VS Code extension sandbox leaves empty .git directory, causing Git discovery CPU spin

Open 💬 2 comments Opened Jun 17, 2026 by hkwi

Summary

When using the Codex VS Code extension in a non-Git workspace on a Linux remote environment, Codex sandbox setup appears to leave an empty .git directory on the host workspace root. VS Code Git then repeatedly treats the folder as a Git repository candidate and spawns git rev-parse --show-toplevel, causing the VS Code extension host to consume high CPU continuously.

Environment

  • VS Code Server: 1.124.2
  • Codex VS Code extension: openai.chatgpt 26.609.30741 linux-x64
  • Platform: Linux remote environment, likely WSL2
  • Codex sandbox: workspace-write / bubblewrap
  • Observed affected workspaces:
  • $HOME/avatra
  • $HOME/tmp/cf

Observed Behavior

  1. The workspace is not a Git repository and initially has no valid .git directory.
  2. After using Codex in the workspace, an empty host-visible .git directory appears at the workspace root.
  3. The directory has no .git/HEAD.
  4. VS Code Git repeatedly runs:

``text
git -c core.hooksPath=/dev/null -c core.fsmonitor= rev-parse --show-toplevel
``

  1. Git fails with:

``text
fatal: not a git repository (or any of the parent directories): .git
``

  1. The VS Code extension host stays at roughly 50-65% CPU.

Evidence

For one affected extension host PID, a 10 second strace sample showed:

  • 70,503 syscalls
  • 4,256 execve calls
  • 304 clone calls
  • 611 wait4 calls
  • 211 /usr/bin/git executions in $HOME/tmp/cf

The repeated command was:

git -c core.hooksPath=/dev/null -c core.fsmonitor= rev-parse --show-toplevel

The trace showed:

  • $HOME/tmp/cf/.git exists
  • $HOME/tmp/cf/.git/HEAD returns ENOENT

The same pattern was previously observed in another workspace, with 324 git rev-parse executions in 10 seconds.

A Codex sandbox command line also included a mount entry like:

--tmpfs $HOME/tmp/cf/.git --remount-ro

That suggests the sandbox may be creating a host-side mountpoint for .git, then leaving the empty directory behind after sandbox use.

Expected Behavior

Codex sandbox setup should not leave an empty .git directory on the host filesystem for a non-Git workspace. If a private .git mount is needed inside the sandbox, it should not persist as a host-visible directory after the sandbox exits.

Actual Behavior

An empty host-visible .git directory remains. VS Code Git sees it and repeatedly retries Git discovery, causing high CPU in the extension host.

Related Log Noise

The Codex log also repeatedly contains:

Received broadcast but no handler is configured method=thread-stream-state-changed

This may be separate, but strace shows the dominant CPU source is the Git discovery loop caused by the empty .git directory.

Feedback UI Issue

I also attempted to submit this via /feedback. The UI showed no confirmation and no session ID, although the Codex manual says a session ID should be shown after submission.

The local Codex log contains:

codex_app_server::request_processors::feedback_doctor_report: timed out running doctor report for feedback; skipping attachment

So I cannot tell whether the in-product feedback submission actually succeeded.

Workarounds

  • Remove the empty .git directory with rmdir <workspace>/.git
  • Disable Git integration for the affected workspace:

``json
{
"git.enabled": false
}
``

  • Reload or restart the VS Code extension host

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗