Remote SSH repeatedly reconnects and fails to resume or create chats after app-server/proxy state diverges

What version of the Codex App are you using (From “About Codex” dialog)?

26.903.9818.0 (x64)

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop intermittently becomes unable to load, resume, or create chats in a Remote SSH project. The UI repeatedly shows one or more of these errors:

Reconnecting 1/5 ... 5/5
failed to resume chat
error creating chat
couldn't get worktree states

Local chats and projects on another remote host remain usable. The affected Linux host is reachable over SSH, git status is fast, and CPU, memory, and I/O are not saturated when the problem occurs.

During the latest incident, a persistent app-server had been alive for about two days while its proxy had been recreated only a few minutes earlier:

app-server --listen unix://    started 2026-09-08 20:52:38
app-server proxy               started 2026-09-10 22:44:25

The app-server log contained:

Error: app-server control socket is already in use at ~/.codex/app-server-control/app-server-control.sock

Remote thread listing could take around 30 seconds. A thread read could report No Codex thread found even though the rollout still existed on disk. Archiving large threads reduced the amount of state but did not prevent newly created small chats from failing.

Terminating only the verified Codex app-server/proxy processes and removing the stale control socket after those processes exited restored the project immediately. After Codex Desktop created a fresh app-server, proxy, and socket, the previously failing thread could be read in about two seconds. The failure has returned after earlier restarts, so the restart is only a temporary recovery.

What steps can reproduce the bug?

The issue is intermittent but has reproduced multiple times with the following sequence:

1. On Codex Desktop for Windows, open a project hosted on Linux through Remote SSH.
2. Use several chats in that remote project across multiple days.
3. Run one or more long turns with tool calls. The problem can also occur after a compact operation or while background/subagent activity is present.
4. Allow the SSH/app-server proxy connection to disconnect and reconnect at least once.
5. Open an existing remote chat or create a new chat in the same project.
6. Observe repeated Reconnecting messages, slow remote thread listing, and eventually failed to resume chat, error creating chat, or couldn't get worktree states.

Example affected session ID:

01a08ba4-4065-7cf1-b756-ef6950b90f6e

The issue also occurs with a newly created small chat after large chats have been archived, so chat size appears to amplify the recovery cost but is not required to trigger the failure.

What is the expected behavior?

• Reconnecting the Remote SSH proxy should either reattach to the existing app-server or replace it atomically.
• Codex Desktop should reconcile authoritative thread and turn state after reconnecting.
• A stale or occupied control socket should be detected and recovered without leaving the project partially connected.
• thread/list and thread/resume operations after reconnect should be bounded or coalesced rather than blocking the entire remote project.
• Failure to hydrate one chat should not prevent other existing chats from loading or prevent a new chat from being created.
• Existing rollout data should remain loadable after a transient transport disconnect.

### Additional information

### Remote environment

- Remote OS: Ubuntu Linux, kernel `5.15.0-119-generic`, x86_64
- Remote Codex CLI: `codex-cli 0.153.4`
- Codex managed runtime: Node.js 22.x in the app-server process environment
- Connection: Codex Desktop Remote SSH
- Workspace: Git repository on a local Linux filesystem
- Free workspace/root filesystem space during the incident: approximately 186 GiB
- Proxy variables inherited by app-server: `HTTP_PROXY`, `HTTPS_PROXY`, and `ALL_PROXY` pointed to a functioning loopback HTTP proxy

Hostnames, usernames, IP addresses, repository names, and chat content are redacted.

### Recovery evidence

Before recovery, the control socket had the same timestamp as the two-day-old app-server. The current proxy was only a few minutes old, and the log reported that the control socket was already in use.

Recovery procedure:

1. Preserve the existing app-server log.
2. Identify the exact user-owned Codex app-server and proxy process trees.
3. Send `SIGTERM` only to those Codex processes.
4. Confirm that the old app-server has exited.
5. Remove only the stale `app-server-control.sock`.
6. Allow Codex Desktop to bootstrap a fresh app-server and proxy.

After recovery:

```text
app-server --listen unix://    started 2026-09-10 22:49:24
app-server proxy               started 2026-09-10 22:49:29
app-server-control.sock        created 2026-09-10 22:49

The new app-server log was clean. Remote thread listing succeeded, and reading the latest three turns from the affected session completed in about two seconds.

No rollout, SQLite database, session index, repository file, or project artifact was deleted.

Related reports

• https://github.com/openai/codex/issues/23919
• https://github.com/openai/codex/issues/19608
• https://github.com/openai/codex/issues/18860
• https://github.com/openai/codex/issues/24475
• https://community.openai.com/t/codex-desktop-remote-ssh-threads-show-only-the-initial-response-although-rollout-jsonl-contains-the-completed-turn/1392366

The symptoms appear consistent with a Remote SSH app-server reconnection/state-reconciliation problem: a long-lived app-server survives while proxy processes are recreated, after which remote hydration becomes slow or fails until the app-server and stale socket are replaced together.

Start by tracing Remote SSH proxy reconnect handling, app-server control-socket ownership, and the thread/list and thread/resume operations described in the report. Done means reconnects recover or replace the app-server safely, stale sockets do not leave the project partially connected, and one failed chat does not block listing or creating others.