Skip to content

Windows 10 app 26.616.4196.0 repeatedly spawns Git root/metadata probes while idle #29110

Open
Open
Windows 10 app 26.616.4196.0 repeatedly spawns Git root/metadata probes while idle#29110
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

Description

@privacyguy123
privacyguy123
opened on Jun 19, 2026

What version of the Codex App are you using?

OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0

What platform are you using?

Windows 10 x64

Git for Windows:

git version 2.54.0.windows.1

What issue are you seeing?

With a local Git workspace open in the Codex Windows app, git.exe repeatedly appears in Sysinternals Process Explorer even when I have not explicitly asked Codex to run a Git command.

One repeatedly observed command is:

"C:\Program Files\Git\bin\git.exe" -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse --show-toplevel

Other Git metadata commands observed in the same app session include:

git.exe config --null --get core.fsmonitor
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain

I can provide a Process Explorer screenshot if useful. core.fsmonitor=false appears intentional; the problem is the repeated process creation, not that configuration override.

Why this may be distinct from existing reports

This resembles existing Windows issues, but the visible loop here is centered on root discovery and metadata refresh rather than the older snapshot/index commands:

The source path documented in #23207 identifies rev-parse --show-toplevel as part of the desktop git-origins worker. Current app-server source also creates Git enrichment per turn, concurrently collecting HEAD, remotes, and working-tree status. The status path probes core.fsmonitor for each metadata collection:

This suggests that a workspace/turn-metadata invalidation may be continuously retriggering one or both Git metadata paths. That is a hypothesis, not a confirmed root cause.

Steps to reproduce

  1. Start Codex Windows App 26.616.4196.0.
  2. Open or select a local Git repository workspace.
  3. Leave the project open without manually running Git commands.
  4. Open Sysinternals Process Explorer and filter for git.exe.
  5. Observe repeated short-lived git.exe processes, including rev-parse --show-toplevel.

Expected behavior

Repository root and metadata should be cached, debounced, or refreshed only after a relevant workspace/Git-state event. An idle Codex project should not continuously create Git processes.

Actual behavior

Git metadata probes continue to be spawned repeatedly while the project is idle.

Suggested diagnostics / fix direction

Please add structured logging or counters containing:

  • refresh reason / invalidating event
  • workspace path hash
  • Git command category
  • whether an identical metadata request is already in flight

Then ensure that git-origins and turn-metadata enrichment are debounced and deduplicated per workspace, with no repeated refresh without a relevant state change.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    performance
    on Jun 19, 2026

  2. github-actions commented on Jun 19, 2026

    @github-actions
    github-actionsBot
    on Jun 19, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. privacyguy123 commented on Jun 19, 2026

    @privacyguy123
    privacyguy123
    on Jun 19, 2026
    Author

    Caused by orphaned/broken .git folder being in .codex folder.

  4. privacyguy123
    closed this as completedon Jun 19, 2026

  5. privacyguy123 commented on Jun 29, 2026

    @privacyguy123
    privacyguy123
    on Jun 29, 2026
    Author

    Bug is back in new build downloaded today - the "fix" I said worked before isn't applicable anymore, there is no orphaned .git folder in .codex anymore.

  6. privacyguy123
    reopened this on Jun 29, 2026

  7. zhanghaonj-prog commented on Jul 13, 2026

    @zhanghaonj-prog
    zhanghaonj-prog
    on Jul 13, 2026

    I can reproduce this on a newer Codex Desktop build, and in my case the workspace did not contain an invalid or empty .git directory.

    Environment

    • Codex Desktop: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
    • OS: Windows 11 Pro 25H2, build 26200.8524
    • Git for Windows: C:\Program Files\Git\cmd\git.exe

    Reproduction and measurements

    With a task bound to a normal directory that was not inside any Git repository, the Codex Electron main process repeatedly launched:

    "C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

    Each invocation correctly failed with:

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

    A process monitor captured 20 top-level Git processes launched directly by ChatGPT.exe in 7.1 seconds, equivalent to approximately 169.1 launches per minute. Retry intervals were generally between 0.2 and 2.3 seconds. The parent was the Electron main process, not a renderer, GPU, or network-service process.

    The loop may be temporarily absent immediately after restarting Codex, then reappear following a workspace refresh or file change. This suggests that the failed repository-root lookup is being retriggered by workspace/filesystem invalidation rather than running only as a fixed startup timer.

    Controlled comparison

    I ran git init in the exact same working directory without staging or committing any existing files.

    After the directory became a valid repository:

    • the repeated failing rev-parse --show-toplevel calls stopped immediately;
    • Git activity fell from approximately 169/minute to 4–6/minute;
    • more than 10 minutes of monitoring showed no recurrence of the high-frequency loop;
    • the remaining calls were associated with real file changes, for example ls-files against a continuously updated log file.

    This strongly suggests that a negative result from repository-root discovery is not being cached/debounced, and is repeatedly invalidated for non-Git workspaces.

    Performance impact

    During the active loop, battery discharge reached approximately 36.71 W. WPR/WPA analysis also showed increased Microsoft Defender activity (WdFilter.sys / MsMpEng.exe) associated with the repeated process and filesystem activity. The loop correlated with occasional UI/mouse stuttering.

    I captured a pre-workaround WPR GeneralProfile + FileIO trace (approximately 1.8 GB) and can provide it if there is a secure upload location or if a smaller targeted trace is preferred.

    Suggested fix: cache the negative non-repository result and only invalidate it when the workspace path, a relevant parent path, or .git state actually changes. Repeated failures should also be deduplicated and use retry backoff.

  8. zhanghaonj-prog commented on Jul 13, 2026

    @zhanghaonj-prog
    zhanghaonj-prog
    on Jul 13, 2026

    Additional diagnostic reference: I submitted this through the Codex Desktop in-app feedback flow with the relevant conversation logs included.

    Shared session ID: 019f54cf-377e-7d42-b4d1-e7fd62b234d6

    This is the original session in which the high-frequency Git process creation, power impact, WPR trace, and before/after git init comparison were investigated.

  9. artemrizhov commented on Jul 13, 2026

    @artemrizhov
    artemrizhov
    on Jul 13, 2026

    Same problem with ChatGPT Codex for Windows on directory without .git.
    Version 26.707.62119

  10. rwang23 commented on Jul 14, 2026

    @rwang23
    rwang23
    on Jul 14, 2026

    I maintain an open-source, reversible Windows workaround for the visible Git/conhost window side of this problem:

    https://github.com/rwang23/codex-windows-console-guard

    It uses process-local Git/PowerShell/CMD wrappers and, for MSIX activation paths that bypass that local PATH, a narrowly scoped native guard. The guard hides only a ConsoleWindowClass window whose ancestry contains Git plus either current ChatGPT.exe or legacy Codex.exe.

    Safety boundaries are intentional: it does not replace the installed Git executable, change persistent user/system PATH, touch the registry, or hide unrelated terminals.

    Important limitation: this reduces the visible-window impact only. It does not reduce the underlying rev-parse/Git polling rate, prevent an orphaned Git process, or resolve the CPU/memory cost reported here. The upstream debounce, cancellation, and no-window process-launch fixes are still needed.

    The README is portable (no machine-specific clone path), includes install/rollback steps for users and agents, and documents the trade-offs of the optional PowerShell mitigations. I will keep the workaround updated as Windows desktop package behavior changes; package-version reports with redacted status output are welcome.

  11. suiyuebaobao commented on Jul 22, 2026

    @suiyuebaobao
    suiyuebaobao
    on Jul 22, 2026 – with ChatGPT Codex Connector

    The repeated Git root and metadata probes while idle here are the same class of Git-backed refresh workload I reproduced.

    I published a single-file Windows launcher for the original Microsoft Store/MSIX Codex app:

    It starts Codex with a process-scoped GIT_DIR=NUL. On my machine, the stable trace changed from 247 new git.exe and 137 new taskkill.exe processes per 10 seconds to 0 and 0 over 15 seconds; WMI Provider Host fell from about 6.6% to 0.9%.

    Usage: fully exit Codex from the Windows system tray, then run the script.

    This is an unofficial workaround, not an upstream fix. It deliberately disables or limits Review, Changes, branch detection, commit, and other Git-backed Codex features. It does not patch Codex, modify repositories or Git configuration, write system environment variables, require elevation, terminate processes, or remove chat history. Launching Codex normally restores Git integration.

  12. Evan-Haug commented on Aug 31, 2026

    @Evan-Haug
    Evan-Haug
    on Aug 31, 2026

    Two things to add here, one on the orphan sub-problem and one on the loop itself. I have filed the root cause separately as #41783 rather than repasting it, but the short version matters for this thread: the leftover git.exe processes several people mention are frozen before main() runs, inside detect_msys_tty() in git-for-windows compat/winansi.c, in a NtQueryObject(ObjectNameInformation) call on a stdio pipe handle that never returns and is not alertable. I confirmed it with a non-invasive cdb attach to six of them at 6.8 hours old; all six had the identical stack. Such a process cannot exit, cannot be timed out, and has KernelModeTime, UserModeTime, ReadOperationCount and WriteOperationCount all exactly 0 forever.

    On the producer, which is directly relevant to the hypothesis in the issue body.

    The three metadata commands listed here (remote -v, status --porcelain, and the config --null --get core.fsmonitor probe in front of the status path) are launched together by TurnMetadata::fetch_workspace_git_metadata in codex-rs/core/src/turn_metadata.rs:

    let (head_commit_hash, associated_remote_urls, has_changes) = tokio::join!(
    get_head_commit_hash(&self.cwd),
    get_git_remote_urls_assume_git_repo(&self.cwd),
    get_has_changes_in_repo(&self.cwd, repo_root),
);

    called from spawn_git_enrichment_task. So the turn_metadata.rs lead in the issue body is right for that half of the observed traffic; it is one concurrent fan-out per enrichment round, not three independent pollers. On my host the orphans arrived as two bursts spaced about 5 seconds apart, which is consistent with repeated enrichment rounds, though I would not read the exact per-burst composition as proof of anything.

    A cancellation path worth checking alongside the debounce fix.

    cancel_git_enrichment_task does task.abort(). That drops the in-flight futures, and with them the KillGitProcessTreeOnDrop guard in codex-rs/git-utils/src/git_process.rs. That guard has an impl Drop only under #[cfg(unix)], where it calls kill_process_group. On Windows there is no Drop impl, so cancellation relies on the JobObject handle drop plus tokio's kill_on_drop(true).

    That distinction matters here because of something I do not think has been stated in these threads: on a stock Git for Windows install git resolves to the cmd\git.exe shim, which spawns mingw64\bin\git.exe as a child. The process that wedges is therefore a grandchild, and kill_on_drop reaps only the direct child. I captured the two-level chain live:

    pid=28584  "git" -c safe.bareRepository=explicit -c core.hooksPath=NUL -c core.fsmonitor=false remote get-url origin
    ^ pid=35984 codex.exe ... app-server
pid=37004  git.exe -c safe.bareRepository=explicit -c core.hooksPath=NUL -c core.fsmonitor=false remote get-url origin
    ^ pid=28584 (the shim)

    To be fair to the code: spawn_git_command does job-contain on the success path, so I am not claiming this is broken outright. The gaps I would check are the uncontained Err(_) fallback (job: None, no Windows Drop, so only kill_on_drop is left), whether the app-server WorkspaceCommand exec path job-contains at all, and now this abort()-driven cancellation path. Details in #41783.

    Why the rate in this issue makes it worse rather than being a separate concern. A wedge only needs to happen occasionally to accumulate. At the ~169 launches/minute measured upthread, occasional is guaranteed. Fixing the debounce would cut the exposure even if the containment gap is fixed separately, so I do not think this issue is superseded by mine.

    One thing only you can answer, and I would find it genuinely useful. You are on git 2.54.0.windows.1; I am on 2.39.2.windows.1. I could not determine whether current Git for Windows still has this hang, and I found no upstream fix for it. Next time you have leftover git.exe processes, could you check whether they show the zero-work signature?

    Get-CimInstance Win32_Process -Filter "Name='git.exe'" |
  Select-Object ProcessId, KernelModeTime, UserModeTime,
                ReadOperationCount, WriteOperationCount,
                @{n='ageMin';e={[math]::Round(((Get-Date) - $_.CreationDate).TotalMinutes,1)}}

    All four columns zero on a process more than a couple of minutes old is the wedge. If yours instead show non-zero reads, then your leftovers are a different failure from mine and 2.54 may already be safe, which is worth knowing before anyone recommends a Git upgrade as a workaround. If you want to confirm the stack directly, cdb.exe -p <pid> -pv -c "~*k; q" attaches without killing the process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions