[Windows Desktop] Older auto-connected SSH app-servers trigger unbounded app/installed loop and silent exits

Open 💬 2 comments Opened Aug 9, 2026 by whisperLiang
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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, and 0.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/installed responses
  • 2,827 unknown variant errors
  • 1,351 app/list responses
  • 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?

  1. Install Codex Desktop on Windows.
  2. Configure multiple SSH hosts that Codex discovers automatically.
  3. 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, and 0.146.0
  1. Launch Codex Desktop and allow it to auto-connect to all discovered SSH hosts.
  2. No remote task needs to be started. Within seconds, inspect the Desktop main-process log for repeated app/installed -32600 responses and interleaved app/list traffic.
  3. 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/installed response, 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 EPIPE as 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/list compatibility loop over macOS Remote Control, primarily causing extreme network transfer
  • #35985 — Windows Desktop IpcRouter EPIPE / write EOF failure
  • #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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 19 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37689
  • #37355

Powered by Codex Action

zainazeem · 13 days ago

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

  • Affected ChatGPT/Codex Desktop: 26.803.61601 (build 6396)
  • Current Desktop checked afterward: 26.810.41047; bundled CLI 0.148.0-alpha.9
  • macOS 26.2, Apple Silicon M1 MacBook Pro, 16 GB RAM
  • Affected SSH app-server: codex-cli 0.139.0
  • Updated SSH app-server used for the successful mitigation: codex-cli 0.146.0

Impact 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 ChatGPT resource diagnostics for the affected Desktop build:

  • 2,147.90 MB of file-backed memory dirtied over 8,313 seconds (258.39 KB/s average)
  • 8,590.13 MB dirtied over 58,846 seconds (145.98 KB/s average)

Both reports classify the event as disk writes and 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:

  • 7,625 rejected app/installed requests in one session
  • 5,119 rejected app/installed requests in another
  • Repeated -32600 Invalid request: unknown variant app/installed
  • Thousands of paired AppServerConnection response_routed and electron-message-handler Request failed records
  • Additional unknown conversation events from both the primary and hidden avatarOverlay renderers

This 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.0 to 0.146.0 caused Desktop to restart the remote connection. After reconnection:

  • app/installed completed successfully in 3 ms
  • No new unknown variant app/installed failures appeared
  • No runaway log growth occurred during the verification window
  • Desktop CPU returned toward idle

Why 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:

  1. Negotiate app-server capabilities per connection.
  2. Cache an unsupported-method result and apply bounded fallback/backoff after the first rejection.
  3. Detect an incompatible remote CLI and show a clear update/disconnect prompt.
  4. Prevent hidden/prewarmed renderers from independently amplifying metadata polling.
  5. Bound or rate-limit repetitive error logging.
  6. Document minimum compatible remote CLI versions and acknowledge affected Desktop releases in release notes.

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.