›_ Codex Issues
Codex Issues / #37209

Codex stdio MCP subprocess omits TMUX/TMUX_PANE, breaking tmux-aware tools

Open 💬 2 comments Opened Aug 6, 2026 by srobinson

What version of Codex CLI is running?

codex-cli 0.146.0

What subscription do you have?

ChatGPT subscription. This appears independent of account tier.

Which model were you using?

gpt-5.6-sol. The subprocess environment construction is model independent.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What terminal emulator and version are you using?

tmux 3.7b, with TERM=screen-256color. Both TMUX and TMUX_PANE are present in the parent Codex process.

Codex doctor report

Not included because the controlled A/B below isolates the stdio MCP child environment.

What issue are you seeing?

When Codex is launched inside tmux, its stdio MCP child processes do not receive TMUX or TMUX_PANE by default.

A controlled fresh-session A/B used the same CLI, model, stdio MCP process, working directory, and tool call:

  • Default MCP configuration: process environment inspection showed no TMUX or TMUX_PANE, and the tmux-dependent operation failed.
  • env_vars = ["TMUX", "TMUX_PANE"]: the same operation succeeded and its temporary tmux resource was removed successfully.

The MCP server initialized and the native MCP tool call reached it in both runs. The child-process environment was the only changed input.

What steps can reproduce the bug?

  1. Start Codex from inside tmux and confirm variable presence without printing values:
test -n "$TMUX" && echo TMUX=present
test -n "$TMUX_PANE" && echo TMUX_PANE=present
  1. Configure a stdio MCP server with a tool that reports the presence of those variables or performs an operation against the current tmux session.
  2. Call the tool through Codex. Observe that the child process has neither variable.
  3. Add explicit passthrough:
[mcp_servers.example]
command = "/path/to/server"
env_vars = ["TMUX", "TMUX_PANE"]
  1. Restart Codex and repeat. The child receives both variables and the operation succeeds.

What is the expected behavior?

Tmux-aware stdio MCP servers should have a clear supported path to the terminal context in which Codex is running. Reasonable fixes include forwarding TMUX and TMUX_PANE by default when present, or surfacing a startup or doctor diagnostic that recommends per-server env_vars passthrough.

This report does not request unrestricted inheritance of the parent environment.

Additional information

In rust-v0.146.0, the stdio launcher calls env_clear() and rebuilds the MCP child environment through create_env_for_mcp_server; DEFAULT_ENV_VARS omits TMUX and TMUX_PANE:

Related environment allowlist reports:

  • #19023 documents explicit env_vars passthrough for secret-manager session state.
  • #29124 covers stripped proxy and CA variables.

This is separate from #32101. Native MCP routing succeeded in both sides of this A/B; only the child process tmux context changed.

View original on GitHub ↗

2 Comments

ded-furby · 22 days ago

Thanks for the report. Quick reproducibility check: does this happen only for tools launched via the dedicated MCP subprocess path, and can you confirm whether both TMUX and TMUX_PANE are missing together? If you can paste sanitized output from ps eww ... codex or startup env dump, that would make it easier to identify a regression point.

srobinson · 22 days ago

Yes, this reproduces specifically for stdio MCP child processes, and both variables are missing together.

In the parent Codex process, a sanitized environment check shows:

TMUX=<present>
TMUX_PANE=<present>
TERM=<present>
PWD=<present>

For the MCP child processes launched by Codex, the same check shows:

TERM=<present>
PWD=<present>

TMUX and TMUX_PANE are both absent. The MCP servers initialize and respond normally; only the inherited tmux context is missing. Explicitly adding env_vars = ["TMUX", "TMUX_PANE"] restores the expected behavior.