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

Resolved 💬 2 comments Opened Aug 9, 2026 by wanziyaofaya Closed Aug 9, 2026
💡 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.

  • #37355

Powered by Codex Action

wanziyaofaya · 19 days ago

Refiled from the intended GitHub account as #37690. Closing this issue as a duplicate.