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.chatgpt26.422.30944stableopenai.chatgpt26.5422.30944pre-release
The pre-release Remote-SSH extension bundle reports:
codex-cli 0.125.0-alpha.3What 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 fullBefore 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=288After 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-enabledThe same fresh pre-release session still logged:
dropping overload response
outbound queue is fullThe 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=1I 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.30944to pre-release26.5422.30944. - Verified the pre-release remote extension and bundled
codex-cli 0.125.0-alpha.3were actually active. - Verified there was only one fresh
codex app-serverprocess 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.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional diagnostic update after comparing the stuck thread with another thread that opens successfully in the VS Code extension:
codex resume --all.647 KB261JSONL linescompactedrecordsreplacement_historytask_complete10 MB4829JSONL lines4compactedrecordsSo this particular failure does not look like a generic "thread too large" or "compacted replacement_history is too large" issue.
One notable log difference:
logs_2.sqliteshowsthread/resumewith:codex resume --all:But I do not see the corresponding
CodexWebviewProvider.webview:<uuid>thread/resumeentry for that stuck thread when trying to open it in the VS Code panel.That suggests the data and rollout replay path are probably intact, while the VS Code webview/navigation/session-resolution path may fail before issuing or completing the normal webview
thread/resumerequest for this specific history item.I also confirmed the stuck thread is present in
state_5.sqlitewith a validrollout_path, and the rollout file exists at that path. I am intentionally not attaching full logs or transcripts because they contain private workspace/repository details.Workaround update: I was able to recover the stuck VS Code panel session by clearing the local VS Code workspace session model cache.
Important detail: this cache was on the local Windows VS Code client, not on the remote Linux host.
The affected key was in the local VS Code user-data workspace DB:
The key was:
That cache value contained the stuck thread id and
openai-codex://route/local/<thread-id>entries. The remote Codex state itself was still valid:codex resume --allcould open the same session.~/.codex/state_5.sqlitehad the thread with a validrollout_path.Recovery steps I used:
state.vscdb.agentSessions.model.cacherow fromItemTable.Right after reload, the Codex panel temporarily showed:
After waiting a bit, the previously stuck session hydrated and opened successfully in the VS Code extension.
This suggests at least one failure mode is a stale/corrupt local VS Code
agentSessions.model.cacheentry for the remote workspace. Clearing that single cache key can recover the panel without deleting remote~/.codexdata or session JSONL files.Having massive issues with this the past two days. What's going on over there? I got all of these errors and had to blow up cache files, .codex in my linux root, and relogin via vscode. This seeems to have fixed it.. for now.