Codex VS Code extension on code-server: precise version boundary + root cause analysis
Codex VS Code extension on code-server: precise version boundary + root cause analysis
TL;DR
If you run Codex (openai.chatgpt) extension inside code-server (browser VS Code), Send may freeze the entire input box. Root cause is a VS Code proposed-API mismatch. Downgrade to0.5.22 (Oct 2025) to fix.
Context
We deploy browser-based coding sandboxes for end-users using code-server 4.100 + Codex extension. Many users hit “Send doesn’t work, refresh sometimes fixes it” — same pattern as in openai/codex#26951, #10421, #10515, and others.
After ~2 days of log archaeology, we located the precise root cause and version cutoff.
What’s actually happening
The Codex extension version 0.5.23 (Oct 2025) onward declares enabledApiProposals: ['chatSessionsProvider', 'languageModelProxy'] and calls vscode.chat.registerChatSessionItemProvider.
That API was introduced in VS Code 1.103 (July 2025) and is still marked proposed — see Microsoft’s Using Proposed API guide: “subject to change, only available in Insiders distribution, should not be used in published extensions.”
code-server releases lag upstream VS Code. If your code-server is based on VS Code < 1.103, the API doesn’t exist. The Codex extension catches the TypeError (good), logs it as info (less good), but the downstream broadcast handlers never get registered (bad).
User-visible result: hundreds of [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed warnings, eventually the webview JS main thread saturates, composer freezes.
Empirical version boundary (the new data)
Downloaded VSIXs and inspected package.json:
| Version | chatSessionsProvider |
Safe on code-server 1.100? |
|---|---|---|
| 0.3.3 ~ 0.5.22 | NO | YES |
| 0.5.23 (2025-10-23) | YES | NO |
| All later (including 26.5xxx, 26.6xx) | YES | NO |
0.5.22 is the last working version.
Why upgrading code-server doesn’t help
We tested code-server 4.118 (VS Code 1.118.0). The chatSessionsProvider TypeError goes away, BUT:
- New error:
PendingMigrationError: navigator is now a global in nodejs(Node 22 issue, #10515). Still unmigrated in latest stable 26.5623.42026. - The broadcast handlers still don’t fully wire up (API shape evolved between 1.103 and 1.118).
- End-user experience actually got worse than 4.100 + 0.5.22.
So upgrading code-server isn’t a real fix.
Workaround (verified working)
# 1. Uninstall whatever's there
code-server --uninstall-extension openai.chatgpt
# 2. Download 0.5.22 linux-x64
curl -L -o /tmp/codex.vsix \
'https://openai.gallery.vsassets.io/_apis/public/gallery/publisher/openai/extension/chatgpt/0.5.22/assetbyname/Microsoft.VisualStudio.Services.VSIXPackage'
# 3. Install
code-server --install-extension /tmp/codex.vsix
# 4. Disable auto-update so it doesn't get bumped back
cat >> ~/.local/share/code-server/User/settings.json <<'EOF'
"extensions.autoUpdate": false,
"extensions.autoCheckUpdates": false,
EOF
What you lose
0.5.22 is from Oct 2025, so you miss ~8 months of features:
- Native VS Code chat-panel integration (the
chatSessionsProvideritself) - Apps SDK / MCP apps marketplace
- New plan-summary / progress view
For our end-users these are mostly invisible. Core chat / multi-thread / streaming / tool use / context all work.
Future-proofing thought
chatSessionsProvider is still proposed and Microsoft has already marked registerChatSessionItemProvider as @deprecated in favor of ChatSessionItemController (see vscode source). So when the next Codex extension migrates to the new controller API, even latest VS Code Insiders users may break.
If you’re shipping anything production-critical that depends on the Codex extension, consider moving to codex exec (non-interactive) or the Codex SDK with your own thin UI. That’s the only path that doesn’t depend on the proposed-API churn.
Filed an issue too
Posted full report at Issues · openai/codex · GitHub [fill in once filed] with reproducer.
Hope this saves someone the 2 days I spent.
Discussion in the ATmosphere