Repository navigation
Desktop Connections launches remote app-server with scrubbed env and leaves a stale backend that local CLI later reuses #29138
Description
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,
Connectionsstarts 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 resumesees those env vars. - The
codex app-server --listen unix://launched through DesktopConnectionsdoes 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 resumeprocess env containsHTTP_PROXY,HTTPS_PROXY,ALL_PROXYcodex app-server --listen unix://process env contains onlyHOME,PATH,SHELL
Expected behavior
One of the following should be supported:
- Desktop
Connectionsshould start the remote app-server with the host login shell environment, or - Desktop
Connectionsshould support explicit remote app-server env injection / a documented remote env file, or - Desktop
Connectionsshould isolate its backend state from normal local CLI state (separateCODEX_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_policyis 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
Activity
github-actions commentedon Jun 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
EateralSpirial commentedon Jun 19, 2026
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://throughCODEX_REMOTE_PAYLOAD.Those processes were not receiving the environment from my normal interactive shell. Before the workaround,
/proc/<app-server>/environonly had a small SSH/PAM environment such asHOME,PATH,SHELL, locale/session vars, and nohttp_proxy/https_proxy/all_proxy/no_proxyvalues.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.sockplus an orphanedcodex 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:
~/.codex/config.tomlasshell_environment_policy.inherit = "all", but do not hardcode proxy env vars inshell_environment_policy.set.SSH_ORIGINAL_COMMANDunchanged.After restarting the orphaned app-server/proxy processes, the new Desktop-launched processes now show the expected proxy variables in
/proc/<pid>/environ, includinghttp_proxy,https_proxy,all_proxy,no_proxyand 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 commentedon Jun 23, 2026
Nice workaround! Codex itself kept suggesting approaches based on setting environment variables globally, which would have had a much larger blast radius.