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 stableopenai.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
- Use VS Code on Windows with a Linux Remote-SSH workspace.
- Install and sign in to the Codex VS Code extension.
- Create/use a Codex conversation in the remote workspace.
- Close/reconnect the Remote-SSH window or restart the VS Code server.
- Open the previous Codex session from the Codex panel.
- 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:
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.
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.chatgpt26.422.30944stableopenai.chatgpt26.5422.30944pre-releaseThe pre-release Remote-SSH extension bundle reports:
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?
~/.vscode-server~/.vscode-server/extensions/openai.chatgpt-*-linux-x64What 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.30944to pre-release26.5422.30944.Relevant log signatures
The Remote-SSH extension log contains repeated app-server transport warnings like:
Before switching to pre-release, the remote logs contained counts like:
After switching to pre-release and reconnecting, only one new
codex app-serverprocess was active and it was launched from the pre-release extension path:The same fresh pre-release session still logged:
The latest pre-release log summary included:
I also saw these non-fatal-looking request failures, with private repo/account/query details redacted:
I am not sure whether the 400/403 requests are causal or just noise, but the
outbound queue is fullwarning appears to correlate with the panel failing to hydrate the resumed session.Steps to reproduce
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
Remote-SSH: Kill VS Code Server on Host.../ reconnected.26.422.30944to pre-release26.5422.30944.codex-cli 0.125.0-alpha.3were actually active.codex app-serverprocess after reconnecting.The issue still reproduced.
Related issues/PRs
This may be related to, but not fully fixed by:
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.