[macOS 26.803] SSH-connected host cannot resume some threads locally; orphan app-server blocks Remote pairing with 409

What version of the ChatGPT/Codex desktop app are you using?

Both Macs:

• ChatGPT desktop: 26.803.61601
• Build: 6396
• Bundled Codex CLI/app-server: 0.147.0-alpha.6.5

What platform are you using?

Both machines:

• macOS 27.0 (26A5406e)
• Apple Silicon (arm64)

Topology:

• Controller Mac: uses ChatGPT Desktop > Settings > Connections > SSH to connect to the other Mac.
• Target Mac: also runs ChatGPT Desktop locally and should be directly available through QR-based Remote Control.
• Both apps are signed in to the same ChatGPT account/workspace.
• A legacy ChatGPT Classic app is installed on the target, but it and its background helper were not running while this reproduced.

What issue are you seeing?

A Mac that has been used as a ChatGPT Desktop built-in SSH target can be left with an SSH-started codex app-server that conflicts with the target Mac's local ChatGPT Desktop app.

The failure has two related user-visible symptoms:

1. Thread access becomes frontend-dependent.
   • Threads previously opened locally on the target can be resumed through built-in SSH after the target desktop app exits.
   • Some threads opened or resumed through built-in SSH cannot later be opened/resumed from the target's local desktop app while the SSH-created app-server remains.
   • This feels like the SSH runtime retains ownership or path/runtime context after the controller UI disconnects.
2. Direct Remote Control setup on the target is blocked.
   • The target first showed:
     • Unable to enable Remote Control. Make sure only one ChatGPT instance is running.
   • A later attempt showed:
     • Unable to get pairing code: Remote control failed to connect.
   • Target-side logs repeatedly reported:

WARN codex_app_server_transport::transport::remote_control::websocket
failed to connect to app-server remote control websocket:
HTTP error: 409 Conflict
body: {"detail":"Remote app server already online"}
reconnect_attempt=<n>

During the failure, the target had both a desktop-owned app-server and a separate background Unix-socket app-server:

/Applications/ChatGPT.app/.../codex app-server --listen stdio://
~/.local/bin/codex app-server --listen unix://

The Unix-socket process had PPID 1. A sanitized codex doctor --json summary for it reported:

background server is running
mode: ephemeral
pid file: missing
settings: missing
control socket: ~/.codex/app-server-control/app-server-control.sock

The local state and log databases passed integrity checks. This does not look like transcript/database corruption.

Observed sequence

This is the observed sequence; I have not yet reduced it to a fully deterministic single-command reproducer.

1. On the target Mac, open and use several project threads in the local ChatGPT desktop app.
2. Quit the target's local ChatGPT desktop app.
3. From the controller Mac, add/enable the target under Settings > Connections > SSH.
4. Open/resume project threads on the target through the built-in SSH connection.
5. Disconnect SSH and quit ChatGPT Desktop on the controller.
6. Relaunch ChatGPT Desktop locally on the target.
7. Attempt to open/resume threads that were used over SSH and enable Control this Mac / obtain a QR pairing code.
8. Some SSH-used threads fail to open locally, and Remote Control setup/reconnect logs repeated 409 Remote app server already online.
9. Inspecting the target shows an SSH/background app-server --listen unix:// alongside the local desktop app-server.

Recovery that worked temporarily

1. Fully quit ChatGPT Desktop on the controller Mac, not only close its window.
2. Disconnect the built-in SSH connection.
3. Terminate the exact SSH-owned proxy/app-server on the target.
4. Restart ChatGPT Desktop on the target.

After this cleanup, the target desktop could take ownership again and QR Remote setup could connect. The conflict can recur when an SSH/background app-server reappears.

Expected behavior

• Disconnecting or quitting a ChatGPT Desktop built-in SSH connection should cleanly stop its SSH proxy and ephemeral remote app-server, unless a managed daemon is intentionally configured.
• If a remote app-server already exists, the target's local desktop app should safely attach/take over or show which connection owns it and offer a supported disconnect action.
• A thread should remain openable from the target's local desktop app after it was opened through built-in SSH.
• QR Remote pairing should not be blocked indefinitely by a ghost/stale app-server connection.
• codex doctor should identify the owning frontend/session for a live Unix-socket app-server instead of reporting an ephemeral server with no PID/settings metadata.

Related issues

• #24542 — Desktop SSH proxy can keep an unmanaged app-server alive/respawn it.
• #31983 — idle SSH remote threads fail after restarting the connection.
• #28862 — stale Remote Control enrollment/app-server returns 409 and lacks a supported takeover path.
• #32321 — an orphaned desktop app-server can keep the Remote Control WebSocket and cause 409.

The distinct part here is the same macOS target also running ChatGPT Desktop locally: SSH-created runtime ownership makes thread access asymmetric and blocks direct QR Remote pairing on the current 26.803 build.

User feedback: SSH-owned Linux thread cannot continue locally

• Type: External — @koume3003, September 9.
• User reports (translated from Japanese): Opening a Linux workstation project from Mac Desktop over SSH leaves the same thread “ロック中” (“locked”) in the workstation's local Desktop, preventing local continuation.
• The reporter attributes this to the SSH-started app-server holding the writer lock. While the remote connection remains active, stopping that server triggers automatic reconnection and lock reacquisition. They therefore use separate local/remote threads, losing continuity of conversation and work.
• Request: A shared app-server for local Desktop, CLI and SSH clients, or explicit lock release/handoff so the same thread can continue locally.
• Relationship: Related SSH/local ownership feedback, not a confirmed duplicate or common root cause. This report does not establish an orphaned server after disconnect, and supplies no build, diagnostics or evidence of history deletion.

Start by reproducing the observed SSH/local sequence, then run codex doctor --json and inspect the target's app-server processes, Unix socket, and Remote Control logs for the repeated 409. Compare the desktop-owned and SSH/background servers, using related issues #24542, #28862, and #32321 for context. Done means the SSH-owned server is cleaned up or handed off after disconnect, local threads remain usable, and QR pairing is no longer blocked.