What happened?
After a brief network interruption caused by the local Mac sleeping, a Supacode Remote SSH (Beta) terminal does not reliably reattach to its persistent remote session.
I have observed two failure modes:
- With Keeps SSH sessions alive across disconnects enabled, reconnection can loop with
No user exists for uid 501 and SSH exit 255.
- After disabling that option as a workaround, SSH reconnects successfully, but Supacode reports
Reconnected without a persistent session; starting a fresh shell. The terminal scrollback remains visible, but the running Codex process is gone.
I expected Supacode to reconnect and reattach to the existing remote zmx session so the running process survives the short disconnect.
The network and SSH endpoint recover normally: in the second mode, SSH reconnects after one second. Remote zmx logs show that affected sessions received an explicit kill rather than merely losing their client, which suggests the session cleanup/reconnect lifecycle is terminating a session that is still needed.
Steps to reproduce
- On a MacBook, open a repository on another Mac using Remote SSH (Beta), with Keeps SSH sessions alive across disconnects enabled.
- Start a long-running interactive process such as Codex in the remote terminal.
- Let the MacBook sleep briefly so the SSH/Tailscale connection drops, then wake it.
- Observe repeated SSH exit 255 reconnect attempts with
No user exists for uid 501.
- Disable Keeps SSH sessions alive across disconnects, reconnect, and repeat the short sleep/disconnect.
- SSH now reconnects, but Supacode falls back to a fresh shell instead of restoring the running process.
The exact sleep timing is intermittent, but this has happened repeatedly across multiple tabs in the same remote workspace.
Supacode version and build
0.10.8 (1785775286)
Latest published release checked on 2026-09-01: v0.10.8.
macOS version
- Local: macOS 26.5.1, Apple silicon
- Remote: macOS 13.7.8, x86_64
System locale
en_US@rg=nlzzzz
Mac hardware
MacBook Air, Apple M3, 16 GB
Relevant logs
Supacode terminal output:
Shared connection to remote host closed.
Connection failed (ssh exit 255). Retrying in 1s. Press Ctrl-C to stop.
Reconnected without a persistent session; starting a fresh shell.
Earlier persistent reconnect loop:
No user exists for uid 501
Connection failed (ssh exit 255). Retrying in 15s. Press Ctrl-C to stop.
Relevant remote zmx log lines from an affected session:
deleting socket file
kill received
shutting down daemon
sending SIGHUP to session process
Additional diagnostic detail:
Local zmx bundled with Supacode: 0.6.0
Remote /usr/local/bin/zmx: 0.7.0
The version mismatch may be relevant, but the clearest symptom is that the remote session receives a kill during the reconnect/cleanup sequence.
Before submitting
I am not currently planning to open a pull request.
What happened?
After a brief network interruption caused by the local Mac sleeping, a Supacode Remote SSH (Beta) terminal does not reliably reattach to its persistent remote session.
I have observed two failure modes:
No user exists for uid 501and SSH exit 255.Reconnected without a persistent session; starting a fresh shell.The terminal scrollback remains visible, but the running Codex process is gone.I expected Supacode to reconnect and reattach to the existing remote zmx session so the running process survives the short disconnect.
The network and SSH endpoint recover normally: in the second mode, SSH reconnects after one second. Remote zmx logs show that affected sessions received an explicit kill rather than merely losing their client, which suggests the session cleanup/reconnect lifecycle is terminating a session that is still needed.
Steps to reproduce
No user exists for uid 501.The exact sleep timing is intermittent, but this has happened repeatedly across multiple tabs in the same remote workspace.
Supacode version and build
0.10.8 (1785775286)
Latest published release checked on 2026-09-01: v0.10.8.
macOS version
System locale
en_US@rg=nlzzzz
Mac hardware
MacBook Air, Apple M3, 16 GB
Relevant logs
Supacode terminal output:
Earlier persistent reconnect loop:
Relevant remote zmx log lines from an affected session:
deleting socket file kill received shutting down daemon sending SIGHUP to session processAdditional diagnostic detail:
The version mismatch may be relevant, but the clearest symptom is that the remote session receives a kill during the reconnect/cleanup sequence.
Before submitting
ready.I am not currently planning to open a pull request.