Assistant Boundary

Warden is a runtime governance layer that sits between your AI assistant and your codebase. Understanding the boundary between what Warden controls and what your assistant controls natively helps you configure both effectively.

What Warden Controls

These capabilities are handled by Warden regardless of which assistant you use:

Safety & Policy

• Blocking dangerous commands (rm -rf, reverse shells, credential theft)
• Substitution rules (grep → rg, find → fd, curl → xh) — mostly advisory, a few applied in place
• Sensitive file protection (.ssh, .env, credentials)
• Prompt injection detection in tool output

Session Intelligence

• Session phase tracking (Warmup → Productive → Exploring → Struggling → Late)
• Goal extraction and drift detection
• Loop detection and verification debt tracking
• Focus scoring and advisory injection (trust-gated)

Output Efficiency

• Verbose output compression (dotnet build, npm install, git diff)
• Smart truncation and context budget management
• Compaction forecasting

Observability

• MCP server for assistant-to-Warden queries
• Session quality scoring and anomaly detection
• Cross-session learning

What Warden Writes

Warden is not read-only with respect to your assistant’s configuration. Hooks have to be registered somewhere, and that somewhere is the assistant’s own settings file. Everything Warden writes is scoped, tracked, and removable.

Rules for those writes:

• Compilation is a three-way merge, not an overwrite. Each compile records every entry it adds in a manifest (~/.warden/managed-keys.json). The next compile replaces exactly those entries and leaves anything you added by hand in place. It snapshots settings.json before writing and writes atomically (temp file plus rename).
• Compilation can run on its own. The background server recompiles Claude Code’s entries at startup whenever your rules.toml is newer than that manifest — which is how a rule change reaches the host’s native allow and deny lists without your doing anything. warden --debug compile <target> runs it on demand.
• Uninstall reverses it. warden uninstall removes Warden’s hook entries from ~/.claude/settings.json and ~/.gemini/settings.json, drops allowedHttpHookUrls, and removes the MCP registration from ~/.claude.json. Your other settings are untouched.

CLAUDE.md

Warden’s per-turn governance section — session phase, trust, active rule counts — is delivered through the SessionStart hook’s additionalContext. It is not written to your CLAUDE.md.

Earlier releases wrote that section into the project’s CLAUDE.md as a block bounded by <!-- warden:start --> and <!-- warden:end -->, never touching anything outside those markers. If a project of yours still carries one, it is inert and safe to delete.

What Claude Code Controls

These are native Claude Code features that Warden does not touch:

• CLAUDE.md — project instructions, coding style, preferences
• Permissions — tool approval prompts (allow/deny). Warden observes permission requests and records them; by default it does not answer them
• Context window — what’s loaded, when to compact
• Model selection — which Claude model powers the session
• Skills — slash commands and custom workflows
• Memory — persistent facts across conversations
• Settings — everything in settings.json outside the hook, auto-allow, and deny entries listed above

What Gemini CLI Controls

These are native Gemini CLI features that Warden does not touch:

• .gemini/ project configuration — Warden’s hooks live in the user-level ~/.gemini/settings.json
• Tool policies — which tools are allowed or denied
• Context management — what’s included in the prompt
• Model selection — which Gemini model is used
• Extensions — Gemini CLI plugins and integrations

What Codex CLI Controls

These are native Codex CLI features that Warden does not touch:

• .codex/ project configuration — Warden’s hooks live in the user-level ~/.codex/hooks.json
• Tool policies — which tools are allowed or denied
• Context management — what’s included in the prompt
• Model selection — which OpenAI model is used
• Plugins — Codex CLI extensions and integrations

Hook Coverage Is Not Equal

The rule engine is shared; the hooks each host exposes are not. Claude Code gets 17 hook registrations across 13 events. Codex CLI gets 15 across 11 — nearly the full surface. Gemini CLI gets 11 across 7; its API has no permission, post-compaction, subagent, or task-completion events, so those capabilities cannot exist there.

Safety enforcement and substitution behave the same on all three, because they run in the pre-tool hooks every host provides. “No event” means the host’s hook API has nothing to register against — not that Warden skips it. The Gemini and Codex registrations follow each host’s published hooks reference; behavior on a live install of those hosts has not yet been independently verified the way Claude Code’s has.

The Shared Boundary

Some behaviors involve both Warden and the assistant:

Design Rules

1. Warden never overrides the assistant’s permission system. If Claude Code, Gemini CLI, or Codex CLI approves a tool use, Warden can still deny it for safety — but it cannot grant permissions the assistant denied. Warden’s own auto-approve path is off by default: it observes permission requests and lets the host’s dialog decide.

2. Warden’s writes to assistant configuration are scoped and reversible. They are limited to the hook, auto-allow, and deny entries listed above, tracked in a manifest, and removed by warden uninstall.

3. The rule engine is assistant-agnostic; hook coverage is not. The same compiled rules, session signals, and output compression run behind whichever hooks the host exposes. Where a host exposes fewer events, Warden does less — see the table above.