Remote Control: target node_repl launches with controller CODEX_HOME env despite correct target config

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.602.30954 • Released Jun 5, 2026

Current target-machine diagnostics show:

Codex CLI on target Device B: 0.137.0-alpha.4
Codex Desktop originator: Codex_Desktop
Chrome plugin build seen in node_repl env/config: 26.602.30954

What subscription do you have?

Plus

What platform is your computer?

Target Device B:

Darwin arm64 macOS 26.5.1

Topology:

Device A: desktop/laptop Remote Control controller
  CODEX_HOME: /Users/<controller-user>/.codex

Device B: controlled target running this Codex Desktop thread
  CODEX_HOME: /Users/<target-user>/.codex

Negative control: using the mobile client against the same target Device B does not reproduce this failure.

What issue are you seeing?

In a Remote Control session, a resumed/old thread on the controlled target machine launches the node_repl MCP server with CODEX_HOME and related MCP env from the desktop/laptop controller machine.

The failing node_repl process is launched on Device B, but its MCP launch environment contains Device A paths. This breaks the Chrome plugin before any browser connection code can run.

This is not two active local macOS users on one machine. It appears to be a Remote Control / resumed-thread MCP launch environment leak from the controller device into the controlled target device.

It is also not a Chrome extension or native host install failure. The failure happens during node_repl startup because the MCP launch environment is wrong for the target machine.

Current direct repro from the affected thread:

node_repl kernel exited unexpectedly

node_repl diagnostics: {
  "kernel_status": "exited(code=1)",
  "kernel_stderr_tail": "WARNING: proceeding, even though we could not update PATH: CODEX_HOME points to \"/Users/<controller-user>/.codex\", but that path does not exist | Error: CODEX_HOME points to \"/Users/<controller-user>/.codex\", but that path does not exist"
}

That path is the controller desktop/laptop user home from Device A. It does not exist on the controlled target Device B, where the thread and node_repl process are actually running.

Target Device B config is correct. On Device B, ~/.codex/config.toml contains:

[mcp_servers.node_repl]
args = []
command = "/Applications/Codex.app/Contents/Resources/node_repl"
startup_timeout_sec = 120

[mcp_servers.node_repl.env]
NODE_REPL_NODE_PATH = "/Applications/Codex.app/Contents/Resources/node"
NODE_REPL_TRUSTED_CODE_PATHS = "/Users/<target-user>/.codex"
CODEX_HOME = "/Users/<target-user>/.codex"
BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab"
BROWSER_USE_CODEX_APP_VERSION = "26.602.30954"
CODEX_CLI_PATH = "/Applications/Codex.app/Contents/Resources/codex"

codex doctor --json on Device B reports:

config.load: ok
  CODEX_HOME: /Users/<target-user>/.codex
  config.toml parse: ok
  mcp servers: 1

mcp.config: ok
  MCP configuration is locally consistent
  configured servers: 1
  stdio servers: 1

state.paths: ok
  CODEX_HOME: /Users/<target-user>/.codex (dir)

The only failing doctor check in this run was terminal.env because TERM=dumb; that appears unrelated.

Process inspection showed the target Desktop app-server parent process environment was clean (HOME=/Users/<target-user> and no controller CODEX_HOME), while the child node_repl process environment contained controller-device paths:

CODEX_HOME=/Users/<controller-user>/.codex
NODE_REPL_TRUSTED_CODE_PATHS=/Users/<controller-user>/.codex
SKY_CUA_SERVICE_PATH=/Users/<controller-user>/.codex/plugins/cache/openai-bundled/computer-use/...
HOME=/Users/<target-user>

That points to Remote Control / thread MCP launch config injecting controller-device env into a target-device child process, not to the target parent process environment or target config.toml.

What steps can reproduce the bug?

Observed reproduction:

1. Device A is a desktop/laptop Remote Control controller with its own local CODEX_HOME.
2. Device B is a macOS Codex Desktop target with a different local CODEX_HOME.
3. From Device A, resume/open an existing Codex Desktop thread on Device B through Remote Control.
4. In that resumed thread, invoke the Chrome plugin: [@chrome](plugin://chrome@openai-bundled).
5. The Chrome skill attempts to use the required node_repl/js MCP tool.
6. node_repl starts on Device B but exits immediately because its env contains Device A CODEX_HOME.
7. Restarting Codex Desktop on Device B and retrying the same resumed thread does not clear the stale controller env.

Negative control:

1. Use the mobile client to access/control the same target Device B.
2. The stale controller CODEX_HOME failure does not occur in the observed setup.

Additional refresh evidence:

• Local logs on Device B contain RefreshMcpServers records from other/newer threads that correctly use /Users/<target-user>/.codex for node_repl.env.CODEX_HOME and NODE_REPL_TRUSTED_CODE_PATHS.
• The affected resumed thread did not receive a new verified RefreshMcpServers record after config repair/restart, and continued launching node_repl with the controller-device env.
• I attempted the app-server protocol method config/mcpServer/reload; it did not produce a verified refresh for this affected thread, and the next node_repl/js call still failed with the controller-device CODEX_HOME.

What is the expected behavior?

When Codex Desktop uses Remote Control to resume a thread on Device B, the MCP server launch environment for node_repl should be generated from Device B runtime/config, not Device A.

A resumed remote-control thread should not continue launching target-machine MCP servers with controller-machine CODEX_HOME after:

• Device B config.toml has the correct value;
• codex doctor on Device B sees the correct value;
• the Device B Desktop app-server parent environment is clean;
• Codex Desktop on Device B has been restarted.

The desktop/laptop Remote Control path should behave like the mobile client path: the target machine MCP runtime should use target-machine paths.

Additional information

Related but not exact matches:

• #21301: per-thread node_repl/js availability diverges. This issue is similar in that the failure is thread-specific, but here the tool is exposed and the child launch env comes from the wrong Remote Control side.
• #18522: old/resumed threads fail after restart while new threads work. This looks like the same session/runtime identity class, but the visible symptom here is controller-machine CODEX_HOME injected into target-machine node_repl.
• #20399: remote/project/thread host state can mix. This issue appears to be a similar host/runtime identity mix, but in Remote Control MCP launch env rather than SSH shared-home project indexing.
• #26011 / #26190: stale or regenerated MCP config/env breaks node_repl, but those reports focus on config contents or Windows paths. Here the target persisted config is correct and the wrong value appears only at runtime launch.
• #25361 / #26364: Chrome/node_repl bootstrap failures, but not this specific target config ok, target parent env ok, child MCP env from controller device case.

Impact: workflows that depend on logged-in Chrome automation on the controlled target machine are blocked in the affected resumed Remote Control thread from the desktop/laptop controller. Static Chrome checks can pass, but the MCP runtime exits before browser-client.mjs can call agent.browsers.get("extension").