Remote SSH: support session-attached app-server transport for hosts that do not allow detached background processes

Open 💬 0 comments Opened Jun 5, 2026 by axelcursive

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:

  1. Codex Desktop connects over SSH.
  2. It starts codex app-server --listen unix://....
  3. The bootstrap SSH command exits.
  4. The app-server/socket is no longer available.
  5. 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 proxy able 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.

View original on GitHub ↗