Delegate Claude Code review and implementation tasks to the local Claude Code CLI as background subagents.
Run tasks: Start a Claude Code session (claude_run) with a chosen permission tier — consult (read-only: Read, Grep, Glob) or execute (adds Edit, Write, Bash) — in an allowed workspace, returning a jobId immediately.
Poll results: Check progress and final output with claude_status, using a cursor for incremental events, optionally waiting up to 45 seconds.
Continue sessions: Send follow-up prompts to a finished job via claude_reply, which starts a new turn on the same underlying session and returns a new jobId.
Cancel jobs: Stop a running job and its process tree with claude_cancel.
Configure runs: Specify model, reasoning effort, max turns, spend ceiling, and wait time per run.
Control scope: Workspaces are allowlisted via CC_AS_SUBAGENT_WORKSPACE_ROOTS; state is stored outside workspaces; environment variables passed through are restricted.
Check liveness: ping returns server version and accepted workspace roots without spawning Claude Code.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cc-as-subagent review the changes in C:\code\project-a and list any bugs"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that exposes the local Claude Code CLI as a subagent, for Codex to delegate review and implementation work to.
Read this first
This server is a hole in your caller's policy, by construction. Codex's sandbox and approval settings do not govern MCP servers, and they do not govern anything an MCP server goes on to spawn. Approving this server means approving a path that runs
claudewith a policy you chose here, not one Codex chose.On native Windows there is no sandbox underneath it. Claude Code's
sandbox.enabledcovers macOS, Linux and WSL2 only. What confines a run here is a fixed permission tier plus the CLI's fail-closed behaviour when nothing can answer a prompt — not an OS boundary. A confused model is blunted; a hostile workspace is not defeated. See SECURITY.md.Set
default_tools_approval_mode = "prompt"in your Codex config (see examples/codex-config.toml). It is the only human checkpoint anywhere on this path, and it is off by default.
Related MCP server: Hydra
Submits a task to claude in a workspace and returns a job handle immediately.
The run continues in the background; you poll for the result. Submitting never
blocks, because a real review takes minutes and Codex's default tool timeout is
60 seconds.
Two permission tiers, chosen by the server — the caller names a tier, never a CLI flag:
Tier | Tools | Permission mode | Can |
|
|
| read and search; nothing that needs approval |
|
|
| work inside the workspace — including running builds and tests |
execute runs under auto, which is what makes it an implementation tier at
all. Under the previous mode (acceptEdits) a build or a test could not run —
measured: npm test came back "requires approval and wasn't approved" — so
the tier could edit files but never verify anything.
What that costs, stated rather than buried: a write outside the working
directory is no longer refused. Measured on 2.1.283 — acceptEdits blocked it,
auto allowed it. Inside the workspace the tier is still bounded by --tools,
by the generated deny rules, and by the CLI's classifier; outside it, the deny
rules are the only thing left, and those are not a boundary. The equivalent mode
on the Qoder side does not have this cost, so the two servers are not equally
confined. See SECURITY.md.
Node 18+ (developed on 24)
Claude Code CLI on PATH, logged in
Claude Code 2.1.227 or later; verified against 2.1.283.
--restricted (2.1.248+) is opt-in and off by default, via
CC_AS_SUBAGENT_RESTRICTED=1. It confines the built-in file tools to the
working directory and loads only managed settings plus --settings — but that
last part is also why it is off: it excludes user settings, so it breaks
authentication wherever credentials come from there, and a sanitized
environment has no fallback. Measured on 2.1.283: full environment works,
sanitized environment fails with Not logged in. Turn it on only if your
credentials come from the environment and you pass them through — see
SECURITY.md.
npm install
npm run build
node scripts/selfcheck.mjs # verifies the security assumptions against your CLI
npm run probe # optional: MCP handshake smoke testAdd the server to ~/.codex/config.toml — a working example is in
examples/codex-config.toml.
[mcp_servers.cc-as-subagent]
command = "node"
args = ["<abs path>/cc-as-subagent/dist/index.js"]
default_tools_approval_mode = "prompt"
[mcp_servers.cc-as-subagent.env]
CC_AS_SUBAGENT_WORKSPACE_ROOTS = "C:\\code\\project-a;C:\\code\\project-b"default_tools_approval_mode = "prompt" makes Codex ask a human before each
call. Without it nothing on this path asks anyone.
Tool | Arguments | Returns |
|
|
|
|
|
|
|
| a new |
|
|
|
claude_reply takes a job id, never a session id. The session id stays
server-side, because --resume also accepts a path to a transcript file and a
caller-controlled value there would be a file-read primitive.
Poll with the cursor from the previous response to get only new events. If
the log was compacted while you were away, the response carries cursorResetTo
instead of silently skipping.
Variable | Default | Purpose |
| the server's own cwd | Path-delimiter-separated allowlist. A workspace outside every root is refused. |
|
| Where job state lives. Deliberately outside any workspace. |
| (none) | Comma-separated variable names to pass to |
| off | Set to |
| off | Set to |
| resolved from | Pin an exact CLI build. |
npm test — 53 unit tests. node scripts/e2e.mjs — 13 checks against a real
CLI, including that a resumed turn still carries the isolation stack, that
consult can read a workspace while being granted no write tool, and that the
execute session is granted exactly its six tools — the CLI adds GetTask
to a Bash-capable session uninvited, so it is denied by name.
node scripts/selfcheck.mjs re-runs the security assumptions against whatever
CLI is installed and writes a verdict to the state directory. Re-run it after a
CLI upgrade.
Stated plainly rather than buried — see SECURITY.md for the full list and the reasoning.
No OS sandbox on Windows. The confinement is a permission tier plus fail-closed denial.
Command deny rules are not a security boundary. The CLI's own documentation says so. They blunt a confused model; they do not stop a deliberately crafted one.
Reads inside the workspace are unrestricted. Credentials sitting in a project directory are readable unless named in the deny list.
A workspace the user once trusted interactively carries its own
permissions.allow into these runs.
consult sessions are transcript-persisted unless you pass
--no-session-persistence, which would also make them unresumable.
MIT — see LICENSE.
Stop a running job and the process tree it started.
Inputs: jobId (required).
Start a follow-up turn in an existing session. Takes the jobId of a finished job — the session id stays server-side. Returns a new jobId for the follow-up.
Inputs: jobId (required), prompt (required), model, effort, +1 more.
Start a new Claude Code session in a workspace. Returns a jobId immediately; the run continues in the background. Use claude_status to poll for the result. Tier "consult" is read-only; "execute" may edit files in the workspace.
Inputs: tier (required), prompt (required), workspace (required), model, +4 more.
Poll a job for progress and its result. Pass the cursor from the previous call to receive only new events. Returns the final answer once the run completes.
Inputs: jobId (required), cursor, waitSeconds.
Liveness check. Reports the server version and the workspace roots it will accept. Never spawns Claude Code.
Inputs: no named parameters.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 5 tools
The tools are mostly distinct: ping is a liveness check, claude_run starts a job, claude_status polls it, claude_cancel stops it, and claude_reply continues a finished job. The only mild ambiguity is between claude_run and claude_reply, since both start work in a session, but the descriptions clarify that reply is specifically for follow-up turns on an existing session.
All tools use the claude_ prefix with a clear verb: cancel, ping, run, status, reply. This is a consistent and predictable pattern. The minor deviation is that ping is a noun/verb that doesn't fit the job lifecycle as directly as the others, but it is still clearly named.
Five tools is well-scoped for a subagent orchestration server: start, poll, cancel, reply, and health check. Each tool earns its place and there is no bloat.
The core lifecycle of running and managing a Claude Code session is covered: start, poll, cancel, and follow-up. A minor gap is the lack of a way to list active jobs or sessions, which could be useful for recovery, but agents can work around it by tracking jobIds.
Give spare Claude Code or Codex usage to open source. Your agent opens pull requests. No money.
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
