claude_mcp
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., "@claude_mcpAsk Claude Opus to review my recent code changes"
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.
claude_mcp
claude_mcp is a local, stdio-only Model Context Protocol server that gives
Codex a controlled Claude Opus 5 collaborator through the installed Claude Code
CLI and the user's Claude subscription. Opus can inspect an allowed workspace,
plan or review work without editing, or take a separately annotated write-capable
task that can edit files and run focused tests.
Codex remains the orchestrator and final authority. This bridge does not call the Anthropic API directly, accept an Anthropic API key, scrape a terminal, create commits, or run a resident Claude session.
Collaboration model
The intended workflow is writer–verifier separation:
User
-> Codex (GPT-5.6-sol, orchestrator)
-> claude_mcp over MCP stdio
-> claude -p --model claude-opus-5
-> controlled access to one validated workspace
-> structured Opus report + trusted bridge observations
-> Codex inspects the real diff, reruns important checks, and answers the userUseful patterns include:
Codex implements a substantial change, then starts a fresh Opus review.
Opus implements a bounded change, then Codex inspects the actual diff and independently verifies it.
A read-only planning session is resumed into implementation in the same canonical workspace.
Final independent review normally uses a fresh session rather than resuming the authoring session.
Only one operation may use a workspace at a time. Calls for different workspaces may run concurrently up to the configured global limit. Do not ask both models to write the same workspace concurrently, and skip Opus for trivial mechanical work.
Related MCP server: claude-consult-mcp
Why claude -p
Claude Code's non-interactive print mode provides an argument-vector interface,
explicit tools and permission mode, structured JSON output, session IDs, and a
normal subprocess lifecycle. That is substantially more auditable than PTY,
tmux, terminal-control-sequence, or interactive-TUI scraping. The bridge uses
asyncio.create_subprocess_exec with no shell and supplies all task content as
JSON on stdin.
Public MCP tools
Version 0.1 exposes exactly three tools:
opus_status: free local readiness diagnostics. It runsclaude --versionandclaude auth status, but never a model completion.opus_consult: read-onlyplan,review,diagnose, ordesignwork using onlyRead,Glob,Grep. Those tools are explicitly allowed in both CLI arguments and the per-call settings policy. Scrubbed Claude Code sessions use the effectivedefaultpermission mode directly, avoiding a misleading forced-mode warning. Any observed workspace change is returned as a policy violation.opus_execute: destructive, non-idempotentimplement,fix,refactor,test, ordocumentwork usingRead,Glob,Grep,Edit,Write,Bash. Git is required by default.
Both collaboration tools return the validated Opus report separately from
bridge-observed process, session, policy, and workspace metadata. Claude's own
files_changed claim is advisory; the bridge's pre/post manifest is independent.
Full source diffs are not returned because Codex already has local workspace
access and should inspect them directly.
The public tools use reliable turn ceilings: 24 for read-only consultation and
64 for execution. These are maxima, not quotas, so Claude stops earlier when the
task is complete. If Claude exhausts a ceiling, the bridge reports
error_max_turns as a process failure with the selected ceiling and safe
remediation; it does not mislabel the result as a non-Opus fallback or a broken
structured-output contract.
Requirements
Python 3.11 or newer
Git
macOS, Linux, or WSL2 (not native Windows)
Claude Code at or above the configured minimum, currently
2.1.224Native Claude Code sandbox dependencies. On Linux and WSL2 this normally means
bubblewrap(bwrap) andsocat; macOS uses Seatbelt.A Claude subscription login through Claude Code, or a deliberately supplied
CLAUDE_CODE_OAUTH_TOKEN
The bridge fails closed when the native sandbox, required security settings,
supported CLI version, or allowed workspace roots are missing. Write-capable
execution also requires a successful authentication status probe unless the
operator deliberately supplied CLAUDE_CODE_OAUTH_TOKEN; in that case the actual
bounded request validates the token. Because some Claude Code releases can report
a stale status for a usable stored login, read-only consultation also lets the
bounded model request make the final authentication determination and returns its
redacted failure reason.
Installation
git clone git@github.com:catid/claude_mcp.git
cd claude_mcp
uv sync --all-groupsVerify the installed entry point without sending a model request by configuring
the server in Codex and calling opus_status.
Authentication
Use the normal Claude Code subscription login:
claude auth login
claude auth statusCLAUDE_CODE_OAUTH_TOKEN is preserved if the operator deliberately supplies it.
Version 0.1 does not support API-key billing or Bedrock, Vertex, Foundry, custom
gateways, profiles, or alternate endpoints.
Before every diagnostic and task process, the bridge copies the parent
environment and removes variables that could switch authentication, provider,
endpoint, organization, profile, or model. This includes ANTHROPIC_*,
CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, and
CLAUDE_CODE_USE_FOUNDRY, plus selected cloud credentials. Interpreter/loader
injection variables such as NODE_OPTIONS, PYTHONPATH, and LD_PRELOAD, all
GIT_* variables, proxy and custom-CA variables, and CLAUDE_CONFIG_DIR are
also removed. It forces
CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 so Bash children do not inherit Anthropic or
cloud credentials. opus_status reports detected override and dangerous
environment names, never values. Ordinary requirements such as HOME,
PATH, SHELL, TMPDIR, and locale are retained. Version 0.1 intentionally
does not inherit corporate proxies; explicit opt-in proxy support is future work.
Current Claude Code may create known zero-byte scrub stubs and append matching
.git/info/exclude blocks. The bridge records pre-existing state, removes only
new zero-byte stubs, and atomically restores only exact scrub-mode append blocks;
pre-existing or model-written content is preserved.
Configuration
Set at least CLAUDE_MCP_ALLOWED_ROOTS in the MCP server environment. Paths are
separated with os.pathsep (: on POSIX) and are resolved canonically at server
startup.
Variable | Default | Meaning |
|
| Claude Code executable |
|
| Required Opus 5 model |
| required for task calls | Allowed workspace roots |
|
| Total completion timeout |
|
| SIGTERM grace before SIGKILL |
|
| Maximum serialized task payload |
|
| Maximum Claude stdout |
|
| Maximum captured stderr |
|
| Concurrent distinct workspaces |
|
| MCP heartbeat interval |
|
| Require Git for execution |
|
| Claude execute permission mode |
|
| Minimum supported CLI |
| XDG state default | Session registry and lock state |
All values are validated. bypassPermissions and plan mode are not accepted as
execute modes.
Codex MCP configuration
Add this to ~/.codex/config.toml, using absolute paths:
[mcp_servers.opus_collaborator]
command = "/absolute/path/to/claude_mcp/.venv/bin/claude-mcp"
enabled = true
required = false
startup_timeout_sec = 20
tool_timeout_sec = 7500
default_tools_approval_mode = "approve"
[mcp_servers.opus_collaborator.env]
CLAUDE_MCP_ALLOWED_ROOTS = "/absolute/path/to/repositories"
CLAUDE_MCP_MODEL = "claude-opus-5"
CLAUDE_MCP_REQUIRE_GIT_FOR_WRITES = "true"Codex clients share this MCP configuration. Run codex mcp list to inspect
configured servers, or use /mcp in the Codex terminal UI to confirm that
opus_collaborator loaded and advertises exactly three tools. See the current
Codex MCP documentation
for client configuration and approval-mode details.
Usage patterns
Fresh architecture plan
Call opus_consult without a session ID:
{
"workspace_path": "/repos/service",
"task": "Design the new durable job scheduler",
"mode": "design",
"focus": "crash recovery, idempotency, and migration",
"effort": "high"
}Resume a plan into implementation
Pass the returned session ID to opus_execute for the same canonical workspace:
{
"workspace_path": "/repos/service",
"task": "Implement the approved scheduler design",
"mode": "implement",
"session_id": "00000000-0000-4000-8000-000000000000",
"acceptance_criteria": [
"Existing jobs migrate without data loss",
"Focused unit and recovery tests pass"
]
}The shown UUID is illustrative; use the actual bridge-returned value.
Codex implementation, fresh Opus review
After Codex writes a substantial change, call opus_consult with mode: "review"
and omit session_id. Ask for concrete, evidenced findings. Codex should evaluate
each finding against the repository rather than accepting it automatically.
Opus implementation, Codex verification
Delegate a bounded change with opus_execute, then have Codex inspect git diff,
the bridge's observed_changed_paths, pre-existing dirty work, and important
tests. The bridge never commits or pushes the result.
Recommended Codex instruction
Use the Opus collaborator proactively for substantial architecture, unfamiliar
repositories, difficult bugs, multi-file changes, algorithms, concurrency,
security-sensitive work, and independent review. Skip it for trivial mechanical
edits. Delegate a complementary role, never let both agents write the workspace
at once, inspect the actual diff after Opus writes, and use a fresh session for
final independent review unless continuity is specifically valuable.Security model
Workspace paths are hostile input. The bridge expands ~, performs strict
canonical resolution, rejects files and missing paths, checks path-aware allowed
root containment, detects the Git top level, and rejects symlink, traversal,
sibling-prefix, and Git-root escapes. Execution requires Git by default but does
not require a clean tree; pre-existing tracked, staged, untracked, deleted, and
renamed work is preserved as context.
Every operation acquires, in order, a per-canonical-workspace async lock, a
global async semaphore, and a process-safe file lock whose filename is a SHA-256
digest. This prevents duplicate calls for one workspace from consuming global
capacity needed by another workspace. Sessions are canonical UUIDs stored in an
atomic, mode-0600 registry
inside a mode-0700 state directory. A session is bound to one canonical
workspace and one Opus model. A plan may resume into execution, but cross-
workspace and cross-model resumes fail.
Successful output must prove Opus 5 through a validated authoritative model field
or protocol-conformant positive Opus usage that exceeds aggregate Haiku auxiliary
usage. Both modelUsage spellings are audited when present; malformed,
conflicting, or unexpected model entries fail closed, and no fallback model is
configured.
Before and after a call, the bridge independently captures Git HEAD/branch,
NUL-safe porcelain status, tracked/staged/untracked/deleted/renamed paths, diff
statistics, and a content state fingerprint. The returned snapshot explicitly
notes that Git-ignored paths and .git internals are not observed; Codex must
inspect those separately when they matter. Non-Git consultations receive a
directory manifest with explicit entry and content-hash limits; beyond the hash
budget, bounded first/last content samples plus size/mtime/ctime metadata remain
observation evidence.
Filenames with spaces, tabs, quotes, and newlines are supported. A failed or
timed-out process still gets a post-operation observation when possible.
Claude starts in its own process session. Timeout, cancellation, output overflow, or shutdown sends SIGTERM to the full process group, waits the configured grace period, sends SIGKILL if needed, reaps the process, stops heartbeats, cleans owner-only temporary prompt/settings files outside the repository, and releases all locks. The bridge never retries a completion automatically; an ambiguous failure may already have changed files and consumed subscription usage.
Every model call uses --safe-mode, --strict-mcp-config, --no-chrome, no Web
tools, a mandatory fail-closed native sandbox, an empty strict network allowlist,
no local binding or Unix sockets, secret-path denies, and dangerous Git-command
denies. Unsandboxed retry is disabled. Admin-managed Claude Code policy still
applies and can affect the effective policy; inspect organization policy when
opus_status or Claude Code reports a managed-setting conflict.
Important limitations:
Workspace source and submitted task context are sent to Anthropic through the locally authenticated Claude Code process and consume subscription usage.
opus_executeis deliberately write-capable and should be approval-gated by the MCP client.Native sandboxing is a strong boundary, not magic. Repository-contained secrets remain sensitive even when common secret paths are denied.
Claude Code may persist normal local session transcripts in its own state. The bridge does not copy or expose transcript contents.
Network access from Claude tools is denied by default. The model request itself necessarily reaches Anthropic through Claude Code.
Common commit, push, reset, clean, restore, rebase, merge, and history-rewrite commands are denied by pattern; HEAD and workspace changes are independently observed. These are layered controls, not a substitute for Codex inspecting the actual diff and trusted manifest.
Troubleshooting
CLI too old:
opus_statusreports the parsed and minimum versions. Runclaude update, then verifyclaude --version.Authentication unavailable: run
claude auth login,claude auth status, and a newclaude -pcall. A nonzero or malformed status fails execution preflight unless the operator deliberately suppliedCLAUDE_CODE_OAUTH_TOKEN. Read-only consultation may still attempt its bounded call and reports the redacted Claude authentication error if that request also fails.opus_statusreports whether the deliberate-token execution exception is active.API key overrides subscription: unset
ANTHROPIC_API_KEYand related provider variables. Task processes strip them regardless; status reports names.Workspace outside allowed roots: add the complete canonical Git root's parent to
CLAUDE_MCP_ALLOWED_ROOTS. Allowing only a nested subdirectory is rejected when the Git root would escape.Native sandbox unavailable: install
bwrapandsocaton Linux/WSL2, or use a supported macOS host. The bridge runs a real namespace-isolation probe, not just an executable check, and never falls back to unsandboxed Bash. Ubuntu 24.04 may additionally require an administrator-provided AppArmor profile for/usr/bin/bwrapwithuserns,permission; prefer the distribution's purpose-built bwrap profile when available rather than disabling the global user-namespace restriction.Session/workspace mismatch: omit
session_idto start fresh in the new workspace. Sessions cannot move between repositories.Timeout after possible edits: do not blindly call again. Inspect status, actual files, Git diff, tests, and the error's pre/post metadata first.
Malformed Claude result: update Claude Code if necessary and inspect the workspace. Locally invalid structured output is never trusted and execution is never automatically retried.
Corrupt session registry: stop bridge processes, preserve the registry for diagnosis, and move it aside only after deciding that resumable sessions are no longer needed. Corruption is not silently discarded.
Development
The test suite is fully offline. tests/fixtures/fake_claude.py emulates Claude
diagnostics, structured completions, mutations, malformed output, limits,
timeouts, and process descendants. No test requires Anthropic credentials,
network access, subscription usage, or a real Claude invocation.
uv sync --all-groups
uv run ruff check .
uv run ruff format --check .
uv run pytest
uv buildtests/test_protocol.py launches the installed claude-mcp entry point and
performs a real stdio MCP initialize/list/call sequence against the fake CLI.
Version 0.1 scope
Version 0.1 uses direct, synchronous access to one validated workspace per call. It intentionally has no PTY/TUI scraping, tmux integration, resident background agent, remote MCP transport, direct Anthropic API path, alternate provider, automatic worktree, automatic Git operation, arbitrary child MCP server, or background job that outlives an MCP call.
Possible later work includes opt-in isolated Git worktrees and richer progress streaming. Those features should preserve the writer–verifier and fail-closed security invariants established here.
Available Tools
3 toolsopus_consultConsult Claude Opus read-onlyARead-only
Ask a workspace-aware Opus 5 session to plan, design, diagnose, or independently review without editing files. The 24-turn minimum is a completion ceiling, not a required amount of work; omit max_turns to use the reliable default.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| task | Yes | ||
| focus | No | ||
| effort | No | high | |
| context | No | ||
| max_turns | No | ||
| session_id | No | ||
| workspace_path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context the annotations cannot convey: the no-edit guarantee for the consultation, and the semantics of the 24-turn minimum as a ceiling rather than a workload, plus the advice to omit max_turns for the reliable default. It stops short of disclosing cost, latency, or session reuse behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the capability statement front-loaded and the parameter caveat second. Dense and earn-your-place, though the max_turns clause packs two ideas (ceiling semantics plus default advice) into one semicolon splice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The read-only safety profile is carried by annotations and the output schema means return values need not be described, so the core job is covered. But with 8 parameters at 0% schema coverage, an agent still has no guidance on mode/effort/focus/context/session_id semantics, which is a real gap for a tool this configurable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains max_turns well (24-turn minimum is a ceiling, omit to use the default), but mode, task, focus, effort, context, session_id and workspace_path are never addressed, leaving most of the 8 parameters undocumented anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb set (plan, design, diagnose, review) tied to a named resource (workspace-aware Opus 5 session) and pins the scope with 'without editing files'. That scope contrasts cleanly with the sibling opus_execute, so an agent can separate them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the enumerated modes and the 'without editing files' constraint, which hints that opus_execute is the alternative when edits are needed. However, it never states when to pick this tool over opus_execute or opus_status explicitly, and gives no prerequisites or exclusions beyond the read-only framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
opus_executeLet Claude Opus modify a workspaceBDestructive
Delegate bounded implementation, fixes, refactoring, tests, or documentation to Opus 5 with direct write access; inspect the returned trusted workspace manifest. The 64-turn minimum reduces accidental early truncation of editing runs.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| task | Yes | ||
| effort | No | xhigh | |
| context | No | ||
| max_turns | No | ||
| session_id | No | ||
| workspace_path | Yes | ||
| acceptance_criteria | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds useful context – direct write access, a 'trusted workspace manifest' being returned, and the rationale for the 64-turn minimum (avoiding early truncation) – but omits permissions, reversibility, and rate/limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with the primary action front-loaded and the constraint rationale second. No filler, though the second sentence's turn-minimum note is a fairly narrow detail to spend the tail on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the manifest mention is a bonus. Still, for a destructive 8-param write tool with zero schema descriptions, key semantics (workspace_path meaning, session_id reuse, acceptance criteria behavior) are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 8 parameters, so most fields (task, context, effort, workspace_path, session_id, acceptance_criteria) are undocumented. The description only partially compensates by matching the mode values and referencing the 64-turn minimum for max_turns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: delegating bounded coding tasks to 'Opus 5 with direct write access'. The phrase 'direct write access' implicitly distinguishes it from a read-only consult sibling, but no sibling is named outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It enumerates the task classes it handles (implementation, fixes, refactoring, tests, documentation), which maps to the mode enum and implies usage. However, it never states when to prefer this over opus_consult or opus_status, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
opus_statusCheck Opus collaborator readinessARead-onlyIdempotent
Check Claude Code version, subscription authentication, sandbox support, bridge configuration, and an optional workspace without invoking a model completion.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_path | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioral trait beyond them: this performs its checks without triggering a model completion, i.e. no token spend or model side effects — key information for deciding to call it first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the enumerated checklist is dense but each item earns its place by naming a distinct check. Slightly list-heavy, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and annotations cover safety semantics. The description enumerates everything inspected, leaving only minor gaps such as how to interpret partial failures or auth prerequisites — acceptable for a status probe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter (workspace_path) with 0% schema description coverage, so the description carries the burden. It partially compensates by calling the workspace "optional," matching the default of "" and zero required params, but adds no format or expected-value guidance for the path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb ("Check") over a specific set of readiness facets — Claude Code version, subscription auth, sandbox support, bridge config, workspace — which tells an agent exactly what this diagnostic reports. The trailing clause "without invoking a model completion" implicitly separates it from opus_consult/opus_execute, though no sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "without invoking a model completion" hints at the natural usage (a cheap preflight before consult/execute), but the description never states when to call this versus the siblings or what a failed check implies. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
opus_consult - First observed
opus_execute - First observed
opus_status
TDQS
Scored across 3 tools
The three tools map onto a clear read-only / non-editing / editing split: opus_status inspects configuration, opus_consult plans and reviews without writes, and opus_execute delegates with write access. opus_consult and opus_execute could still be momentarily confused since they both invoke a model session, but the descriptions explicitly distinguish edit vs. no-edit behavior.
All three tools follow the same opus_<verb> pattern, with concise verbs (status, consult, execute) that consistently describe the action. No mixing of conventions or casing.
Three tools is minimal but each serves a distinct role in the delegate-to-Opus workflow, so nothing is redundant. It sits at the thin edge of the acceptable range, with no lifecycle tooling (cancel, resume, list sessions) to round it out.
Configuration check, planning/review, and execution are covered, but the surface has notable gaps: no way to list or resume sessions, cancel or abort a long run, or retrieve results of a previously delegated task. Agents must work around these lifecycle omissions.
Related MCP Connectors
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Persistent, governed institutional memory for Claude Code — specs, decisions, learnings.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables Claude Code to delegate tasks to OpenAI's Codex CLI (GPT-5.4) with structured execution traces, parallel execution, session persistence, and adversarial code review.15MIT
- AlicenseAqualityBmaintenanceEnables OpenAI Codex to consult Claude Code for co-analysis, adversarial second opinions, and read-only file review over the Model Context Protocol, with Claude remaining advisory and unable to modify files.924 npmMIT
- AlicenseAqualityCmaintenanceBridges a main agent (e.g., Codex) to a separate execution model in Claude Code Haha Desktop, enabling delegated coding tasks with file modifications, test runs, and change auditing.61MIT
- AlicenseNot gradedqualityCmaintenanceLocal authenticated MCP bridge enabling bounded cross-model review between Claude Code and Codex, with isolated artifacts/workspaces and secure per-role endpoints.51 npmMIT