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.

Watcher does not support Gemini CLI, which Google has deprecated in favor of Antigravity CLI, on any provider route. Captures that carry its 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.

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.

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.

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.

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. Watcher still reviews each request Codex raises, and the sandbox is unchanged.

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.