Expose current thread ID to local stdio MCP servers

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.

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

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

1. 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.