TraceRookSupported integration scope
MVP1 targets local Claude Code sessions with compatible user hooks, including local CLI and IDE-embedded sessions where those callbacks actually execute. The host can offer other execution environments; TraceRook’s local guarantee does not extend to them automatically.
The current adapter normalizes sanitized schema fixtures and encodes fixture decisions. It does not install or run a live integration. Do not manually install the foundation bridge as an operational security hook.
Consent-based hook configuration
The intended installer modifies ~/.claude/settings.json only after a readable before/after preview and explicit consent. It preserves unrelated keys, matchers, and hooks, creates a permission-preserving backup, and refuses a write if the source changed.
Required lifecycle hooks include SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, and SessionEnd. PostToolUseFailure is optional. InstructionsLoaded can inform behavioral context, but is not itself an enforcement gate.
Pre-tool decisions
PreToolUse is the hook that can deny a supported proposal before execution. TraceRook’s no-override path exits successfully with empty stdout, leaving Claude Code’s native permission flow intact.
A denial uses validated hookSpecificOutput.permissionDecision = "deny" or exit code 2 with sanitized stderr. Debugging text must never contaminate stdout. High-risk human review waits synchronously within the callback before returning its final host-compatible result.
External reference: Claude Code hooks reference.
Installation is only the first check
Verification needs the exact detected host version, adapter version, schema check, configuration state, helper signature, successful callback, and real pre-tool blocking evidence. Policy may disable user hooks even when a file contains them.
Onboarding must exercise a harmless real host call and show its receipt. A separate harmless blocked fixture must prove the body never ran. Newer-than-verified versions show Compatibility not yet verified.
Failure and repair
A callback error or timeout can let execution continue. If the bridge starts but the service is unavailable, shared local fallback rules can return a timely denial for known catastrophic evidence. A hook that does not run cannot enforce it.
Repair must preserve unrelated settings and use the same consent and optimistic-concurrency protections as installation. App moves must not silently rewrite user configurations. See safe configuration changes.