Codex IDE extension causes 100% Code Helper (Renderer) CPU in non-git folders due to git stable-metadata retry loop

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

What version of the IDE extension are you using?

openai.chatgpt@26.422.30944

What subscription do you have?

yes

Which IDE are you using?

VS Code

What platform is your computer?

macos

What issue are you seeing?

When opening the Codex IDE extension in a folder that is not a Git repository, the VS Code process Code Helper (Renderer) immediately jumps to around 100% CPU and stays there.

This happens even when I do not run any prompt or perform any action inside Codex. Simply opening the Codex IDE/webview is enough to trigger it.

The issue appears to be caused by the Codex git worker repeatedly failing the stable-metadata RPC call in a tight loop.

Codex logs repeatedly show:

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

Example from the log:

2026-04-26 14:49:13.530 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-26 14:49:13.540 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-26 14:49:13.550 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git

In my case, the log repeated this hundreds of times within a few seconds.

VS Code DevTools Performance also showed repeated renderer/webview message activity around:

webviewElement.ts
overlayWebview.ts
mainThreadWebviews.ts
rpcProtocol.ts
postMessage / setTimeout

Closing the Codex webview immediately stops the CPU usage.

A workaround is to run git init in the opened folder. As soon as .git is created, CPU usage returns to normal. Interestingly, after Codex stabilizes, removing .git with rm -rf .git does not immediately make the CPU spike return.

This suggests Codex enters a bad initialization/retry loop when started in a non-git folder. Creating .git once breaks the loop.

What steps can reproduce the bug?

  1. Create or open any folder that is not a Git repository:

``bash
mkdir /tmp/codex-nongit-repro
cd /tmp/codex-nongit-repro
code .
``

  1. Open the Codex IDE extension / ChatGPT Codex panel in VS Code.
  1. Observe macOS Activity Monitor.
  1. Code Helper (Renderer) jumps to around 100% CPU and stays there.
  1. Check the Codex extension logs:

``bash
grep -RniE "worker_rpc_response_error|stable-metadata|workerId=git" \
~/Library/Application\ Support/Code/logs/*/window*/exthost/openai.chatgpt/Codex*.log | tail -200
``

  1. The logs repeatedly show:

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

  1. Run this in the same folder:

``bash
git init
``

  1. CPU usage immediately returns to normal.
  1. Optionally remove .git:

``bash
rm -rf .git
``

  1. CPU does not immediately spike again after the loop has been broken.

What is the expected behavior?

Codex should handle non-git folders without entering a high-CPU retry loop.

If the opened workspace is not a Git repository, Codex should either:

- skip git metadata collection,
- return a stable "not a git repository" state,
- or retry with throttling/backoff.

Opening Codex in a non-git folder should not cause `Code Helper (Renderer)` to stay at 100% CPU.

### Additional information

This appears to be specifically related to non-git workspaces.

Observed behavior:

```text
non-git folder
→ open Codex IDE webview
→ repeated worker_rpc_response_error method=stable-metadata workerId=git
→ Code Helper (Renderer) 100% CPU
→ run git init
→ CPU immediately normalizes
→ remove .git
→ CPU does not immediately spike again

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19642
  • #19327
  • #18775
  • #18331
  • #19568

Powered by Codex Action

blueGLS · 4 months ago

I can reproduce a closely related case on Windows.

Working version:
26.325.31654

First bad tested version:
26.406.31014

Environment:

  • Windows 11
  • VS Code clean profile: code --profile CodexTest
  • Only Codex installed
  • No folder opened, only Untitled-1
  • Google Drive and Syncthing closed

Behavior:

  • Opening the Codex panel causes one logical CPU to stay near 100%.
  • Closing the Codex panel immediately drops CPU usage.
  • Rollback to 26.325.31654 fixes the issue.

This may be the same stable-metadata / non-git workspace loop,
but in my case it also happens with no folder opened at all.

igorkuznecov · 4 months ago

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.