Supported agents

Watcher supports local Claude Code and Codex sessions through the Watcher client.

Gateway hooks also support agents routed through Tailscale's Aperture LLM gateway, without installing the Watcher client on each machine.

Claude Tag

Watcher does not currently support monitoring Claude Tag. Hooks configured in a repository do not run in Claude Tag sessions. Monitoring through a Watcher plugin has not been verified.

Through Aperture

Aperture integration records sessions and reviews tool calls in observe mode. It does not block tool execution. Configure it using the Aperture hook setup. Tool thresholds and command rules written for Claude Code's tool names also apply to the other agents' equivalent tools; see Tool names and policy.

Symbol	Support	Meaning
✅	fully supported	Supported for session and tool-call monitoring.
🧪	experimental	Expected to work, but not fully tested or guaranteed.
🚫	known not supported	The agent can use this provider natively, but Watcher does not support monitoring that route through Aperture.
❌	invalid	The agent cannot natively use this provider API.

Harness	AWS Bedrock	OpenAI	Google Vertex AI	Anthropic	Gemini API	Microsoft Foundry	OpenRouter
Claude Code CLI	✅	❌	✅	✅	❌	🧪	🧪
Claude Desktop Chat	🧪	❌	🧪	✅	❌	🧪	🧪
Claude Desktop Code	🧪	❌	🧪	🧪	❌	🧪	🧪
Claude Cowork	🧪	❌	🧪	🧪	❌	🧪	🧪
Codex CLI	🧪	✅	❌	❌	❌	🧪	✅
Codex Desktop	🧪	🧪	❌	❌	❌	🧪	🧪
Codex IDE extension	🧪	🧪	❌	❌	❌	🧪	🧪
ChatGPT Desktop Work	🧪	🧪	❌	❌	❌	🧪	🧪
Gemini CLI		❌	🚫		🚫
OpenCode	✅	✅	✅	✅	✅	🧪	✅
Antigravity CLI	❌	❌	🚫	❌	🧪	❌	❌
Qwen Code		🧪					✅
Mistral Vibe		🧪					🧪

Blank cells are not assessed. The matrix describes native provider routes; bridges that translate between provider APIs are outside its scope.

ChatGPT Desktop Work means Work locally in the ChatGPT desktop app, which reads the same custom provider configuration as Codex. Cloud Work runs in OpenAI's hosted environment and does not pass through Aperture.

Google has deprecated Gemini CLI in favor of Antigravity CLI. Watcher does not support Gemini CLI through Aperture on any provider route. The hook-based Gemini CLI example in Integrations is a separate connection, described there. Aperture captures that carry the Gemini CLI user agent are still recorded and their tool calls reviewed, but one conversation can appear as several sessions, and each of its helper requests, such as chat compression or a web search, as a session of its own. Gateway hooks describes this behavior.

For SDK examples and other connection types, see Integrations. To record GitHub Copilot CLI sessions and review their tool calls without the Watcher client, see Set up GitHub Copilot CLI.

Local agents

watcher hooks install registers Watcher with every supported agent on the machine. The installer runs it for you, and it is safe to run again. The hooks record the session as it happens and give blocking review its gate:

• Claude Code: hook entries are written into ~/.claude/settings.json. They observe the session lifecycle: session start, each prompt, each tool call and its result, end of turn, and session end. The tool-call hooks are where blocking review evaluates a call before it runs.
• Codex: hook entries are written into hooks.json in the Codex home directory (~/.codex by default). Codex gates tool calls differently from Claude Code, so it needs the extra handling described in Codex specifics below.

With both local agents, the hooks record from the agent's own transcript files (for example Claude Code's ~/.claude/projects). These files belong to the agent and exist with or without Watcher.

Subagent coverage follows each agent's hook and approval flow. See Subagent coverage for an example and the limits on conversation visibility.

Installing, removing, repairing, and diagnosing local hooks is covered on the Client page.

Claude Code specifics

Calls you approve at Claude Code's prompt

When blocking review escalates a call, you can approve it at Claude Code's own permission prompt. If you then press Esc while the approved call is still running, Watcher records the call as one you refused: the human decision is deny, the call shows as blocked, and the decision time is when you pressed Esc. Claude Code reports that interrupt exactly as it reports pressing Esc at the permission prompt, so Watcher cannot tell the two apart. The call may already have changed files or run commands before you pressed Esc, and that record does not show it.

Claude Code does not tell Watcher when you approve at its prompt, so when you approve a call and let it finish, the recorded decision time is when the call finished, not when you answered.

Codex specifics

Codex reviews tool calls through its own approval flow rather than on every call, and it needs some extra setup.

Setup and confirmation

Watcher manages Codex's approval policy in its config.toml. In enforce mode it also manages two more things: the sandbox, and who answers an approval request. The installer previews these changes and asks you to confirm them before applying.

Codex then adds its own check. The next time it starts, it asks you to confirm the new hooks. Until you accept, Codex runs without them, so sessions are not recorded and no call is gated.

How calls are gated

Codex's approval policy is set so that Codex asks before it runs a command it considers dangerous, and whenever the model needs to act outside its sandbox. Watcher reviews each of these requests and either answers or escalates it.

For a request made inside a Code Mode program, Codex keeps waiting for Watcher's answer even after you interrupt the turn (Esc), and acts on it. So when the turn was interrupted before Watcher finished reviewing a request, Watcher denies the request instead of approving it, escalating it or leaving it to Codex, and records it as a cancelled call that Watcher blocked, with no answer from you.

Actions that stay inside the workspace, and are not on Codex's dangerous list, run without a pre-execution decision. They are still recorded and graded.

So do commands you approved with "Yes, and don't ask again": Codex saves a rule allowing commands that start the same way and stops asking about them, so Watcher receives no further requests for them. When the Codex session's record lists such a rule, as it does for one saved during that session, the call's decision in Analyzer says that a rule covered it.

The sandbox follows the enforcement mode

What the sandbox is set to depends on the machine's enforcement mode.

In enforce mode, Watcher keeps Codex's workspace sandbox on. An action that reaches the network, or a path outside the workspace, must then be requested as an escalation, and Watcher reviews that request.

In observe and paused modes, Watcher does not manage the sandbox. It leaves whatever you set: it never tightens a sandbox you did not ask for, and never weakens one you did.

Overriding who answers

Running codex --approve-for-me (alias --not-so-yolo) changes who answers escalations for that invocation, overriding what Watcher pinned. Codex's own auto-reviewer answers the ones Watcher would otherwise have put to a human. Choosing "Approve for me" in Codex's /permissions menu does the same for the rest of the session. Watcher still reviews each request Codex raises, and the sandbox is unchanged. Analyzer shows whether such a call ran, but records no human decision for it, since no person answered.

Policies that bypass the gate

A Codex session can also run under an approval policy that asks about nothing at all. Watcher then receives no requests, so in enforce mode it reviews none of that session's calls before they run. codex exec forces such a policy for its run.

Codex also stores the policy a thread ran under and restores it as a session-level setting, which outranks the one Watcher configures. So resuming or forking a thread that ever ran that way brings the policy back.

Either way, the session is still recorded and graded afterward. Each of its calls carries a decision noting that it was not routed through Watcher because of the session's Codex approval policy. Starting a fresh interactive thread restores the gate.