Desktop Connections launches remote app-server with scrubbed env and leaves a stale backend that local CLI later reuses

[EateralSpirial]

Summary

When Codex Desktop on Windows uses Connections to a Linux host, the remote codex app-server --listen unix:// starts with a scrubbed environment (effectively only HOME, PATH, and SHELL, missing proxy and other shell env vars). After the connection is closed, that backend remains running and later local codex CLI sessions on the Linux host can reuse the same stale backend/socket, so the interactive shell environment and the actual app-server environment diverge.

Why this is a problem

• shell_environment_policy.inherit = "all" only affects subprocesses launched by Codex, not the app-server startup environment.
• Remote connections are documented as using the connected host for shell commands, tools, MCP, and skills, so users reasonably expect the connected host environment model to be consistent.
• In practice, Connections starts a backend that does not inherit the host shell environment, and the stale backend can continue affecting later local CLI sessions.

Observed behavior

On the Linux host:

• Interactive shell contains proxy env vars such as http_proxy, https_proxy, all_proxy.
• Foreground codex resume sees those env vars.
• The codex app-server --listen unix:// launched through Desktop Connections does not.
• OpenAI Docs MCP (https://developers.openai.com/mcp) then fails from the backend path.
• Closing the desktop connection does not restore behavior because the stale backend remains running and local CLI later reuses it.

Example process environment on the host:

• codex resume process env contains HTTP_PROXY, HTTPS_PROXY, ALL_PROXY
• codex app-server --listen unix:// process env contains only HOME, PATH, SHELL

Expected behavior

One of the following should be supported:

1. Desktop Connections should start the remote app-server with the host login shell environment, or
2. Desktop Connections should support explicit remote app-server env injection / a documented remote env file, or
3. Desktop Connections should isolate its backend state from normal local CLI state (separate CODEX_HOME, separate control socket, or similar), so stale remote backends are not reused by local CLI.

Environment

• Codex Desktop on Windows
• Remote connected host: Linux
• Host config has shell_environment_policy.inherit = "all"
• Remote MCP includes https://developers.openai.com/mcp
• Host uses local proxy env vars in normal shell workflows

Notes from docs

Relevant docs appear to imply:

• Remote connections use the connected host for shell commands, tools, MCP, and skills
• shell_environment_policy is about subprocess env handling
• Desktop apps / IDE extensions may not inherit shell env vars, which matches the observed scrubbed backend startup

The main regression here is not only env scrubbing at startup, but also that the stale backend remains active and later local CLI sessions can reuse it.

Related issues

• Local CLI silently reuses stale Remote Control app-server, causing conda env mismatch #28913
• Codex Desktop remote proxy respawns unmanaged app-server and blocks daemon bootstrap #24542
• Codex Desktop does not use the Windows system proxy for the codex process it launches inside WSL2 #15447
• Windows Codex Desktop stdio MCP child process does not inherit user env vars for mcp-remote header substitution #24362

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Local CLI silently reuses stale Remote Control app-server, causing conda env mismatch #28913

Powered by Codex Action

[EateralSpirial]

Follow-up with a narrower diagnosis from the affected machine.

What I confirmed locally:

• The Windows Codex Desktop SSH connection authenticates successfully. The key actually used is the one with fingerprint SHA256:4WdnNqJ1Rt0WX+G55TjIWwKuLm0LcTp9ZK3O+kmRMIQ.

• The Desktop remote command starts processes like:

  /bin/sh -c '... PATH="${CODEX_INSTALL_DIR:-$HOME/.local/bin}:$PATH"; export PATH; codex app-server proxy'

  and also starts codex app-server --listen unix:// through CODEX_REMOTE_PAYLOAD.

• Those processes were not receiving the environment from my normal interactive shell. Before the workaround, /proc/<app-server>/environ only had a small SSH/PAM environment such as HOME, PATH, SHELL, locale/session vars, and no http_proxy / https_proxy / all_proxy / no_proxy values.

• My normal interactive shell did have those variables, and network access to https://developers.openai.com/ depended on them. The scrubbed app-server environment caused the Developers Docs MCP server to fail from the Desktop-launched backend.

• A stale ~/.codex/app-server-control/app-server-control.sock plus an orphaned codex app-server --listen unix:// can then make subsequent local CLI/app-server attempts reuse or conflict with the Desktop-launched backend.

Temporary local workaround I applied:

• Keep ~/.codex/config.toml as shell_environment_policy.inherit = "all", but do not hardcode proxy env vars in shell_environment_policy.set.
• Have my interactive shell write a small runtime snapshot file containing only proxy/CA variables.
• Add a transparent forced command for the specific Desktop SSH key. It sources that snapshot and then executes the original SSH_ORIGINAL_COMMAND unchanged.

After restarting the orphaned app-server/proxy processes, the new Desktop-launched processes now show the expected proxy variables in /proc/<pid>/environ, including http_proxy, https_proxy, all_proxy, no_proxy and uppercase variants.

The product gap remains: Desktop Connections says it starts the remote Codex app server using the remote user's login shell, but in this setup the effective environment is not the user's working shell environment. There also does not appear to be a documented, first-class way to configure environment inheritance or per-connection env for SSH-host app-server startup without using SSH forced-command wrappers or global OS-level environment files.

[ZiyiGaoCN]

Nice workaround! Codex itself kept suggesting approaches based on setting environment variables globally, which would have had a much larger blast radius.