codex - 💡(How to fix) Fix VS Code Codex extension burns sustained CPU while waiting for a workspace to become a Git repository

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

The Codex VS Code extension entered an apparent tight loop in a WSL remote workspace that was not yet initialized as a Git repository.

Codex had not been asked to perform any Git-related operation. The workspace was a temporary project, and I intentionally had not run git init.

Despite being idle, the remote VS Code extension-host Node process consumed approximately 47% of one CPU continuously for an extended period, causing significant fan activity.

Initializing Git in the project caused the CPU usage to stop.

Error Message

  • htop showed the remote extension-host Node PID continuously using approximately 47% CPU.
  • VS Code Process Explorer incorrectly showed only approximately 0–2% CPU for the same PID.
  • The hot thread was the Node MainThread.
  • A V8 CPU profile showed the overwhelming majority of samples beneath the OpenAI extension calling child_process.spawn().

Root Cause

  • Sustained unnecessary CPU use
  • High fan speed and power consumption
  • Potentially hours of wasted CPU time
  • Difficult diagnosis because VS Code Process Explorer substantially under-reports the remote process CPU usage

Code Example

openai.chatgpt.../out/extension.js
  -> child_process.spawn()
     -> node:internal/child_process spawn
        -> native spawn

---

handleGitInit
ensureWatchingForGitInit
checkForGitDirectory
getStableMetadata
getStableRootMemoized
invalidateStableMetadata

---

ensureWatchingForGitInit
checkForGitDirectory
handleGitInit
getStableMetadata
getStableRootMemoized
RAW_BUFFERClick to expand / collapse

Profile attached: node-cpuprofile.json

Description

The Codex VS Code extension entered an apparent tight loop in a WSL remote workspace that was not yet initialized as a Git repository.

Codex had not been asked to perform any Git-related operation. The workspace was a temporary project, and I intentionally had not run git init.

Despite being idle, the remote VS Code extension-host Node process consumed approximately 47% of one CPU continuously for an extended period, causing significant fan activity.

Initializing Git in the project caused the CPU usage to stop.

Environment

  • VS Code Remote – WSL
  • Ubuntu under WSL
  • Codex/OpenAI extension: openai.chatgpt-26.602.30954-linux-x64
  • Remote VS Code extension host: ~/.vscode-server/.../out/bootstrap-fork
  • Node reported in WSL: v24.15.10

Observed behavior

  • htop showed the remote extension-host Node PID continuously using approximately 47% CPU.
  • VS Code Process Explorer incorrectly showed only approximately 0–2% CPU for the same PID.
  • The hot thread was the Node MainThread.
  • A V8 CPU profile showed the overwhelming majority of samples beneath the OpenAI extension calling child_process.spawn().

Representative call path:

openai.chatgpt.../out/extension.js
  -> child_process.spawn()
     -> node:internal/child_process spawn
        -> native spawn

The native spawn frame accounted for 4,978 samples in a roughly ten-second CPU profile.

Nearby OpenAI extension frames included:

handleGitInit
ensureWatchingForGitInit
checkForGitDirectory
getStableMetadata
getStableRootMemoized
invalidateStableMetadata

This strongly suggests that the extension was repeatedly spawning processes while polling for Git initialization or repository metadata.

Expected behavior

When a workspace is not a Git repository:

  • Codex should detect that state once and remain idle.
  • It may install a filesystem watcher for .git, but it should not repeatedly spawn processes or continuously poll.
  • An idle extension should consume effectively zero CPU.
  • Git repository initialization should not be required merely to keep the extension idle.

Actual behavior

The extension continuously consumed approximately half of one CPU core until the workspace was initialized as a Git repository.

Reproduction outline

  1. Open a non-Git directory in VS Code using Remote – WSL.
  2. Enable the Codex/OpenAI extension in the WSL environment.
  3. Do not run git init.
  4. Do not ask Codex to perform any Git-related operation.
  5. Observe the remote extension-host Node PID using sustained CPU in htop.
  6. Run git init in the workspace.
  7. Observe CPU usage return to normal.

Impact

  • Sustained unnecessary CPU use
  • High fan speed and power consumption
  • Potentially hours of wasted CPU time
  • Difficult diagnosis because VS Code Process Explorer substantially under-reports the remote process CPU usage

Suggested investigation

Inspect the retry or watcher logic around:

ensureWatchingForGitInit
checkForGitDirectory
handleGitInit
getStableMetadata
getStableRootMemoized

In particular, check whether a failed Git-root lookup or missing .git directory causes an immediate rescheduling loop with repeated child_process.spawn() calls and no delay or backoff.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

When a workspace is not a Git repository:

  • Codex should detect that state once and remain idle.
  • It may install a filesystem watcher for .git, but it should not repeatedly spawn processes or continuously poll.
  • An idle extension should consume effectively zero CPU.
  • Git repository initialization should not be required merely to keep the extension idle.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING