stable-metadata error loop in non-git folders causes high CPU in the VS Code extension

What version of the IDE extension are you using?

openai.chatgpt-26.417.40842-win32-x64

What subscription do you have?

ChatGPT Business

Which IDE are you using?

Visual Studio Code

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

When I open Visual Studio Code with the Codex extension in a folder that is not a Git repository, CPU usage spikes heavily. The extension repeatedly requests git stable-metadata, treats the “Not a git repository” case as an error instead of an empty state, and starts spamming worker_rpc_response_error for method=stable-metadata workerId=git. This creates a tight error loop, high CPU usage, and continuous log spam until the window is closed or the extension is patched.

What steps can reproduce the bug?

Open Visual Studio Code.
Install and enable the Codex extension.
Open a local folder that is not a Git repository.
Open the Codex panel or start using the extension in that folder.
Wait a short time.
Observe high CPU usage and repeated worker_rpc_response_error log entries for method=stable-metadata workerId=git.

What is the expected behavior?

When Codex is opened in a folder that is not a Git repository, the extension should treat missing git stable-metadata as a normal empty state, not as an error. It should return null / no metadata, avoid repeated retries or log spam, and keep CPU usage normal. This non-git case should be handled gracefully in future releases. Details and a local repro are included below.

The likely problematic code paths are the stable-metadata handler in out/extension.js and the git metadata query in webview/assets/globe-*.js. The non-git case should return null instead of an error, and the webview side should treat failed stable-metadata requests as optional / empty-state results rather than propagating them as repeated errors.

Additional information

I investigated this locally because the CPU spike remained reproducible after reinstalling the extension.

At first I suspected the earlier open-in-targets issue, but after testing a clean reinstall and checking the current logs, that was not the real cause for this repro. In my case, the dominant repeating log line was:

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

The workspace I was testing in was not a Git repository. Running git rev-parse --show-toplevel in that folder returned the normal “not a git repository” result.

After inspecting the installed extension bundle, the problem looked like this:

• the extension/webview keeps requesting git stable-metadata
• in a non-git folder, the extension treats that as an error path instead of an empty state
• the webview keeps surfacing that failure
• this creates a tight log/error loop and drives CPU usage high

The important part is that this was reproducible even without any real Git data, simply by opening Codex in a non-git folder.

I tested a narrow local patch in two places:

1. In out/extension.js, for the stable-metadata path, I changed the non-git result from an error to null.
2. In the webview git metadata hook (webview/assets/globe-*.js), I added a safe catch so failed stable-metadata requests also resolve to null instead of propagating as repeated errors.

After applying only this narrow patch to a freshly reinstalled extension and reloading the VS Code window, the CPU spike disappeared completely.

So the root issue seems to be: in non-git folders, missing git metadata is being treated as an error condition instead of a normal empty state. Returning null for that case was sufficient to stop the loop in my repro.