What version of the IDE extension are you using?
ChatGPT extension: openai.chatgpt v26.415.20818
What subscription do you have?
ChatGPT Plus
Which IDE are you using?
VS Code: 1.116.0
What platform is your computer?
25.3.0 arm64 arm
What issue are you seeing?
When I open the Codex panel in VS Code inside a non-git folder on macOS, CPU usage becomes abnormally high almost immediately.
The main symptom is that VS Code renderer processes (Code Helper (Renderer)) jump to roughly 200%–300%+ CPU, and the machine becomes noticeably hot. In some runs, the plugin process also becomes elevated.
I narrowed this down with multiple A/B tests:
- In a clean VS Code environment with no extra extensions, opening a normal folder is fine.
- After installing only
openai.chatgpt, opening Codex in a non-git folder reproduces the high CPU issue.
- If I open the same environment in a git repository, Codex behaves normally.
- Even adding only an empty
.git shell via git init is enough to make the problem disappear.
The most relevant log pattern I found is repeated warnings like:
worker_rpc_response_error error={} method=stable-metadata workerId=git
I also saw VS Code git logs repeatedly reporting:
fatal: not a git repository (or any of the parent directories): .git
This makes it look like Codex may be repeatedly requesting git-related stable metadata in a non-git workspace and entering a retry/error loop that drives renderer/plugin CPU very high.
What steps can reproduce the bug?
- On macOS, create a fresh folder that is not a git repository.
Example:
mkdir -p ~/Desktop/codex-nongit-repro
- Start VS Code with a clean user data dir and a clean extensions dir.
rm -rf ~/Desktop/vscode-repro-user ~/Desktop/vscode-repro-exts
mkdir -p ~/Desktop/vscode-repro-user ~/Desktop/vscode-repro-exts
code \
--user-data-dir ~/Desktop/vscode-repro-user \
--extensions-dir ~/Desktop/vscode-repro-exts \
--install-extension openai.chatgpt
- Open that non-git folder in the same clean environment.
code \
--user-data-dir ~/Desktop/vscode-repro-user \
--extensions-dir ~/Desktop/vscode-repro-exts \
~/Desktop/codex-nongit-repro
-
Open the Codex panel and interact with it briefly.
-
Observe process usage.
ps -Ao pid,ppid,%cpu,%mem,command | \
grep -E 'Code Helper \(Renderer\)|Code Helper \(Plugin\)|Visual Studio Code' | \
grep -v grep | sort -k3 -nr | head -20
-
In my case, one or more Code Helper (Renderer) processes quickly rise to about 200%–300%+ CPU.
-
For A/B comparison, in the same folder, run:
-
Then reopen the same folder and open Codex again.
-
After git init, CPU usage returns to normal or near-normal, and the issue is no longer reproducible in the same way.
-
I also reproduced the same pattern in my normal VS Code environment:
- non-git folder -> high CPU
- same folder after
git init or in a real git repository -> normal behavior
What is the expected behavior?
Codex should behave normally in both git and non-git folders.
If git metadata is unavailable, I would expect Codex to gracefully detect that situation, skip git-specific metadata work, or fall back without entering a high-frequency retry/error loop.
Opening the Codex panel in a normal non-git project folder should not cause renderer/plugin CPU usage to spike to several hundred percent.
Additional information
Important observations:
This is reproducible in a completely clean VS Code environment with only openai.chatgpt installed.
This does not appear to require any other third-party extension.
The problem is strongly correlated with whether the opened folder is a git repository.
A simple workaround is running git init in the folder.
What version of the IDE extension are you using?
ChatGPT extension: openai.chatgpt v26.415.20818
What subscription do you have?
ChatGPT Plus
Which IDE are you using?
VS Code: 1.116.0
What platform is your computer?
25.3.0 arm64 arm
What issue are you seeing?
When I open the Codex panel in VS Code inside a non-git folder on macOS, CPU usage becomes abnormally high almost immediately.
The main symptom is that VS Code renderer processes (
Code Helper (Renderer)) jump to roughly 200%–300%+ CPU, and the machine becomes noticeably hot. In some runs, the plugin process also becomes elevated.I narrowed this down with multiple A/B tests:
openai.chatgpt, opening Codex in a non-git folder reproduces the high CPU issue..gitshell viagit initis enough to make the problem disappear.The most relevant log pattern I found is repeated warnings like:
worker_rpc_response_error error={} method=stable-metadata workerId=gitI also saw VS Code git logs repeatedly reporting:
fatal: not a git repository (or any of the parent directories): .gitThis makes it look like Codex may be repeatedly requesting git-related stable metadata in a non-git workspace and entering a retry/error loop that drives renderer/plugin CPU very high.
What steps can reproduce the bug?
Example:
mkdir -p ~/Desktop/codex-nongit-reproOpen the Codex panel and interact with it briefly.
Observe process usage.
In my case, one or more
Code Helper (Renderer)processes quickly rise to about200%–300%+CPU.For A/B comparison, in the same folder, run:
Then reopen the same folder and open Codex again.
After
git init, CPU usage returns to normal or near-normal, and the issue is no longer reproducible in the same way.I also reproduced the same pattern in my normal VS Code environment:
git initor in a real git repository -> normal behaviorWhat is the expected behavior?
Codex should behave normally in both git and non-git folders.
If git metadata is unavailable, I would expect Codex to gracefully detect that situation, skip git-specific metadata work, or fall back without entering a high-frequency retry/error loop.
Opening the Codex panel in a normal non-git project folder should not cause renderer/plugin CPU usage to spike to several hundred percent.
Additional information
Important observations:
This is reproducible in a completely clean VS Code environment with only openai.chatgpt installed.
This does not appear to require any other third-party extension.
The problem is strongly correlated with whether the opened folder is a git repository.
A simple workaround is running git init in the folder.