Remote SSH: support session-attached app-server transport for hosts that do not allow detached background processes
Summary
Codex Desktop Remote SSH currently appears to rely on starting a remote codex app-server via a short-lived SSH bootstrap command, then reconnecting to it through a Unix socket.
This breaks on SSH environments where background processes started by the bootstrap session do not survive after that SSH session exits.
It would be useful to have an alternative Remote SSH mode where the app-server stays attached to the active SSH session, similar to how Remote-SSH style tools keep their remote server tied to the connection.
Current behavior
Remote SSH fails even though normal SSH works and codex is available on the remote PATH.
The observed flow seems to be:
- Codex Desktop connects over SSH.
- It starts
codex app-server --listen unix://.... - The bootstrap SSH command exits.
- The app-server/socket is no longer available.
- The subsequent proxy/connect step fails.
This can surface as a generic SSH connection failure or an app-server/socket connection failure.
Expected behavior
Codex Desktop should provide a Remote SSH transport mode that does not require a detached background process to survive after the bootstrap SSH session exits.
Possible approaches:
- Start
codex app-server --listen stdio://and keep that SSH session open as the transport. - Add a session-attached Remote SSH mode, similar in spirit to VS Code/Cursor Remote-SSH.
- Make
codex app-server proxyable to start or attach to the listener in the same SSH session when the socket is missing. - Expose a setting such as:
[remote_ssh]
app_server_mode = "session-attached"
or a per-host equivalent.
Why this matters
Some SSH environments intentionally clean up detached/background processes when the SSH session that created them exits. In those environments, the current detached app-server bootstrap model is fragile even though interactive SSH sessions and command execution work normally.
A session-attached mode would make Remote SSH usable in more constrained SSH environments without requiring users to run a persistent daemon or manually keep a background process alive.
Additional context
The existing app-server already supports stdio transport:
codex app-server --listen stdio://
The CLI also exposes remote app-server connection options, so this seems mostly like a Desktop Remote SSH transport-mode gap rather than a missing server capability.