codex - 💡(How to fix) Fix Expose current thread ID to local stdio MCP servers [2 comments, 2 participants]

What feature would you like to see?

Expose the current Codex thread/session identity to local stdio MCP servers.

Today CODEX_THREAD_ID is available to shell/tool executions, but it does not appear to be available to stdio MCP server startup. This makes it hard for MCP servers to correlate their tool calls with the active Codex thread.

Concretely, please support one of these:

1. Inject CODEX_THREAD_ID into local stdio MCP server processes, the same way it is injected into shell tool executions.

2. Add a supported dynamic MCP env source, for example:

   [mcp_servers.my_server]
   command = "my-server"
   args = ["mcp", "serve"]
   env_vars = [{ name = "CODEX_THREAD_ID", source = "thread" }]

3. Expose equivalent thread/session metadata to MCP servers through another stable mechanism.

Current behavior

Codex CLI 0.125.0 exposes CODEX_THREAD_ID in shell tool executions. For example, inside a shell tool:

env | grep CODEX_THREAD_ID
# CODEX_THREAD_ID=019dba93-8214-7d50-a089-9690b4ce6b9e

However, a local stdio MCP server configured with:

[mcp_servers.clumsies]
command = "clumsies"
args = ["mcp", "serve"]
env_vars = ["CODEX_THREAD_ID"]

does not receive CODEX_THREAD_ID during MCP startup. The MCP server exits when it requires this env var, and Codex reports the server as enabled but with no tools:

/mcp

• clumsies
  • Status: enabled
  • Command: clumsies mcp serve
  • Env: CODEX_THREAD_ID=*****
  • Tools: (none)

Codex logs show the MCP process did not receive the env var:

MCP server stderr (clumsies): Error: clumsies MCP server requires a host CLI session id.

codex mcp get clumsies --json shows the config was parsed as:

{
  "transport": {
    "type": "stdio",
    "command": "clumsies",
    "args": ["mcp", "serve"],
    "env": null,
    "env_vars": ["CODEX_THREAD_ID"]
  }
}

This suggests env_vars inherits from the MCP launcher process environment, not from the active Codex thread context.

Additional local checks

I tested whether env_vars supports a thread-context source:

codex mcp get clumsies \
  -c 'mcp_servers.clumsies.env_vars=[{name="CODEX_THREAD_ID",source="thread_id"}]' \
  --json

Codex rejects it:

unsupported env_vars source `thread_id`; expected `local` or `remote`

source = "local" parses, but appears to mean the MCP launcher local process environment. source = "remote" parses too, but the binary contains a message indicating it requires remote MCP stdio.

Why this matters

MCP servers that record audit logs, per-thread state, rule attestations, or tool-call provenance need to associate MCP tool calls with the active Codex thread. Without a stable Codex-provided thread/session id at MCP startup or tool-call time, these servers must either:

• invent their own session ids, which cannot be correlated with Codex hooks or shell executions;
• rely on workspace-global marker files, which break with concurrent sessions;
• ask the model to pass session ids manually, which is brittle and protocol-polluting;
• or fail MCP startup, which leaves Codex showing Tools: (none).

This is especially visible for MCP servers that also integrate with Codex hooks: hooks can see the current session/thread identity, while the MCP server cannot, so hook events and MCP tool events cannot be reliably joined.

Expected behavior

There should be a supported way for local stdio MCP servers to receive the same active Codex thread/session identity that shell tool executions receive.

Environment

• Codex CLI: codex-cli 0.125.0
• Platform: macOS arm64
• MCP transport: local stdio

Related issues

• #8923 requested programmatic session id exposure.
• #14097 asks for stable per-agent metadata on tool/subprocess invocation.
• #4180 shows MCP server subprocess environments can differ from normal shell environments.
• #4222 mentions CODEX_WORKSPACE_ROOT being injected at tool-call time, which looks similar to the observed CODEX_THREAD_ID behavior.