codex - 💡(How to fix) Fix VS Code Codex extension becomes unresponsive on Windows; logs show app-server backpressure/event storm, Cloudflare plugin 403s, and sync WSL probing

Summary

On Windows, the OpenAI Codex VS Code extension can become almost completely unresponsive while VS Code itself remains usable. In the affected sessions the VS Code renderer reports the local Extension Host as unresponsive/responsive in cycles, and the Codex panel/sidebar becomes degraded or stuck even though the bundled codex app-server process remains alive.

This report is for the local Windows VS Code extension, not Remote-SSH. The symptoms overlap with several existing issues, but this case has additional local evidence: Extension Host CPU profiles, per-pattern log counts, and a small local mitigation experiment against the installed extension bundle that removed the heaviest Codex-specific log/event storm.

Environment

• OS: Windows x64
• Shell: PowerShell
• IDE: VS Code, local window
• Extension: openai.chatgpt / Codex VS Code extension
• Extension version: 26.506.31421
• Extension path shape: %USERPROFILE%\.vscode\extensions\openai.chatgpt-26.506.31421-win32-x64
• Extension entrypoint: out/extension.js
• Bundled app-server command shape: bin\windows-x86_64\codex.exe app-server --analytics-default-enabled
• Codex CLI on PATH: codex-cli 0.130.0
• Auth mode: ChatGPT login/subscription mode. No auth tokens are included in this report.

User-visible behavior

• VS Code remains generally responsive.
• The Codex extension UI becomes very sluggish or nearly unresponsive.
• The Extension Host enters unresponsive/responsive cycles.
• The bundled codex app-server process remains alive during the degraded state.
• Reloading the VS Code window temporarily improves the state, but the instability can return.

Reproduction / collection notes

I do not yet have a minimal deterministic repro. This was observed during normal local VS Code usage with the Codex sidebar open and existing Codex sessions available. The failure appears intermittent, but when it occurs it leaves clear artifacts in the standard VS Code logs.

Useful local log locations on Windows:

%APPDATA%\Code\logs\<session>\window1\renderer.log
%APPDATA%\Code\logs\<session>\window1\exthost\openai.chatgpt\Codex.log
%TEMP%\exthost-*.cpuprofile

The exthost-*.cpuprofile files were generated by VS Code after the renderer logged UNRESPONSIVE extension host: starting to profile NOW. The extension bundle is minified, so function names/line numbers below are the names and locations present in the installed bundle/profile, not source-module names.

Evidence before local mitigation

Older same-day VS Code/Codex logs showed large counts of Codex-specific backpressure and event/noise patterns.

From one affected log session:

outbound queue is full: 946
Server overloaded; retry later: 248
thread-stream-state-changed: 137
Failed to parse MCP message: 40
unsupported feature enablement: 6
httpStatus=403: 13

From another affected log session:

outbound queue is full: 1032
Server overloaded; retry later: 106
thread-stream-state-changed: 1908
mcp_request_timeout: 3
Failed to parse MCP message: 162
unsupported feature enablement: 4
httpStatus=403: 32

The VS Code renderer logs for the affected window recorded Extension Host unresponsive/responsive cycles. One example window had an Extension Host PID that repeatedly moved between is unresponsive and is responsive while VS Code itself was still usable.

CPU profile samples captured by VS Code during affected Extension Host stalls pointed into the Codex extension bundle. The most relevant local findings were:

exthost-4d5a60.cpuprofile:
  top frame: 6739 hits in flushCompleteLines
  url: .../openai.chatgpt-26.506.31421-win32-x64/out/extension.js
  line: 60, column: 9676

exthost-a687db.cpuprofile:
  top samples in minified extension.js functions involved in routing / string-buffer processing
  url: .../openai.chatgpt-26.506.31421-win32-x64/out/extension.js
  line: 413 and surrounding minified frames

Observed Codex log classes included:

• app-server transport/backpressure errors: outbound queue is full
• backend overload errors: Server overloaded; retry later
• repeated thread-stream-state-changed notifications without apparent UI recovery
• unsupported feature enablement:

unsupported feature enablement `workspace_dependencies`: currently supported features are apps, memories, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation
method=experimentalFeature/enablement/set

• remote plugin sync / featured plugin cache failures against chatgpt.com/backend-api/plugins/list and .../plugins/featured, returning 403 Forbidden HTML Cloudflare challenge pages. I am intentionally not pasting the full challenge body, but the body included markers like:

Enable JavaScript and cookies to continue
window._cf_chl_opt
/cdn-cgi/challenge-platform/
cZone: 'chatgpt.com'
cType: 'managed'

• telemetry/CES failures such as https://chatgpt.com/ces/v1/rgstr?... returning httpStatus=403
• MCP resource discovery noise when servers do not implement resources/templates:

Failed to list resources for MCP server '<server>': Mcp error: -32601: Method not found
Failed to list resource templates for MCP server '<server>': Mcp error: -32601: Method not found

• localized Windows process output being fed into the MCP JSON parser, causing parse failures. Examples of the localized taskkill output shape:

ÊXITO: o processo com PID <pid> foi finalizado.
ERRO: o processo com PID <pid> ...

I am sanitizing exact local usernames, workspace names, token-bearing URLs, and unrelated private paths.

Local mitigation experiment

This was a local experiment on the installed, minified extension bundle only. It is not a proper upstream fix, but it helped identify likely failure surfaces.

I patched the installed out/extension.js locally to:

1. Chunk the stdout line-framing path that previously spent heavy CPU in flushCompleteLines, yielding with setImmediate after either 200 complete lines or about 8 ms of work.
2. Ignore known localized Windows taskkill success/error lines before attempting JSON.parse on app-server stdout lines.

After reloading VS Code, a clean observation window showed the heaviest Codex-specific storm was gone:

outbound queue is full: 0
Server overloaded; retry later: 0
thread-stream-state-changed: 0
mcp_request_timeout: 0
Failed to parse MCP message: 0

Residual startup issues still appeared:

Extension host (LocalProcess pid: <pid>) is unresponsive: 2
Extension host (LocalProcess pid: <pid>) is responsive: 2
UNRESPONSIVE extension host: 1
unsupported feature enablement: 4
startup remote plugin sync failed: 1
failed to warm featured plugin ids cache: 1
httpStatus=403: 1
slow SQL statement: 2
wsl.exe --status: 2
callClient: client not ready: 13

A subsequent two-minute observation after the initial startup period did not produce additional Extension Host unresponsive events and did not reintroduce outbound queue is full, Server overloaded, thread-stream-state-changed, MCP timeouts, or JSON parse failures.

This mitigation result suggests, but does not prove, that a line/event burst or app-server stdout parsing path can monopolize the Extension Host event loop under some error conditions. The remaining startup unresponsive events may involve other initialization paths too.

Additional residual Windows-specific issue: WSL probe

Even when running the local Windows extension, and without WSL installed/enabled for Codex, the extension invoked a synchronous WSL probe during startup:

command=wsl.exe args=--status
Error: Command failed: wsl.exe --status
O Subsistema do Windows para Linux não está instalado...

The stack in the Codex log pointed into the extension bundle:

execFileSync
k7 (.../openai.chatgpt-26.506.31421-win32-x64/out/extension.js:429:314)
rLe (.../out/extension.js:428:30899)
Gi (.../out/extension.js:428:30840)
os-info (.../out/extension.js:483:19100)
v_.fetch (.../out/extension.js:442:1944)
t.handleMessage (.../out/extension.js:458:71772)

I locally mitigated this by changing the installed bundle so automatic Gi() WSL detection returns null unless chatgpt.runCodexInWindowsSubsystemForLinux is enabled, while preserving forced detection paths used by the WSL installation flow. This second local mitigation still requires a VS Code reload to validate fully.

Why this looks upstream rather than local configuration only

• The same broad symptoms are reported in multiple open issues involving the VS Code extension/app-server boundary, feature mismatch, Cloudflare 403s, and backpressure.
• The VS Code process itself remained usable; the problem localized to Extension Host / Codex UI behavior.
• CPU profiles during stalls pointed into the Codex extension bundle's line/event processing, not only into external MCP servers.
• The local chunking/parse-guard mitigation eliminated the largest Codex-specific storm counters in the next clean session.
• The Cloudflare/plugin discovery failures return HTML challenge pages to non-browser extension/app-server paths; these should degrade gracefully rather than contribute to UI stalls or log floods.

Expected behavior

• The VS Code extension should remain responsive even when the app-server emits a large stdout/log/event burst.
• Extension/app-server feature negotiation should agree on workspace_dependencies, or unsupported features should fail once quietly and be disabled for the session.
• Cloudflare challenge / plugin sync / telemetry 403 responses should be detected, deduplicated, and backed off, not allowed to flood logs or destabilize the UI.
• Localized Windows process output should never be parsed as MCP JSON.
• WSL detection should not synchronously run wsl.exe --status on startup when Codex is not configured to run in WSL, or it should be async/cached/non-blocking.
• MCP resources/list and resources/templates/list -32601 Method not found responses should not be surfaced as repeated extension errors for servers that simply do not implement those optional capabilities.

Possible investigation targets

1. Add backpressure/yielding around the extension stdout line framer and notification router.
2. Ensure stdout parsing only attempts JSON on protocol-shaped lines; ignore or quarantine known child-process status lines.
3. Deduplicate or downgrade repeated thread-stream-state-changed broadcasts if no handler is registered.
4. Align extension feature flags with bundled app-server supported features for workspace_dependencies.
5. Treat Cloudflare HTML challenge responses from plugin/app discovery as a known degraded mode with backoff and a clear diagnostic.
6. Make WSL probing conditional, async, cached, or tied strictly to runCodexInWindowsSubsystemForLinux.
7. Downgrade optional MCP resources/templates discovery -32601 responses to debug-level noise.

Related issues

These issues appear related but do not fully cover this local Windows evidence set:

• #21806: VS Code Remote-SSH stalls with unsupported workspace_dependencies, thread-stream-state-changed, and outbound queue full
• #21735: Windows task reliability with connector/logo overload, plugin manifest warnings, and Cloudflare/telemetry 403
• #20673: plugin/connectors requests return Cloudflare 403 challenge HTML
• #19437: workspace_dependencies feature mismatch loop
• #19366: repeated connector logo fetch / Server overloaded; retry later
• #20599: WSL app-server high CPU with outbound queue full
• #16341: Cloudflare challenge HTML/403 instability

Notes

I have local logs and CPU profiles available and can provide additional redacted snippets if useful. I intentionally did not paste auth tokens, full Cloudflare challenge bodies, or private workspace paths.