Repository navigation
High CPU usage in VS Code when opening Codex panel in a non-Git workspace #20295
Description
What version of the IDE extension are you using?
26.422.71525
What subscription do you have?
ChatGPT Pro
Which IDE are you using?
VS Code
What platform is your computer?
Darwin 25.4.0 arm64 arm
What issue are you seeing?
Opening the Codex panel in VS Code causes CPU usage to spike immediately and remain high. Disabling the Codex extension and restarting VS Code makes CPU usage return to normal.
This appears to happen when the current VS Code workspace is not a Git repository.
Environment:
- OS/platform: Darwin 25.4.0 arm64 arm
- VS Code: 1.118.1
- Codex VS Code extension: openai.chatgpt@26.422.71525
- Architecture: Apple Silicon / darwin-arm64
- Workspace type: local folder, not a Git repository
Observed high-CPU processes:
- Code Helper (Renderer): roughly 90% to 200%+
- Code Helper (Plugin): roughly 30% to 50%
What steps can reproduce the bug?
- Open VS Code with a folder that is not a Git repository.
- Enable the Codex VS Code extension.
- Open the Codex panel/window.
- Observe CPU usage in Activity Monitor or VS Code Process Explorer.
What is the expected behavior?
Codex should handle non-Git workspaces gracefully. Opening the Codex panel in a folder that is not a Git repository should not cause sustained high CPU usage, repeated Git metadata requests, or log flooding.
Additional information
No response
Activity
github-actions commentedon Apr 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
m13v commentedon Apr 30, 2026
i chased almost this exact symptom in a vscode extension last fall. renderer pinned around 180%, plugin host another 40, and the smoking gun was a file watcher kicking off a git status check on every fs event. in a non-git folder the spawn fails fast, the watcher retries, and you get a tight loop that never backs off. cheap repro: strace/dtrace the helper for a few seconds and count git invocations. the fix for us was caching the not-a-repo result for the workspace lifetime instead of re-probing on each tick.