Windows Desktop remote SSH sessions freeze during app-server reconnect/list/resume

Open 💬 4 comments Opened May 21, 2026 by 35ujq435jq45

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Windows Desktop remote SSH sessions freeze during app-server reconnect/list/resume

Summary

Codex Windows Desktop becomes unresponsive for tens of seconds when using a remote Linux workstation over SSH. The strongest evidence points to the remote app-server reconnect/recovery path: after the SSH-proxied app-server transport drops or reconnects, Desktop performs expensive thread/list and thread/resume work across multiple long conversations. During these freezes, system CPU/RAM/disk/GPU are not saturated.

This looks related to remote SSH/app-server code=1006 reports, but the failure mode is slightly different: the remote app-server/proxy can successfully start and report version 0.132.0, yet Desktop still freezes during recovery and long-thread resume/list work.

Environment

App: Codex Windows Desktop
Desktop package versions observed: OpenAI.Codex_26.519.2081.0, later OpenAI.Codex_26.519.2736.0
Remote: Linux workstation over Windows OpenSSH
Remote app-server version reported by Desktop logs: 0.132.0
Usage pattern: multiple Codex Desktop windows/chats connected to the same remote host, including long conversation histories
Local Windows chats do not show the same freezes

Observed Pattern

Representative sequence from Desktop logs:

app_server_connection.closed code=1006
ssh_websocket_v0.proxy_command_failed ... signal=SIGTERM
app_server_connection.reconnect_started
ssh_websocket_v0.ensure_remote_app_server
codex_version_probe
app_server_bootstrap
proxy_command_starting
Current reported app-server version: 0.132.0
websocket_reconnect_marked_threads_needing_resume
thread/resume
maybe_resume_success

Common repeated warnings/errors in the same windows:

Failed to resolve git root: Failed to locate git executable in PATH
unsupported feature enablement `auth_elicitation`
goals feature is disabled
Codex app-server is not available

Remote app-server log also showed:

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

Capture Evidence

I have local capture bundles available if useful. Highlights:

Capture A

Caught two remote websocket drops:
app_server_connection.closed code=1006
app_server_connection.closed code=1006
Recovery included long resumes:
128-turn chat: thread/resume about 19.5s, later about 50.4s
200-turn chat: thread/resume about 19s
Resource state during freeze:
Codex private memory peak: about 7.1 GB
Codex working set peak: about 5.5 GB
System CPU peak: about 21.9%
Free RAM minimum: about 33.8 GB
Disk peak: about 2.7%
Codex GPU peak: about 13.6%
DWM GPU peak: about 8.0%
Capture-window counts:
thread/resume: 5
maybe_resume_success: 5
websocket_reconnect_marked_threads_needing_resume: 12
websocket_reconnect_recovery_start/done: 6 / 6

Capture B

Caught one drop:
app_server_connection.closed code=1006
SSH app-server proxy failed with SIGTERM
reconnect started
app-server version reported as 0.132.0
reconnect marked 2 streaming threads needing resume
Pre-drop sluggishness:
thread/list about 8.9s
thread/list about 9.3s
Recovery included:
130-turn chat: resume about 2.4s, then another about 16.0s
201-turn chat: resume about 19.0s
Resource state:
System CPU peak: about 17.9%
Free RAM minimum: about 32.9 GB
Disk peak: under 1%
Codex GPU peak: about 7.5%
DWM GPU peak: about 5.4%

Capture C

This was after the Desktop package updated to OpenAI.Codex_26.519.2736.0. It did not catch another explicit code=1006, but it caught the same expensive remote recovery/list/resume shape:

app_server_bootstrap succeeded
proxy_command_starting
app-server version 0.132.0
websocket_reconnect_recovery_start
websocket_reconnect_marked_threads_needing_resume conversationCount=19 markedCount=0
thread/resume durationMs=23545 for a 204-turn conversation
thread/list durationMs=17142
thread/list durationMs=14932
thread/list durationMs=25191
thread/list durationMs=11819
maybe_resume_success markedStreaming=true turnCount=204

Later in the same capture:

thread/resume durationMs=468, turnCount=1
thread/resume durationMs=2706, turnCount=132
thread/list durationMs=8312
thread/list durationMs=10246

Resource state in this capture:

Codex private memory peak: about 845.8 MB
Codex working set peak:    about 964.9 MB
System CPU peak:           about 21.0%
Free RAM minimum:          about 35.5 GB
Disk peak:                 about 0.58%
GPU sample peak:           about 1.83%

Expected Behavior

Codex Desktop should remain responsive while reconnecting to a remote SSH app-server. Reconnect should not trigger duplicated or UI-blocking thread/resume / thread/list work across multiple long conversations.

Actual Behavior

When the SSH-proxied app-server websocket closes or the remote connection recovers, Desktop can become unresponsive while it performs long thread/list and thread/resume calls. These calls can take 19-50s for long chats, and multiple list/resume calls appear clustered during recovery.

Suspected Area

Remote SSH websocket reconnect/recovery path in Codex Desktop
Deduplication/scheduling of websocket_reconnect_marked_threads_needing_resume
UI responsiveness during long thread/resume and thread/list
Diagnostics around proxy SIGTERM and app-server control socket reuse

Related Issues

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

#22991
#23235
#22411

Powered by Codex Action

35ujq435jq45 · 3 months ago

Thanks for the duplicate suggestions. I reviewed these and agree this is closely related to #23235 and #22411, especially around slow thread/list / thread/resume.

I am going to leave this open for now because the distinguishing part here is the remote SSH app-server reconnect/recovery path: captures show app_server_connection.closed code=1006, SSH app-server proxy termination with SIGTERM, reconnect/recovery, and then clustered long thread/list / thread/resume calls across multiple long remote conversations. The Desktop UI becomes unresponsive even though CPU/RAM/disk/GPU are not saturated.

If maintainers prefer one tracking issue, I am happy for this to be closed as a duplicate of the most appropriate one, but I wanted to preserve the remote SSH reconnect evidence since it may point to a separate scheduling/recovery issue on top of the general slow list/resume behavior.

35ujq435jq45 · 3 months ago

Update: freezing improved after the thread-list/index workaround, but one freeze remains

After applying the #24510-style workaround on the remote host, freezing is noticeably better. In the latest freeze capture, the old thread/list path does not look like the direct trigger anymore.

New capture:

Capture folder: C:\Users\mseebold\codex-freeze-capture-20260526-114733
Zip: C:\Users\mseebold\codex-freeze-capture-20260526-114733.zip
Codex Desktop package: OpenAI.Codex_26.519.5221.0

Windows logged a real app hang:

2026-05-26 11:47:48 AM MDT
Windows Error Reporting
Event Name: AppHangTransient
P1: Codex.exe

The Desktop log has a matching 24.259 second gap:

2026-05-26T17:47:23.819Z info [browser-session-registry] IAB_LIFECYCLE ended browser use turn route conversationId=019dfdda-2450-7ae1-8284-73a6587fde24 turnId=019e6550-6874-7150-8412-7617e26fb377 windowId=1
2026-05-26T17:47:48.078Z info [devicecheck-attestation] DeviceCheck attestation unavailable deviceCheckLatencyMs=null durationMs=0 errorCode=1

Immediately after the app became responsive again, thread/list was relatively fast:

2026-05-26T17:47:49.929Z method=thread/list durationMs=8
2026-05-26T17:47:51.580Z method=thread/list durationMs=1659
2026-05-26T17:48:10.864Z method=thread/list durationMs=14
2026-05-26T17:48:12.485Z method=thread/list durationMs=1635

So I think the index workaround helped the thread/list issue, but this remaining freeze may be a separate Desktop/browser-use/sidebar lifecycle path. The hang starts immediately after:

IAB_LIFECYCLE ended browser use turn route

for a large/old browser-use conversation:

conversationId=019dfdda-2450-7ae1-8284-73a6587fde24

Other notes from the same capture:

Local state_5.sqlite is small: ~848 KB, 13 threads.
Local logs_2.sqlite is large: ~490 MB.
Main Codex process and renderer were both around ~1.6 GB private memory.
The process had been running since 2026-05-23.
No app_server_connection.closed code=1006 or websocket reconnect occurred at the actual hang time.
Git metadata warnings are still noisy because the running Desktop environment does not appear to have git on PATH, despite Git being installed.

Current hypothesis: #24510-style indexing mitigates the slow thread/list freeze, but there is still a residual freeze path around browser-use route cleanup / sidebar lifecycle for large conversations.

w2jmoe · 3 months ago

Interesting report 👀

What stands out is that the machine itself doesn't appear resource-saturated during the freeze.

That makes this feel less like a raw performance problem and more like a recovery/scheduling orchestration issue during reconnect.

Especially these patterns:

repeated thread/list + thread/resume clustering
long conversation recovery
multiple windows sharing the same remote host
reconnect marking many conversations simultaneously

Feels possible the recovery path is doing too much synchronous or duplicated work after transport restoration.

The “resume storm” effect after reconnect is probably worth investigating separately from the websocket disconnect itself.

Also interesting that local chats don't reproduce it — that strongly points toward the SSH/app-server recovery layer rather than rendering/UI alone.

Very detailed diagnostics here 👍