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

• https://github.com/openai/codex/issues/19744
• https://github.com/openai/codex/issues/20636
• https://github.com/openai/codex/issues/19201
• https://github.com/openai/codex/issues/17394
• https://github.com/openai/codex/issues/19109