Codex Remote SSH auto-reconnect restarts intentionally stopped GitHub Codespaces

What variant of Codex are you using?

Codex Desktop

What feature would you like to see?

Summary

When Codex Desktop is connected to a GitHub Codespace through Remote SSH, stopping the Codespace intentionally does not keep it stopped.

Codex automatically attempts to reconnect to the remote host, which causes GitHub Codespaces to start the Codespace again.

As a result, the only reliable way I currently have to stop the Codespace is to manually disable the SSH remote connection in Codex settings before stopping it, and then enable it again the next time I want to work.

This adds unnecessary friction and, more importantly, can cause unintended Codespaces compute usage.

Environment

• Codex Desktop
• Remote SSH
• GitHub Codespaces
• Codespace accessed through its SSH configuration
• GitHub CLI used to explicitly stop the Codespace

Steps to reproduce

1. Create or start a GitHub Codespace.
2. Configure it as a Remote SSH connection in Codex Desktop.
3. Open a project through that remote connection.
4. Finish working but leave Codex Desktop open.
5. Explicitly stop the Codespace:

gh codespace stop -c <codespace-name>

6. Observe the Codespace after the SSH connection goes down.

Actual behavior

Codex detects that the SSH connection was lost and automatically attempts to reconnect.

Because the target is a GitHub Codespace, that reconnect attempt causes the intentionally stopped Codespace to start again.

The effective behavior becomes:

User stops Codespace
        ↓
SSH connection closes
        ↓
Codex auto-reconnects
        ↓
Codespaces starts the environment again
        ↓
Codespace continues consuming compute

To actually leave the Codespace stopped, I currently have to:

1. Open Codex settings.
2. Disable the Remote SSH connection.
3. Stop the Codespace.
4. Later re-enable the Remote SSH connection when I need it again.

Expected behavior

Codex should provide a supported way to keep a Remote SSH host configured without automatically reconnecting to it after an intentional shutdown.

Possible solutions could include:

• An Auto reconnect toggle per remote host.
• A Disconnect / Pause connection action that does not remove or disable the remote configuration.
• Reconnect only while an active Codex task requires the remote.
• A retry limit followed by a disconnected state requiring explicit user action.
• Separate Enabled and Auto-connect settings.

For cloud development environments such as GitHub Codespaces, a particularly useful behavior would be:

Reconnect:
○ Always
● Only while needed by an active task
○ Never automatically

This would allow the native GitHub Codespaces idle timeout to work as intended.

Why this matters

For a normal SSH server, aggressive reconnect behavior is mostly an inconvenience.

For GitHub Codespaces and similar on-demand development environments, reconnecting has side effects: attempting an SSH connection can start billable compute resources that the user explicitly stopped.

This means Codex can unintentionally override the lifecycle decision made by the user.

Related issue

This appears related to:

• #35733 — Remote SSH auto-connect / repeated reconnection behavior and request for lazy connections.

However, this case has an additional consequence specific to on-demand cloud environments: the automatic reconnect can restart infrastructure that the user intentionally stopped.

Because of that, I believe supporting an explicit disconnected state or disabling automatic reconnect independently from the remote configuration would be useful.

Additional information

No response

Start by reproducing the behavior with the GitHub CLI command shown in the issue and review related issue #35733 for the existing Remote SSH reconnect design. Trace where Codex Desktop detects a lost SSH connection and initiates retries. Done means an intentionally stopped Codespace remains stopped without requiring the remote configuration to be disabled, with the chosen disconnected-state behavior covered by tests.