loading…
Search for a command to run...
loading…
A relay server that enables communication between Claude Code and Codex through shared messaging channels, facilitating collaborative workflows like code review
A relay server that enables communication between Claude Code and Codex through shared messaging channels, facilitating collaborative workflows like code reviews. It includes tools for posting and fetching messages, a web UI for viewing conversations, and automated activity logging.
This runs a single Python MCP server that both Claude Code and Codex (VS Code chat / CLI) can connect to.
It provides:
post_message, fetch_messages, list_channelspippython -m venv .venv
source .venv/bin/activate # (Windows: .venv\Scripts\activate)
pip install -r requirements.txt
python claude_codex.py
This reads host/port from config.json (or env vars, or defaults to 127.0.0.1:8010).
Alternatively, specify host/port directly:
uvicorn claude_codex:app --host 127.0.0.1 --port 8010
Open:
Logs:
log/claude_codex.log (rotated, defaults: 25MB × 10 backups)log/channel_messages.log (rotated, defaults: 25MB × 10 backups)Configuration is loaded from config.json (if present), then environment variables, then defaults.
Create a config.json in the project root:
{
"host": "127.0.0.1",
"port": 8010,
"log_path": "log/claude_codex.log",
"log_max_mb": 25,
"log_backup_count": 10,
"channel_log_path": "log/channel_messages.log",
"channel_log_max_mb": 25,
"channel_log_backup_count": 10,
"channels": ["proj-x", "codex", "claude"],
"allowed_hosts": []
}
| Variable | Default | Meaning |
|---|---|---|
CLAUDE_CODEX_HOST |
127.0.0.1 |
Server host |
CLAUDE_CODEX_PORT |
8010 |
Server port |
CLAUDE_CODEX_LOG_PATH |
log/claude_codex.log |
Log file path |
CLAUDE_CODEX_LOG_MAX_MB |
25 |
Rotate after N MB |
CLAUDE_CODEX_LOG_BACKUP_COUNT |
10 |
Keep N backups |
CLAUDE_CODEX_CHANNEL_LOG_PATH |
log/channel_messages.log |
Channel message archive log path |
CLAUDE_CODEX_CHANNEL_LOG_MAX_MB |
25 |
Rotate channel log after N MB |
CLAUDE_CODEX_CHANNEL_LOG_BACKUP_COUNT |
10 |
Keep N channel log backups |
CLAUDE_CODEX_CHANNELS |
proj-x,codex,claude |
Seed list of channels |
CLAUDE_CODEX_ALLOWED_HOSTS |
(empty) | Extra hosts for MCP DNS-rebinding protection (comma-separated) |
Legacy compatibility: log_max_bytes / channel_log_max_bytes (and env ..._MAX_BYTES) are still accepted.
Example:
CLAUDE_CODEX_LOG_PATH=/tmp/relay.log uvicorn claude_codex:app --host 127.0.0.1 --port 8010
By default the MCP endpoint only accepts requests with Host: localhost or Host: 127.0.0.1 (DNS-rebinding protection). To allow connections from other machines on the network, add their IPs to allowed_hosts:
config.json:
{
"host": "0.0.0.0",
"allowed_hosts": ["192.168.2.3"]
}
Or via env vars:
CLAUDE_CODEX_HOST=0.0.0.0 CLAUDE_CODEX_ALLOWED_HOSTS=192.168.2.3 python claude_codex.py
Port wildcards are added automatically — 192.168.2.3 becomes 192.168.2.3:*. You can also specify an explicit host:port pattern like 192.168.2.3:8010.
See:
docs/claude.mddocs/codex.mdUse a shared channel like proj-x so both agents read/write the same thread.
Claude makes changes, then posts a review packet:
Codex fetches, reviews, then posts feedback:
Claude applies fixes and posts an updated packet.
scripts/review-poll.sh is a lightweight bash poller that watches a channel for new messages. It uses curl and jq to hit the /api/messages endpoint and prints one-line summaries of any new messages since the last poll.
Required env vars:
| Variable | Purpose |
|---|---|
BASE_URL |
Server URL, e.g. http://127.0.0.1:8010 |
LASTFILE |
Path to a file that persists the last-seen message ID |
Optional env vars:
| Variable | Default | Purpose |
|---|---|---|
TARGET |
propiese |
Channel to poll |
INTERVAL |
20 |
Seconds between polls |
WATCH_SENDER |
claude |
Only show messages from this sender (ignores own messages) |
Example:
BASE_URL=http://127.0.0.1:8010 LASTFILE=/tmp/last_id TARGET=proj-x INTERVAL=10 bash scripts/review-poll.sh
Codex won't poll on its own — it only acts when prompted. Options A–C below require a human in the loop to relay messages to Codex. Only Option D is fully automated.
Add to .github/copilot-instructions.md or your VS Code Copilot instructions:
After completing any task, call the fetch_messages MCP tool on the "proj-x" channel
to check for new review feedback before going idle.
Codex will check after each task, but won't poll while idle. You still need to manually prompt Codex to start a new task cycle.
BASE_URL=http://127.0.0.1:8010 LASTFILE=/tmp/last_id TARGET=proj-x INTERVAL=10 \
bash scripts/review-poll.sh
New messages appear in the terminal. You need to read the output and tell Codex to act on it (e.g. "check the proj-x channel" or paste the summary).
Auto-starts the poll script when you open the workspace, so you don't have to launch it manually. But Codex still cannot read terminal output on its own — you need to prompt it when you see new messages.
Add to .vscode/tasks.json:
{
"version": "2.0.0",
"tasks": [
{
"label": "MCP Poller",
"type": "shell",
"command": "bash",
"args": [".codex/reviewer-poller.sh"],
"options": {
"env": {
"BASE_URL": "http://127.0.0.1:8010",
"LASTFILE": "${workspaceFolder}/.codex/reviewer-poller.last_id",
"TARGET": "proj-x",
"INTERVAL": "15"
}
},
"isBackground": true,
"runOptions": { "runOn": "folderOpen" }
}
]
}
Tip: Enable auto-start via
Ctrl+Shift+P→Tasks: Manage Automatic Tasks in Folder→ Allow.
This is the only fully automated option. It uses Codex CLI — OpenAI's terminal-based coding agent — to automatically react to new messages without human intervention.
Install Codex CLI:
npm i -g @openai/codex
Configure MCP connection so Codex can call fetch_messages / post_message directly.
Add to your project's .codex/config.toml:
[mcp.claudecodex]
transport = "sse"
url = "http://127.0.0.1:8010/mcp"
Ensure curl and jq are installed (used by the poll loop).
Create a script (e.g. .codex/auto-review-loop.sh):
The script uses codex exec (non-interactive/headless mode) so that Codex exits automatically after completing each review. The regular codex and codex resume commands open an interactive session that would block the loop.
#!/usr/bin/env bash
set -u
BASE_URL="${BASE_URL:-http://127.0.0.1:8010}"
TARGET="${TARGET:-proj-x}"
INTERVAL="${INTERVAL:-20}"
LASTFILE="${LASTFILE:-.codex/auto-loop.last_id}"
SESSION_ID="${SESSION_ID:-}" # optional: resume an existing Codex session
WATCH_SENDER="${WATCH_SENDER:-claude}" # only react to messages from this sender
LAST=0
if [ -f "$LASTFILE" ]; then
LAST=$(cat "$LASTFILE" 2>/dev/null || echo 0)
fi
if ! [[ "$LAST" =~ ^[0-9]+$ ]]; then LAST=0; fi
echo "auto-loop started: target=$TARGET sender=$WATCH_SENDER interval=${INTERVAL}s last=$LAST session=${SESSION_ID:-new}"
while true; do
JSON=$(curl -sS -m 10 "$BASE_URL/api/messages?target=$TARGET&limit=200" || true)
# Only look at messages from WATCH_SENDER — ignore own (codex) messages
NEW=$(printf "%s" "$JSON" | jq -r --argjson d "$LAST" --arg sender "$WATCH_SENDER" \
'[.messages[] | select(.sender == $sender)] | last | .id // $d' 2>/dev/null || echo "$LAST")
if [[ "$NEW" =~ ^[0-9]+$ ]] && [ "$NEW" -gt "$LAST" ]; then
echo "$(date -Iseconds) new messages from $WATCH_SENDER (last=$LAST, new=$NEW) — launching Codex"
PROMPT="Fetch messages from the $TARGET channel (since id $LAST) sent by $WATCH_SENDER and review them. Post your feedback back to the same channel."
if [ -n "$SESSION_ID" ]; then
# Resume existing session — keeps full conversation context across reviews
codex exec --dangerously-bypass-approvals-and-sandbox resume "$SESSION_ID" "$PROMPT"
else
# Start a fresh session
codex exec --dangerously-bypass-approvals-and-sandbox "$PROMPT"
fi
LAST="$NEW"
echo "$LAST" > "$LASTFILE"
fi
sleep "$INTERVAL"
done
chmod +x .codex/auto-review-loop.sh
# Start a new session each time
BASE_URL=http://127.0.0.1:8010 TARGET=proj-x INTERVAL=15 \
bash .codex/auto-review-loop.sh
# Or resume an existing Codex session (keeps conversation context)
BASE_URL=http://127.0.0.1:8010 TARGET=proj-x SESSION_ID=abc123 \
bash .codex/auto-review-loop.sh
/api/messages every INTERVAL secondscodex exec (non-interactive mode) which processes the task and exits automaticallySESSION_ID is set, it uses codex exec resume <SESSION_ID> to continue an existing session — Codex keeps the full conversation history and builds on previous reviewsWhy
codex execinstead ofcodex? The regularcodexcommand opens an interactive terminal UI that waits for user input and never exits.codex execis the headless/non-interactive mode designed for scripts and automation — it runs the task and exits when done.
Each Codex CLI chat gets a session ID stored under ~/.codex/sessions/. You can use these to maintain continuity across reviews.
| Command | Purpose |
|---|---|
/status |
Show current session ID (inside a running session) |
codex resume |
Pick a session to resume from a list |
codex resume <SESSION_ID> |
Resume a specific session by ID |
codex fork |
Fork a session into a new thread |
codex fork --last |
Fork the most recent session |
You can also type /resume inside the CLI to get an interactive session picker.
Tip: After the first Codex run, grab the session ID from /status or ~/.codex/sessions/ and pass it as SESSION_ID to the auto-loop. This way every review iteration builds on the same conversation thread, giving Codex full context of previous feedback.
| Flag | Approvals | File writes | Network |
|---|---|---|---|
| (default) | Asks before commands/writes | Workspace only | Blocked |
--full-auto |
None | Workspace only | Blocked |
--full-auto + network config |
None | Workspace only | Allowed |
--sandbox danger-full-access |
Asks before commands | Anywhere | Allowed |
--dangerously-bypass-approvals-and-sandbox |
None | Anywhere | Allowed |
Important:
--full-autoblocks network access by default. Since Codex needs to reach the MCP relay, the auto-loop script above will fail unless network access is enabled.
Option 1: Enable network in config (recommended). Add to .codex/config.toml:
[sandbox_workspace_write]
network_access = true
Then --full-auto works as-is.
Option 2: Pass sandbox config inline:
codex exec --full-auto -c 'sandbox_workspace_write.network_access=true' "$PROMPT"
Option 3: Bypass the sandbox entirely (use with caution):
codex exec --dangerously-bypass-approvals-and-sandbox "$PROMPT"
This variant uses --dangerously-bypass-approvals-and-sandbox to ensure Codex can reach the MCP relay without any restrictions:
#!/usr/bin/env bash
set -u
BASE_URL="${BASE_URL:-http://127.0.0.1:8010}"
TARGET="${TARGET:-proj-x}"
INTERVAL="${INTERVAL:-20}"
LASTFILE="${LASTFILE:-.codex/auto-loop.last_id}"
SESSION_ID="${SESSION_ID:-}"
WATCH_SENDER="${WATCH_SENDER:-claude}" # only react to messages from this sender
LAST=0
if [ -f "$LASTFILE" ]; then
LAST=$(cat "$LASTFILE" 2>/dev/null || echo 0)
fi
if ! [[ "$LAST" =~ ^[0-9]+$ ]]; then LAST=0; fi
echo "auto-loop started: target=$TARGET sender=$WATCH_SENDER interval=${INTERVAL}s last=$LAST session=${SESSION_ID:-new}"
while true; do
JSON=$(curl -sS -m 10 "$BASE_URL/api/messages?target=$TARGET&limit=200" || true)
# Only look at messages from WATCH_SENDER — ignore own (codex) messages
NEW=$(printf "%s" "$JSON" | jq -r --argjson d "$LAST" --arg sender "$WATCH_SENDER" \
'[.messages[] | select(.sender == $sender)] | last | .id // $d' 2>/dev/null || echo "$LAST")
if [[ "$NEW" =~ ^[0-9]+$ ]] && [ "$NEW" -gt "$LAST" ]; then
echo "$(date -Iseconds) new messages from $WATCH_SENDER (last=$LAST, new=$NEW) — launching Codex"
PROMPT="Fetch messages from the $TARGET channel (since id $LAST) sent by $WATCH_SENDER and review them. Post your feedback back to the same channel."
if [ -n "$SESSION_ID" ]; then
codex exec --dangerously-bypass-approvals-and-sandbox resume "$SESSION_ID" "$PROMPT"
else
codex exec --dangerously-bypass-approvals-and-sandbox "$PROMPT"
fi
LAST="$NEW"
echo "$LAST" > "$LASTFILE"
fi
sleep "$INTERVAL"
done
Safer alternative: If you prefer to keep the workspace sandbox, add
network_access = trueto your.codex/config.toml(see Option 1 above) and use--full-autoinstead.
Добавь это в claude_desktop_config.json и перезапусти Claude Desktop.
{
"mcpServers": {
"claude-codex-mcp-relay": {
"command": "npx",
"args": []
}
}
}