VS Code Remote-SSH session resume hangs with app-server outbound queue full

VS Code Remote-SSH session resume hangs with app-server outbound queue full

What version of the IDE extension are you using?

Reproduced on both:

• openai.chatgpt 26.422.30944 stable
• openai.chatgpt 26.5422.30944 pre-release

The pre-release Remote-SSH extension bundle reports:

codex-cli 0.125.0-alpha.3

What subscription do you have?

ChatGPT Plus/Pro account via ChatGPT sign-in.

Which IDE are you using?

VS Code with Remote-SSH.

What platform is your computer?

• Local client: Windows 11
• Remote host: Ubuntu 24.04 LTS, VS Code Server under ~/.vscode-server
• Extension kind: workspace/remote extension, installed under ~/.vscode-server/extensions/openai.chatgpt-*-linux-x64

What issue are you seeing?

Opening an existing Codex session from the VS Code Codex panel sometimes hangs forever on a blank/unhydrated conversation view. New sessions may still work, but resuming a previous session in the panel does not load the existing conversation content.

The local Codex session data still appears to exist under ~/.codex, so this does not look like missing session files. It looks more like the VS Code Remote-SSH extension/app-server resume or UI hydration path stops receiving the expected response.

This still reproduces after switching from stable 26.422.30944 to pre-release 26.5422.30944.

Relevant log signatures

The Remote-SSH extension log contains repeated app-server transport warnings like:

codex_app_server::transport: dropping overload response for connection ConnectionId(0): outbound queue is full

Before switching to pre-release, the remote logs contained counts like:

outbound_queue_full=301
dropping_overload_response=302
thread_resume=251
failed_resume=34
no_rollout_found=48
payload_413=0
thread_stream_no_handler=182082
query_cache_no_handler=288

After switching to pre-release and reconnecting, only one new codex app-server process was active and it was launched from the pre-release extension path:

~/.vscode-server/extensions/openai.chatgpt-26.5422.30944-linux-x64/bin/linux-x86_64/codex app-server --analytics-default-enabled

The same fresh pre-release session still logged:

dropping overload response
outbound queue is full

The latest pre-release log summary included:

outbound queue is full=3
dropping overload response=3
thread/resume=0
Failed to resume=0
no rollout found=0
thread-stream-state-changed=0
query-cache-invalidate=1
httpStatus=403=1
httpStatus=400=1

I also saw these non-fatal-looking request failures, with private repo/account/query details redacted:

httpStatus=400 url=/wham/environments/by-repo/github/<redacted>/<redacted>
httpStatus=403 url=https://chatgpt.com/ces/v1/rgstr?<redacted>

I am not sure whether the 400/403 requests are causal or just noise, but the outbound queue is full warning appears to correlate with the panel failing to hydrate the resumed session.

Steps to reproduce

1. Use VS Code on Windows with a Linux Remote-SSH workspace.
2. Install and sign in to the Codex VS Code extension.
3. Create/use a Codex conversation in the remote workspace.
4. Close/reconnect the Remote-SSH window or restart the VS Code server.
5. Open the previous Codex session from the Codex panel.
6. Observe the panel remains blank/unhydrated instead of loading the previous conversation.

Expected behavior

The VS Code Codex panel should resume and hydrate the existing session, or show a clear recoverable error if the resume request failed.

Remediation already attempted

• Closed and reopened VS Code.
• Used Remote-SSH: Kill VS Code Server on Host... / reconnected.
• Switched from stable 26.422.30944 to pre-release 26.5422.30944.
• Verified the pre-release remote extension and bundled codex-cli 0.125.0-alpha.3 were actually active.
• Verified there was only one fresh codex app-server process after reconnecting.

The issue still reproduced.

Related issues/PRs

This may be related to, but not fully fixed by:

• #18203
• #19246
• #16341
• #14812

I can provide a more complete sanitized log bundle if useful, but I avoided attaching full logs here because they include private workspace/repository names and request metadata.