›_ Codex Issues
Codex Issues / #15397

VS Code extension spams unsupported requests / thread-stream-state-changed broadcasts, causing high CPU/GPU usage on macOS

Open 💬 6 comments Opened Mar 21, 2026 by Avi7ii
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the VS Code extension are you using?

openai.chatgpt 26.318.11754 on VS Code 1.111.0 (ce099c1ed25d9eb3076c11e4a280f3eb52b4fbeb, arm64)

What subscription do you have?

GPT Plus

Which IDE are you using?

VS Code

What platform is your computer?

macOS 26.3.1 (25D771280a), Darwin 25.3.0 arm64, Apple M4 MacBook Air (16 GB)

What issue are you seeing?

The Codex VS Code extension sometimes enters an event/error storm in the sidebar. Once it happens, the extension host and VS Code renderers spike, GPU/WindowServer usage rises, the Mac gets hot, and battery drain becomes abnormally fast.

The repeating patterns I captured were:

  • open-in-target not supported in extension
  • [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
  • local-environments is not supported in the extension

At the same time, code --status / process snapshots showed:

  • extension-host [1] around 44% CPU
  • VS Code renderer windows around 14% and 25% CPU
  • gpu-process around 15% CPU
  • macOS WindowServer around 37% to 43% CPU

This happened in a tiny workspace (6 files total), so it does not look like indexing or large-project scanning load.

What steps can reproduce the bug?

  1. Open the Codex sidebar in VS Code on macOS.
  2. Use the extension normally for a while / leave the sidebar open across wake-resume and regular interactions.
  3. In my case the issue surfaced while the Codex sidebar was open in the secondary sidebar. A Markdown preview tab was also open. I also had the subframe7536.custom-ui-style extension enabled with sidebar vibrancy/transparency, which seems to amplify the GPU/WindowServer cost once the bug starts.
  4. When the bad state is reached, the extension starts spamming logs and VS Code becomes hot/high-power-draw.

I could not isolate a single deterministic click sequence yet, but I captured one concrete occurrence on 2026-03-22 around 00:49 to 00:54 local time.

What is the expected behavior?

The extension should not emit unsupported-request errors or unhandled broadcast warnings in a tight loop. Even if a feature is unavailable, the extension should fail once, stop retrying, and not drive sustained renderer/GPU/WindowServer load.

Additional information

Relevant log excerpts from window1/exthost/openai.chatgpt/Codex.log:

2026-03-22 00:53:10.338 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-03-22 00:54:04.001 [error] Error fetching errorMessage="local-environments is not supported in the extension" ... url=vscode://codex/local-environments

And earlier:

Error fetching errorMessage="open-in-target not supported in extension" ... url=vscode://codex/open-in-targets

Counts from the captured logs:

  • about 9,700 open-in-target not supported in extension errors between 00:49:48 and 00:49:58
  • thread-stream-state-changed warnings per minute:
  • 00:50: 76
  • 00:51: 95
  • 00:52: 118
  • 00:53: 117

Context that may matter:

  • Workspace was very small: 3 PDF + 2 Markdown + 1 DOCX files
  • subframe7536.custom-ui-style was enabled with vibrancy: "sidebar" and a transparent workbench background; I think that amplifies the thermal impact, but the extension-side event storm appears to be the trigger
  • Clash and AirSend were not the active hot processes during the capture

I can provide sampled process output and fuller logs if needed.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #15393
  • #14657
  • #13717
  • #14917

Powered by Codex Action

duncanmcl · 3 months ago

I had the same problem.

In my case, it went beyond high CPU/log spam and actually crashed VS Code’s extension host. The crash artifacts show a Node/V8 heap OOM (JavaScript heap out of memory / Ineffective mark-compacts near heap limit).

What I found locally:

  • extension host RSS was about 4.5 GB before crash
  • the OpenAI/Codex extension was repeatedly handling requests for vscode://codex/open-in-targets
  • the handler was throwing open-in-target not supported in extension
  • that error was being logged over and over with stack traces

So this looks related to #15393 as well. Same failure family, but in my case it escalated into an extension-host crash.

Avi7ii · 3 months ago

Thanks, this matches what we saw on our side.

Our local mitigation was to hotfix the extension host so the unsupported open-in-targets / local-environment(s) requests return empty benign results instead of throwing. We kept the original bundle intact, loaded a patched local copy, and after that the open-in-target not supported in extension spam dropped to zero in our latest run, along with the repeated websocket reconnect noise.

That said, this only looks like a workaround, not the real fix. We still see some thread-stream-state-changed warnings afterwards, so there may be a second issue on the webview/renderer side. But returning benign values instead of throwing was enough to stop the worst CPU/GPU storm on our machine.

teron131 · 3 months ago

Exactly the same issue. MacBook Activity Monitor shows one or two Code Helper Renderer spiking 80-200% CPU usage whenever the chat moves and renders. It gets several of this per sec in the logs: [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed.

Not sure if it is a workaround. It seems to be a VS Code extension main problem. Using the Codex app with popup as side panel works effectively the same while the Codex Renderer seems to be quite normal sub 40% CPU usage.

vladerlord · 3 months ago

Same here. After a few prompts, the Code Helper (renderer process) starts consuming ~50% CPU and keeps doing so until VS Code is fully restarted.

VS Code: 1.114.0
Codex extension: 26.5325.31654, 26.5401.11717

The logs are continuously spammed with an error (see stack trace below):

2026-04-04 16:07:13.366 [error] Error fetching errorMessage="open-in-target not supported in extension" errorName=Error errorStack="Error: open-in-target not supported in extension
    at open-in-targets (/Users/user/.vscode/extensions/openai.chatgpt-26.325.31654-darwin-arm64/out/extension.js:255:22561)
    at W_.handleVSCodeRequest (/Users/user/.vscode/extensions/openai.chatgpt-26.325.31654-darwin-arm64/out/extension.js:255:27618)
    at Qw.fetch (/Users/user/.vscode/extensions/openai.chatgpt-26.325.31654-darwin-arm64/out/extension.js:214:1973)
    at t.handleMessage (/Users/user/.vscode/extensions/openai.chatgpt-26.325.31654-darwin-arm64/out/extension.js:230:65930)
    at op.value (/Users/user/.vscode/extensions/openai.chatgpt-26.325.31654-darwin-arm64/out/extension.js:230:56238)
    at E._deliver (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:403:3043)
    at E.fire (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:403:3361)
    at XE.$onMessage (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:528:115424)
    at r._doInvokeHandler (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:407:154500)
    at r._invokeHandler (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:407:154248)
    at r._receiveRequest (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:407:153030)
    at r._receiveOneMessage (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:407:152043)
    at op.value (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:407:149943)
    at E._deliver (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:403:3043)
    at E.fire (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:403:3361)
    at as.fire (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:405:8437)
    at op.value (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:821:9911)
    at E._deliver (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:403:3043)
    at E.fire (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:403:3361)
    at as.fire (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:405:8437)
    at MessagePortMain.<anonymous> (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:821:8082)
    at MessagePortMain.emit (node:events:519:28)\n\tat MessagePortMain._internalPort.emit (node:electron/js2c/utility_init:2:2959)
    at Object.callbackTrampoline (node:internal/async_hooks:130:17)"
url=vscode://codex/open-in-targets
huygiatrng · 3 months ago

Another Windows/Cursor data point: I saw the same pattern where short threads opened, but one longer local thread stayed stuck on Loading with a blank panel. The same thread opened fine in the Codex desktop app, so the session itself did not seem broken.

What helped locally was making stable-metadata fail soft and stopping eager connector logo fetches during mount. Before that, logs were full of git/worker RPC errors and then app-server overloads. After those two changes, the long thread became usable again without touching .codex/sessions.

I also saw UNKNOWN service agentSessions in a VS Code fork, but that looks like a separate host-specific issue.