VS Code extension: high renderer CPU in non-git workspace caused by repeated git stable-metadata worker loop

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

• #16849
• #16850
• #16320
• #17357

Powered by Codex Action

I'm experiencing this too, on linux (opened a duplicate https://github.com/openai/codex/issues/17730).

After running git init . the load immediately drops, no reload or restart required.

Load is normal in other existing git dirs.

Had this issue on windows, clicked initialize repo and the load immediately dropped. Thanks!

Adding a Windows-specific variant that may help narrow this down.

For me this was version-sensitive:

• last known good: 26.409.20454
• reproduces: 26.422.30944
• also reproduces: 26.5422.30944

Environment:

• Windows 10
• VS Code

The repeating log line was the same one discussed here:

worker_rpc_response_error error={} method=stable-metadata workerId=git

What seems worth adding is that I could reproduce closely related failure states beyond just a plain non-git folder:

1. non-git workspace root
2. git repo in unborn state (initialized, but no first commit / no valid HEAD)
3. git repo rejected by Git because of safe.directory / dubious ownership on Windows

In my testing, git init alone was not always sufficient.
The loop only stopped reliably after the workspace had both:

• a Git-safe ownership state (safe.directory)
• a valid first commit so HEAD exists

That suggests the eventual fix should probably treat all of these as stable non-fatal metadata states, not just:

• not a git repository
• repo exists but HEAD is unborn/missing
• repo exists but Git rejects access via safe.directory / ownership checks

This feels closely related to #19326, but with the additional Windows safe.directory angle.

I’m seeing what looks like a related issue on macOS with the latest VS Code extension.

Environment

• Codex / ChatGPT VS Code extension: openai.chatgpt@26.422.30944
• VS Code: 1.117.0
• VS Code arch: arm64
• OS: macOS 26.4.1 build 25E253
• Kernel: Darwin 25.4.0 arm64
• Workspace: Git repo opens correctly; git status works.

What I see

When I open Codex / ChatGPT in VS Code, the Codex Output panel starts logging repeated Git worker warnings (and the CPU usage reaches 130% in the Code Helper (plugin) process):

[warning] worker_rpc_response_error error={} method=stable-metadata workerId=git

Then I also see repeated 403 Forbidden fetch errors to this endpoint:

[error] Error fetching httpStatus=403 statusText=Forbidden url=https://chatgpt.com/ces/v1/rgstr?...&st=javascript-client-react&sv=3.32.2...

When I open or use a chat, the Output panel is also flooded with IPC warnings like:

[warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
[warning] [IpcClient] Received broadcast but no handler is configured method=thread-read-state-changed

These warnings appear repeatedly while the conversation is active / streaming.

Example logs

On opening a chat:

2026-04-25 14:51:41.064 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-25 14:51:41.075 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-25 14:51:41.213 [info] [git-repo-watcher] Starting git repo watcher
2026-04-25 14:51:47.803 [error] Error fetching httpStatus=403 requestId=REDACTED statusText=Forbidden url=https://chatgpt.com/ces/v1/rgstr?k=REDACTED&st=javascript-client-react&sv=3.32.2&sid=REDACTED&ec=3&gz=1

While chatting / streaming:

2026-04-25 14:52:50.205 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-04-25 14:52:50.232 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
2026-04-25 14:52:50.648 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-read-state-changed
2026-04-25 14:52:56.973 [error] Error fetching httpStatus=403 requestId=REDACTED statusText=Forbidden url=https://chatgpt.com/ces/v1/rgstr?k=REDACTED&st=javascript-client-react&sv=3.32.2&sid=REDACTED&ec=4&gz=1

Notes

The chat itself still appears to work, but the Output panel gets noisy with repeated warnings/errors. This seems related to this issue because of the repeated stable-metadata Git worker warnings, but in my case I also consistently see the ces/v1/rgstr 403 Forbidden errors and the repeated IPC thread-stream-state-changed / thread-read-state-changed warnings.

----

The chat itself still appears to work in some cases, but the Output panel gets noisy with repeated warnings/errors. This seems related to this issue because of the repeated stable-metadata Git worker warnings, but in my case I also consistently see the ces/v1/rgstr 403 Forbidden errors and the repeated IPC thread-stream-state-changed / thread-read-state-changed warnings.

Also, some older chats no longer open correctly. When I try to open them, the chat appears to stay stuck in a loading/thinking state, while the Output panel keeps logging this warning indefinitely:

[warning] worker_rpc_response_error error={} method=stable-metadata workerId=git

I put together a small public workaround repo for this stable-metadata non-git loop:

https://github.com/igorkuznecov/patch-codex-extension

What it does:

• patches the extension host bundle so the non-git stable-metadata path returns null instead of a hard error
• patches the webview asset so failed stable-metadata requests resolve to null instead of feeding the loop
• creates .stable-metadata.bak backups
• includes a restore script
• uses MIT license

Current version of the script patches all installed openai.chatgpt-* versions it finds under ~/.cursor/extensions or ~/.vscode/extensions, which turned out to matter when multiple extension versions are present.

Tested locally on Cursor extension builds:

• openai.chatgpt-26.422.62136-darwin-arm64
• openai.chatgpt-26.422.71525-darwin-arm64

The patch script is here:

• patch-codex-stable-metadata.sh

Usage:

bash patch-codex-stable-metadata.sh ~/.cursor/extensions
# or
bash patch-codex-stable-metadata.sh ~/.vscode/extensions

Then reload the editor window.

This is only a local workaround, not an upstream fix, but it stopped the renderer/log loop in my repro.

Solved for Me

Problem gone for me after 05/02/26 9:01 AM, last Git warning logged and CPU load normal.
Didn't update Codex extension or VS Code, so fix may have been somewhere else. I see some other warnings which could be coming from some quick fix, but anyway, CPU is normal. There was a Codex Extension 26.429.30905 update waiting, but problem was gone before installing it.

I did install Codex App yesterday for testing, and it didn't have the excessive CPU load. I switched to VS Code Codex and problem persisted, so I think it's not that App installation fixed anything.

@etraut-openai, wouldn't say this is performance.
This is a bug. not some slow code.

It looks like the issue has indeed been resolved. I’ve been monitoring this for about a week, and during that time I haven’t seen any more freezes or excessive CPU usage in VS Code. Previously, the issue would occur almost immediately, but now everything is working normally, even with the Codex panel open in a non-Git workspace.

Thanks—it looks like the fix worked.

I can confirm this issue still exists on my side.

I just hit the same problem: there was a storm of workerId=git messages, and after running git init in that folder the problem disappeared.

System:

• Linux Mint 22.3
• Linux kernel 6.17.0-29-generic
• x86_64

Codex version:

• 26.422.71525

VSCodium version:

• 1.116.02821

I can confirm that this still exists for me.

Codex version: 26.602.40724

VS Code About page:
Version: 1.123.0
Commit: 6a44c352bd24569c417e530095901b649960f9f8
Date: 2026-06-03T11:29:03+02:00
Electron: 42.2.0
ElectronBuildId: 14159160
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Linux x64 6.17.0-119029-tuxedo