[Windows Desktop] Older auto-connected SSH app-servers trigger unbounded app/installed loop and silent exits
What version of the Codex App are you using (From “About Codex” dialog)?
- Windows Store package:
OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0 - Desktop release from Sentry scope:
codex@26.803.41515 - Bundled local app-server:
codex-cli 0.147.0-alpha.6.5 - Auto-connected SSH app-servers:
0.144.1,0.144.5, and0.146.0
What subscription do you have?
Omitted because the failure occurs in the local/SSH app-server protocol path before any model request.
What platform is your computer?
Windows 11 Home, 10.0.26200, x64.
What issue are you seeing?
Codex Desktop repeatedly disappears/exits after running for roughly 13–35 minutes. There is no Windows Error Reporting crash record, Crashpad report, or resource-exhaustion event for the observed exits.
At startup, the Desktop app automatically connects to three SSH hosts discovered from the user's SSH configuration. Their app-server versions are older than the bundled local app-server. As soon as the remote connections become ready, both the primary renderer and the hidden avatarOverlay renderer begin issuing app/installed requests.
The older SSH app-servers reject that method:
response_routed ... errorCode=-32600 ... method=app/installed
Request failed ... Invalid request: unknown variant `app/installed`
The failures are interleaved with repeated app/list responses and continue without effective backoff.
One representative 19-minute Desktop session produced:
- 6,571
app/installedresponses - 2,827
unknown varianterrors - 1,351
app/listresponses - a maximum observed
pendingCountAfter=1369 - 8,508 log lines / approximately 11 MB across two rotated main-process log files
Some affected sessions end abruptly in the request loop. Other sessions record this shutdown sequence:
[browser-session-registry] IAB_LIFECYCLE removed browser session window
[IpcRouter] Socket error errorCode=EPIPE errorMessage="write EPIPE"
[AppServerConnection] app_server_connection.state_changed cause=stop_process ... hostId=local
[AppServerConnection] app_server_connection.state_changed cause=stop_process ... hostId=<remote SSH host>
Windows AppModel-Runtime then records the Codex AppX container being destroyed. The user sees the app window disappear and must launch it again.
This looks like a capability/version-mismatch loop: unsupported app/installed calls against older auto-connected SSH app-servers cause repeated Apps metadata refreshes, request accumulation, and eventually loss of the renderer/IPC connection or a silent Desktop shutdown.
What steps can reproduce the bug?
- Install Codex Desktop on Windows.
- Configure multiple SSH hosts that Codex discovers automatically.
- Ensure the remote hosts run older Codex app-server versions than the bundled Desktop app-server. The observed versions were:
- local:
0.147.0-alpha.6.5 - remote:
0.144.1,0.144.5, and0.146.0
- Launch Codex Desktop and allow it to auto-connect to all discovered SSH hosts.
- No remote task needs to be started. Within seconds, inspect the Desktop main-process log for repeated
app/installed-32600responses and interleavedapp/listtraffic. - Leave the app open. In the observed runs, the request count and pending queue grow continuously and the app eventually disappears/exits.
The exit timing is not deterministic, but the request loop reproduces immediately after startup while the version-mismatched SSH connections are active.
What is the expected behavior?
- The Desktop client should negotiate app-server capabilities per host.
- After the first unsupported
app/installedresponse, it should use one bounded compatibility fallback, cache the result, and back off. - A hidden/prewarmed renderer should not repeatedly fetch Apps metadata.
- An incompatible remote host should be isolated and must not destabilize the local Desktop UI.
- Closing or losing an IPC/browser client should treat
EPIPEas a normal disconnect and should not terminate the entire app.
Additional information
This appears related to, but is not identical to:
- #37355 — the same
app/installed/app/listcompatibility loop over macOS Remote Control, primarily causing extreme network transfer - #35985 — Windows Desktop
IpcRouterEPIPE /write EOFfailure - #21774 — Windows Desktop silently closes/restarts without a crash artifact
The distinct case here is Windows Desktop with multiple automatically discovered direct SSH app-server connections, an unbounded pending-request queue, and repeated silent application exits.
Windows event logs showed no matching application crash or memory/resource-exhaustion event. SSH authentication and app-server initialization completed successfully before the loop began.
Raw logs are not attached because they contain local paths, SSH aliases, account metadata, and request identifiers. Sanitized excerpts or aggregate counts can be provided if maintainers specify the fields needed.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Confirming the same failure mode on macOS with a directly auto-connected SSH host, with OS-generated resource-violation evidence. This is not limited to Windows or to silent exits.
Environment
26.803.61601(build6396)26.810.41047; bundled CLI0.148.0-alpha.926.2, Apple Silicon M1 MacBook Pro, 16 GB RAMcodex-cli 0.139.0codex-cli 0.146.0Impact and evidence
The user noticed intermittent severe laptop heating after the Desktop update. The issue was not active during the initial live inspection, but macOS had generated two
ChatGPTresource diagnostics for the affected Desktop build:Both reports classify the event as
disk writesand identify the Desktop main process's Node/libuv write path as the heaviest target-process stack. The retained Desktop logs were heavily rotated, with many files reaching the 10 MB rotation limit.Two affected Desktop sessions contained:
app/installedrequests in one sessionapp/installedrequests in another-32600 Invalid request: unknown variant app/installedAppServerConnection response_routedandelectron-message-handler Request failedrecordsunknown conversationevents from both the primary and hiddenavatarOverlayrenderersThis produced sustained write amplification and user-visible heat while no heavy local task was expected. Most users will not inspect Activity Monitor, temperatures, rotating application logs, or macOS resource diagnostics, so this failure can remain silent for hours.
Mitigation confirmed
Updating the SSH host from
0.139.0to0.146.0caused Desktop to restart the remote connection. After reconnection:app/installedcompleted successfully in 3 msunknown variant app/installedfailures appearedWhy this needs a product fix
A remote protocol-version mismatch must not silently enter an unbounded request/error/logging loop capable of writing multiple gigabytes and heating a laptop. Requiring users to infer that an auto-connected remote CLI needs a manual update is not an acceptable compatibility mechanism.
Please:
Raw logs and diagnostic files are not attached because they can contain local paths, SSH metadata, account identifiers, and conversation IDs. Sanitized excerpts from the macOS resource reports can be provided if maintainers specify what they need.