High CPU usage in VS Code when opening Codex panel in a non-Git workspace

Resolved 💬 2 comments Opened Apr 30, 2026 by BinruiHuang Closed Apr 30, 2026
💡 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?

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?

  1. Open VS Code with a folder that is not a Git repository.
  2. Enable the Codex VS Code extension.
  3. Open the Codex panel/window.
  4. 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_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19644
  • #19699
  • #19642
  • #19327
  • #18775

Powered by Codex Action

m13v · 4 months ago

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.