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

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

• #28913
• #24542
• #15447
• #24362