Codex Windows App keeps spawning `git.exe status --porcelain=v1 -z` and leaves orphan `git.exe` / `conhost.exe` processes

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

• #16786
• #15620
• #16820

Powered by Codex Action

Same, I'm seeing git process being called multiple times per second hogging resources. Windows 10.

In my case it also calls git add -A, git add -u, git write-tree, git add -- files files... and git rev-parse. NON STOP.

I hit what looks like the same Windows Codex git/conhost churn issue, but with RAMMap evidence of kernel memory fallout.

RAMMap snapshot after the event:

• Page Table: 6.636 GiB
• Driver Locked: 0.375 GiB
• ProcessList entries in the .RMP snapshot: 210,410
• git.exe entries: 138,169
• conhost.exe entries: 69,607
• Current live git.exe count after the event: 0
• Current live conhost.exe count after the event: 4

So the active process churn had already stopped, but RAM stayed around 24-25 GiB used because the Page Table bucket remained huge. This caused severe system/game freezing symptoms after FH6 launch, with GPU usage dropping to single digits.

This seems more severe than normal CPU churn because the aftermath persists even after git.exe/conhost.exe are gone.

Adding a source-level datapoint and a proposed mitigation branch from a Windows/HDD reproduction.

Observed user impact:

• Codex Desktop/CLI work against a large repository can drive disk usage to 100% on a mechanical HDD.
• On older disks this can make the whole machine appear frozen, not just Codex.
• The suspicious process activity is repeated Git metadata collection, especially git status --porcelain-style worktree scans.

Source-level finding:

• codex-rs/core/src/turn_metadata.rs collects WorkspaceGitMetadata for turns.
• That path currently includes get_has_changes(cwd).
• get_has_changes is implemented in codex-rs/git-utils/src/info.rs using git status --porcelain.
• For large worktrees, and especially when run on an HDD, this can scan many small files and saturate disk I/O.
• This metadata is useful, but it is not important enough to block a turn or make the app keep hammering the disk.

Proposed mitigation:

I prepared a branch that keeps commit hash and remote URL metadata, but makes only the has_changes signal best-effort with a short timeout. If git status does not return quickly, turn metadata simply omits has_changes instead of continuing to wait on a full worktree scan.

Branch:
https://github.com/yuzhiyang1/codex/tree/codex/throttle-git-metadata-on-hdd

Compare:
https://github.com/openai/codex/compare/main...yuzhiyang1:codex:codex/throttle-git-metadata-on-hdd?expand=1

Testing performed locally:

• cargo check -p codex-core --tests
• just test -p codex-core turn_metadata_state_omits_has_changes_when_status_budget_expires
• cargo fmt -p codex-core --check
• just fix -p codex-core

Note: I tried to open a PR from the fork, but GitHub returned GraphQL: yuzhiyang1 does not have the correct permissions to execute CreatePullRequest, so I am leaving the branch here for maintainers to inspect or cherry-pick.

I am seeing what appears to be the same class of issue on Windows with the Codex desktop app.

In my case, opening or keeping a Git repository session active causes git.exe and conhost.exe to be spawned thousands of times per minute. ProcMon shows repeated git status --porcelain=v1 -z, rev-parse, remote, add -u, and write-tree commands with CODEX_SHELL=1. Some commands use a temporary Codex Git index via GIT_INDEX_FILE=<temp>\codex-index-...\index.

The additional impact I observed is Windows Nonpaged Pool growth, with PoolMon growth in tags such as Proc, MiP2, PsIn, and EtwS.

I filed a more detailed report here: https://github.com/openai/codex/issues/26812

I can reproduce a very similar issue on Windows after restarting Codex Desktop.

Environment

• OS: Windows
• Codex Desktop version: 26.609.41114
• Workspace: Git repository at D:\ProjTerra
• Repository state: one normal Git worktree only
• No active Python test/runner was running when the screenshots were taken

What I observe

After restarting Codex Desktop, the problem is still reproducible.

When the main Codex thread is focused, Task Manager shows roughly:

• Codex (22)
• Codex CPU: about 1.0%
• Memory: about 841 MB
• System CPU: about 16%

When I switch away from that main thread / the thread is unfocused, Task Manager expands to roughly:

• Codex (215) or previously Codex (269)
• Codex group CPU: about 20-25%
• System CPU: about 62-83%
• Memory: about 1.0-1.46 GB
• Many child processes appear, especially:
• Git for Windows
• conhost.exe
• node_repl.exe
• PowerShell / pwsh
• multiple Codex helper/renderer processes

When I focus the main thread again, the process tree shrinks back to a much smaller number of child processes and CPU drops.

This makes the issue look less like normal UI rendering cost and more like background workspace/thread/runtime restoration triggering a burst of Git/process polling.

Evidence from local checks

I captured one of the Git commands being spawned:

git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain
Local checks from the repository:
C:\Users\ml292\.codex\worktrees
is empty.
git worktree list --porcelain
shows only one worktree:
worktree D:/ProjTerra
branch refs/heads/codex/projterra-restructure-lab
A single Git status call is not extremely slow:
git -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain
elapsed: about 178 ms
So the high CPU does not appear to be caused by one slow Git command. It looks more like Codex Desktop repeatedly or concurrently spawning many Git status checks and console host processes.
I also closed the only visible pending subagent record before restarting Codex. After a full Codex Desktop restart, the issue still reproduced, so this does not look like a stale project task or leftover test runner.
Expected behavior
Codex Desktop should not spawn hundreds of Git/console/runtime child processes just because the user switches focus or changes thread context.
Workspace status polling should be throttled, deduplicated, cancellable, and child processes should be cleaned up promptly.
Actual behavior
Switching focus/thread context appears to trigger a large burst of Git/status/runtime process creation. This causes high CPU and makes the app difficult to use for long-running projects.
Why this may be related to this issue
This appears to match the issue description here: repeated Git status polling and many Git/conhost child processes on Windows.
The additional detail in my case is that the process explosion is strongly correlated with focus/thread switching:
focused main thread: Codex (22), low CPU
unfocused/switched thread: Codex (215+), high CPU
refocus main thread: process count drops again
I can provide screenshots showing both states.

<img width="1157" height="822" alt="Image" src="https://github.com/user-attachments/assets/49608e20-ec74-45c6-aed9-a670326dba50" />

<img width="1161" height="1279" alt="Image" src="https://github.com/user-attachments/assets/6a6e3ce5-55aa-4a99-a03b-0bd355081617" />

This should be treated as blocker severity for Codex Desktop.

Reason:
Codex Desktop is a coding agent whose primary workflow is opening Git workspaces. In affected workspaces, the app continuously spawns git.exe / git processes in the background while idle. On Windows, every spawned git.exe and the files it touches are inspected by Defender/corporate AV; on macOS, each git spawn can trigger Gatekeeper/code-signature checks via syspolicyd/trustd. This turns a background SCM watcher into a system-wide CPU/I/O storm.

This still appears reproducible on Codex Desktop 26.623.11225.0 on Windows. I opened #30926 with ETW/WPR evidence showing a link between repeated git.exe launches and Windows kernel Token / pool tag Toke growth.

In a mostly-idle trace, Codex.exe started git.exe 263 times in ~54.6 seconds, mostly for:

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

The kernel stack for the corresponding Toke allocations goes through NtCreateUserProcess -> PspInitializeProcessSecurity -> SeSubProcessToken -> SepDuplicateToken. Closing Codex stopped new Token objects growth; reopening Codex resumed it.

I can reproduce a very similar issue on Windows with the Codex desktop app: while Codex is open on a local Git repository, it spawns an extremely large number of git.exe and conhost.exe processes. In my case this does not only cause CPU/process churn; it also causes Windows kernel pool growth until physical memory is exhausted.

codex-windows-git-polling-bugreport.md

Windows desktop app: ETW-confirmed runaway git rev-parse, hidden kernel-memory growth; CLI unaffected

I reproduced what appears to be the same bug class on a current Windows desktop build, with a different repeated Git command and severe hidden memory growth.

Environment

• Windows 11 23H2, build 22631.6199, x64
• Codex/ChatGPT desktop app: package build 26.707.3748.0; user-visible/plugin build 26.707.31428
• Git for Windows
• Standalone Codex CLI tested separately: 0.144.0-alpha.4

Reproduction and process evidence

With the desktop GUI open, the ChatGPT.exe host repeatedly launched:

git.exe -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

Each root Git process launched another git.exe and usually a conhost.exe.

Windows Performance Recorder ETW traces showed:

• 1,039 repeated rev-parse --show-toplevel process rows in one short capture
• 1,113 total Git process rows
• 567 conhost.exe rows
• Every repeated root Git probe was a direct child of the same ChatGPT.exe host

Restarting the desktop app changed the host PID but immediately reproduced the loop. Initializing the working directory as a Git repository did not stop it.

Memory impact

Physical memory rose to 97–99% after roughly 45–120 minutes with 3 codex windows open, while Task Manager's Processes page did not account for most of it. A high-memory Resident Set trace showed approximately:

• 3.63 GB page tables
• 3.82 GB working-set metadata
• 2.69 GB nonpaged pool
• 0.53 GB driver-locked system pages

The PageTable category contained 1,548 git.exe instances and 816 conhost.exe instances. About 7.1 GB of page-table/working-set metadata was attributed to terminated/unknown process instances. A reboot was required to reclaim the stranded kernel memory.

Desktop-vs-CLI validation

After closing the desktop GUI and rebooting, I used only standalone Codex CLI. Two sparse snapshots about 12 minutes apart showed:

| Counter | Start | End | Delta |
|---|---:|---:|---:|
| ChatGPT.exe | 0 | 0 | 0 |
| Available memory | 23,833 MB | 23,723 MB | -110 MB |
| Committed bytes | 9.032 GB | 9.204 GB | +0.172 GB |
| Paged pool | 0.294 GB | 0.301 GB | +0.007 GB |
| Nonpaged pool | 0.393 GB | 0.397 GB | +0.004 GB |
| Process count | 145 | 151 | +6 |
| Resident git.exe | 0 | 0 | 0 |

Memory stayed near 25% during normal CLI use. This is sharply different from the GUI traces, where paged/nonpaged pools rose by roughly 0.17/0.19 GB in only five minutes and continued accelerating.

Other causes checked

• Reproduced with Task Manager closed
• Restarting the desktop app did not help
• The captured process trees did not contain the separate development-control application initially suspected

Current workaround

Keeping the Windows desktop GUI completely closed and using standalone Codex CLI avoids the observed process storm and memory growth. Closing only the window may not be sufficient if ChatGPT.exe remains in the background; I verify it is absent in Task Manager/PowerShell.

I can provide redacted WPR ETL summaries or exact counter data if useful. The raw ETLs may contain local paths, so I would prefer guidance on the minimum artifact needed before uploading them publicly.

Their recorded parent PIDs no longer existed.
Another 4 processes formed two outer/inner Git-for-Windows process pairs, executing:
git ... ls-files --others --exclude-standard -z

The remaining process was a transient repository probe:
git rev-parse --show-toplevel

The directly spawned Git wrapper processes were children of ChatGPT.exe, from the Codex desktop package version OpenAI.Codex_26.707.6957.0_x64.

Process working-directory inspection showed:
6 orphaned status workers running at one mapped-drive Android monorepository root.
10 orphaned status workers running at another mapped-drive Android monorepository root.
The opened Codex workspaces were narrower source/package directories, but the background Git commands were executed from the top-level monorepository roots.

Several workers had remained alive for hours and continued accumulating CPU time.

Project names, usernames and full local paths have been omitted from this report.
Cleanup and respawn behavior
I terminated 20 stale status / ls-files workers.
Immediately afterward, Codex launched 3 replacement Git processes, including a new ls-files pair. The old heavy scans were cleared, but Codex continued periodically spawning short-lived rev-parse --show-toplevel probes.
This confirms that the processes were being created by Codex background repository inspection rather than by a terminal command or a user-started Git operation.
Installed application inspection
Inspection of the installed Codex application's resources/app.asar shows that its Git runner:
Adds -c core.hooksPath=NUL.
Adds -c core.fsmonitor=false for these repository scans.
Spawns Git with process-tree termination requested.
Calls the child-process kill routine when an operation is aborted or times out.
Runs both repository status collection and ls-files --others --exclude-standard -z for untracked-file discovery.
The UI-side repository inspection code repeatedly invokes these operations to build Git status summaries.
However, the observed Git-for-Windows process lineage showed that the outer executable under the Git cmd directory exited while the inner executable under mingw64\bin remained alive.
This suggests that the current Windows process-tree cleanup does not reliably terminate the inner Git-for-Windows process after the outer wrapper exits. Once that happens, the remaining worker becomes orphaned and later refreshes can create additional workers.
Likely contributing conditions
The issue appears particularly easy to trigger when:
A Codex workspace is located below a very large monorepository.
The repository is accessed through a mapped Windows drive.
Multiple Codex tasks or workspaces resolve to the same repository root.
A full-root git status or untracked-file scan is aborted, times out, or is superseded by another refresh.
Expected behavior
Abort, timeout and application exit should terminate the complete Git-for-Windows process tree, including the inner mingw64\bin\git.exe process.
Status scans resolving to the same repository root should be deduplicated.
A previous scan should be cancelled and fully reaped before a replacement scan starts.
Large or mapped-drive repositories should not cause unbounded full-root background scans.
Codex should provide a supported setting to disable, debounce or limit background Git status/untracked-file scanning.
Closing Codex should leave no orphaned git.exe or related console-host processes.
I verified the command lines, process parent relationships, creation times, CPU accumulation and process working directories. I can provide a further sanitized process table if the maintainers need it.

I can reproduce this class of issue on a newer Windows Codex desktop build, including persistent orphaned Git-for-Windows children and measurable memory/handle cost.

Environment

• Windows 11 Home, build 10.0.26200, x64
• Codex Desktop package: OpenAI.Codex_26.707.8479.0_x64
• Git for Windows: 2.53.0.windows.1
• 16 GB physical RAM
• Reproduced while the active Codex workspace was a non-Git directory

Process evidence

During active Codex use I observed approximately 60–67 surviving git.exe processes. Their command lines were Codex read-only metadata probes such as:

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

Current probes could be traced from codex.exe through the Git-for-Windows wrapper. For the older surviving processes, the recorded parent PID no longer existed or had been reused. The oldest processes remained for more than seven minutes with near-zero CPU, mostly waiting in the Windows Executive wait state.

At roughly 60 processes, the pool held about:

• 2.0 GiB private committed memory
• 427 MiB working set
• 6,120 handles
• 101 threads
• only 0.77 accumulated CPU-seconds

An identical manual rev-parse HEAD invocation from the same non-Git workspace exited in 35 ms, while the Codex-launched copies remained alive.

User impact

With the larger pool present, the 16 GB machine showed about 73% commit use, 922 MB in Windows memory compression, pagefile use, and page-read spikes up to roughly 140/sec. Closing other Codex sessions improved responsiveness but did not return the machine to post-reboot behavior. The user also reports that a complete Codex quit during an update did not clear the already-orphaned Git processes; restarting Windows did.

Expected behavior

Read-only metadata probes should have a bounded timeout and their complete Git-for-Windows process tree should be reaped when the request is cancelled, superseded, or the app exits. A failed/non-Git workspace probe should exit promptly rather than leave the inner mingw64\bin\git.exe process behind.

I can provide a sanitized process table or additional counter sampling if maintainers need it. Usernames, repository names, and full local paths have been omitted.

Windows corroboration on current package OpenAI.Codex_26.707.9564.0 (Windows 11 Pro for Workstations 10.0.26200, 16 logical CPUs, 64 GB RAM).

A workspace was nested beneath an unintended empty/unborn parent Git repository that covered a much broader directory tree. With Codex Desktop open, I observed 71 persistent git.exe processes. Most no longer had live parents; one app-owned git add process was consuming CPU. The repeated Codex Git invocations included the -c core.hooksPath=NUL pattern described here.

The parent repository had no usable branch ref, index, or reflog, so it was not serving as a real working repository. Reversible local mitigation:

1. Stop the Codex-owned Git processes.
2. Preserve and disable that unintended parent .git directory.
3. Reopen/continue from the intended nested repository.

Afterward, a 20-second sample repeatedly returned to zero Git processes, with only occasional 0-1 short-lived metadata probes. The intended nested repository still resolved its own HEAD correctly.

This is useful as a trigger condition: a broad, unborn parent repository can make the app's Git polling/snapshot behavior expand across a large tree, and cancelled/superseded Git children are not reliably bounded or reaped. Absolute paths and project names are omitted.

I encountered the same issue on Windows, but it escalated into complete system resource exhaustion.

Environment

Codex Desktop on Windows

Bundled Codex version recorded in the affected transcript: 0.144.0-alpha.4

Git-backed local workspace

32 GB physical RAM

Feedback/log upload ID: 019f5c01-9d37-7ff1-b417-ca5c7db5fb47

Trigger and timeline

The agent performed three sequential PowerShell collection passes over 109 website detail pages. These were sequential Invoke-WebRequest loops, not 109 parallel commands or browser tabs.

The bulk collection finished at approximately 10:42 AM, and the final small document edit finished around 10:57 AM. A RAMMap snapshot timestamped approximately 11:15 AM showed that process spawning had continued after the commands completed, while no shell or browser collection command was active.

The affected transcript contains no agent-authored Git commands.

RAMMap evidence

The snapshot contained 225,324 distinct process IDs:

147,074 git.exe

74,494 conhost.exe

719 powershell.exe

237 ChatGPT.exe

441 Codex-family helper processes

git.exe and conhost.exe represented 98.33% of all processes. The ratio was approximately 1.974 Git processes per console host.

Memory state:

Approximately 31.10 GiB usable physical memory

Approximately 27.12 GiB active

Approximately 174.6 MiB immediately free or zeroed

Approximately 7.14 GiB consumed by page tables

Explorer became unresponsive/crashed, and Windows required a full restart.

The transcript recorded only 33 shell-command invocations and 15 browser-tool calls across the entire multi-hour session, so the 147,074 Git processes were not directly launched by agent-authored Git commands. This appears consistent with a runaway internal Git/workspace polling, status, retry, watcher, or cleanup loop.

I uploaded the affected session and logs privately through /feedback using the ID above. I also retained the original RAMMap snapshot and can provide it privately if maintainers request it.

Still reproducible on Windows with Codex App 26.707.12708.0.

Environment

• Windows 11 x64
• Codex App: 26.707.12708.0
• Git for Windows: 2.53.0.windows.3
• 16 GB RAM

Observed behavior

• Codex periodically spawned up to 32 concurrent git.exe processes.
• 28 processes were orphaned for more than 10 seconds.
• The orphaned processes were idle, with zero CPU usage during a 3-second sample.
• Commands included:
• git status --porcelain
• git rev-parse HEAD
• git remote -v
• git config --get core.fsmonitor
• Switching between three threads caused peaks of 14–17 Git processes.
• The Codex process group's working set temporarily increased from approximately 1.4 GB to nearly 3.0 GB.
• Available system memory dropped to approximately 2 GB during thread switching.
• UI delays were noticeable when sending messages and switching threads.

Additional diagnostics

• Restarting the Codex App temporarily reduced the Git process count, but the processes returned shortly afterward.
• Terminating only confirmed orphaned and idle Git processes did not resolve the issue; Codex recreated a similar number almost immediately.
• Running the same Git commands manually completed in approximately 66–121 ms, including when executed outside a Git repository.
• This suggests that Git and disk performance are not the bottleneck. The issue appears related to child-process lifecycle management or repeated repository-status polling in the Windows Codex App.
• No automated process-killing script or watchdog is being used.

The behavior is still reproducible on a substantially newer App version than the one originally reported.

Windows corroboration on the current desktop package 26.707.12708.0: we still observed Codex-owned Git console surfaces while the app was active, including both ConsoleWindowClass and PseudoConsoleWindow owners. That makes the user-visible flashing a separate problem from the underlying orphan/process-lifecycle bug reported here.

I maintain a small, reversible local mitigation for the visible-window side:

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

The latest revision uses process-local GUI wrappers for Git/PowerShell/CMD plus a narrowly scoped native guard for AppX paths that bypass the launcher's local PATH. It records only the matched PID, executable, window class, and rule. It does not replace Git, modify persistent PATH or the registry, kill processes, or reduce the app's Git polling rate.

In other words, this can make the active Windows session usable while the app still has the lifecycle fault, but it is not a root-cause fix for the retained/orphaned git.exe and conhost.exe children. The upstream fix still needs bounded Git work and reliable cancellation/reaping when a workspace or task changes.

I’m seeing this on Windows as well, on Codex Desktop 26.707.9981.0.

Observed via elevated PowerShell:

Get-CimInstance Win32_Process -Filter "Name = 'git.exe'" |
  Select-Object ProcessId,ParentProcessId,CommandLine

Examples of the commands being spawned repeatedly:

git.exe -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse HEAD
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v
git.exe config --null --get core.fsmonitor
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain
"C:\Program Files\Git\cmd\git.exe" -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

One captured parent process was:

ParentName        : ChatGPT.exe
ParentCommandLine : "C:\Program Files\WindowsApps\OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe"

The storm restarted immediately after killing git.exe, stopped when Git was uninstalled or hidden, and resumed after reinstalling Git. It also persisted after changing ~/.codex/config.toml to remove a broad writable root, because the old writable root was still present in .codex-global-state.json under thread-writable-roots.

This looks like a Codex Desktop Git polling loop without sufficient backoff when Git calls fail, are slow, or return unexpectedly. A setting to disable background Git polling, plus exponential backoff and child-process cleanup, would be very helpful.

### What version of the Codex App are you using (From “About Codex” dialog)? 26.325.3894.0 ### What subscription do you have? On Windows, the Codex Windows App repeatedly spawns Git processes such as: - git.exe status --porcelain=v1 -z and also creates matching console host processes such as: - \??\C:\WINDOWS\system32\conhost.exe 0x4 After closing the Codex window, new processes stop appearing, but many existing git.exe / conhost.exe processes remain alive. Even after ending Codex.exe from Task Manager, the leftover Git-related processes are still present. This looks like the app is polling Git state very aggressively and not cleaning up child processes correctly on exit. ### What platform is your computer? _No response_ ### What issue are you seeing? <img alt="Image" width="2000" height="1106" src="https://private-user-images.githubusercontent.com/73658399/576000387-1638cc0a-dd13-461a-b128-7614c7bb6674.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQyNDEzNzIsIm5iZiI6MTc4NDI0MTA3MiwicGF0aCI6Ii83MzY1ODM5OS81NzYwMDAzODctMTYzOGNjMGEtZGQxMy00NjFhLWIxMjgtNzYxNGM3YmI2Njc0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA3MTYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNzE2VDIyMzExMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTZiNmY4NGZlZTJlNDQwMTE4ZWU3NmFlMjdjZmJmMDY0YzMwZTRhOWI5NTBlMGIzM2EyNTg1ZjdjZjVmNzhkZjMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.k7bNEMKa41BnC26jliGjlfu53AhqYLA07GzxtcnM4OE"> <img alt="Image" width="1161" height="789" src="https://private-user-images.githubusercontent.com/73658399/576001689-baabcb72-da01-4fc6-ae1c-b899d018b3a0.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQyNDEzNzIsIm5iZiI6MTc4NDI0MTA3MiwicGF0aCI6Ii83MzY1ODM5OS81NzYwMDE2ODktYmFhYmNiNzItZGEwMS00ZmM2LWFlMWMtYjg5OWQwMThiM2EwLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA3MTYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNzE2VDIyMzExMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWNhNWJmM2E0MjQyNTFjNDA3MjMzYTkzNGM0OGZiMmE4ZmZlMzQ3OGRkYzg3NmU1YzQ2NGUwMTcwMzExZTYwNTkmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.l0Lr4WG__iYW8TjzWEpiLE9nYkhqU1fwk1UA471Vtkg"> <img alt="Image" width="1161" height="790" src="https://private-user-images.githubusercontent.com/73658399/576001760-d55da594-4891-4a19-9aa3-b41c6d8b786a.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQyNDEzNzIsIm5iZiI6MTc4NDI0MTA3MiwicGF0aCI6Ii83MzY1ODM5OS81NzYwMDE3NjAtZDU1ZGE1OTQtNDg5MS00YTE5LTlhYTMtYjQxYzZkOGI3ODZhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA3MTYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNzE2VDIyMzExMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTgzNzZmYTBiZDcyMjlhMzBiNGIxMzYwMjgzM2MwMTQ1YzRjYzg5ZjEyN2M0YmFmNDRkZjkzYmQxZGYyN2JmZmYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.o5_j-NmsrFmFrcw8e9B5vuVTEauE7dkpgImS09x6c6k"> C:\Users\root\Documents\New project\ is the default project directory used by Codex. ### What steps can reproduce the bug? 1. Open Codex Windows App. 2. Open a Git repository. 3. Observe Task Manager / Process Explorer. 4. Notice repeated creation of: git.exe status --porcelain=v1 -z conhost.exe 0x4 5. Close the Codex app window. 6. New Git processes stop appearing, but many previously created git.exe / conhost.exe processes remain. 7. End Codex.exe manually in Task Manager. 8. Leftover git.exe / conhost.exe processes are still not cleaned up. ### What is the expected behavior? _No response_ ### Additional information _No response_

I can reproduce this on Windows 11 with 32 GB RAM. It occurs in both the Codex desktop app and the VS Code Codex extension.

It also reproduces in a completely clean test folder, after resetting the shared .codex folder, and even when the prompt explicitly says not to use Git.

Recorded results:

2,837 git.exe and 1,408 conhost.exe launches in 45 seconds
Another test produced 2,065 git.exe and 1,033 conhost.exe launches in 60 seconds
PoolMon showed rapidly increasing Proc, MiP2 and PsIn allocations
RAM eventually reaches 90–99%
Windows desktop package: OpenAI.Codex 26.707.12708.0
Codex runtime observed: 0.144.5

Closing Codex stops new launches, but restarting Windows is required to fully recover the leaked memory.

Additional confirmed reproduction on Codex Windows desktop app version 26.707.12708.0.

While the agent is working, short-lived console windows repeatedly flash, take focus, and can capture keystrokes while the user is typing in another application.

I captured a 15-second process trace after stopping unrelated browser/agent daemons. The repeated process chain was:

ChatGPT.exe
  -> powershell.exe
       -> conhost.exe

A fresh PowerShell/conhost pair was created roughly every 1–2 seconds. The captured PowerShell commands show that this is the desktop app's process-manager polling rather than repository work alone. The commands repeatedly query:

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
Get-CimInstance Win32_Process

They collect process IDs, parent IDs, command lines, working-set size, CPU percentage, and process age, then convert the results to JSON.

Further observations:

• The direct parent of each polling powershell.exe was ChatGPT.exe.
• The installed app bundle appears to request windowsHide: true for this polling call, but a visible focus-stealing console still occurs.
• Enabling the stable unified_exec feature and fully restarting Codex changed the controlled command backend to PowerShell 7, but did not stop these desktop-app polling launches or the visible flashes.
• The issue reproduces in a project-independent Codex task and with unrelated gstack/browser processes stopped.
• This is more than process churn: the temporary console steals focus and interrupts/captures typing.

This may also relate to the focus/terminal ownership symptoms in #23485, although this reproduction isolates the Windows desktop process-manager polling path specifically.

Additional confirmed reproduction on Codex Windows desktop app version 26.707.12708.0. While the agent is working, short-lived console windows repeatedly flash, take focus, and can capture keystrokes while the user is typing in another application. I captured a 15-second process trace after stopping unrelated browser/agent daemons. The repeated process chain was: `` ChatGPT.exe -> powershell.exe -> conhost.exe ` A fresh PowerShell/conhost pair was created roughly every 1–2 seconds. The captured PowerShell commands show that this is the desktop app's process-manager polling rather than repository work alone. The commands repeatedly query: Get-CimInstance Win32_PerfFormattedData_PerfProc_Process Get-CimInstance Win32_Process They collect process IDs, parent IDs, command lines, working-set size, CPU percentage, and process age, then convert the results to JSON. Further observations: * The direct parent of each polling powershell.exe was ChatGPT.exe. * The installed app bundle appears to request windowsHide: true for this polling call, but a visible focus-stealing console still occurs. * Enabling the stable unified_exec` feature and fully restarting Codex changed the controlled command backend to PowerShell 7, but did not stop these desktop-app polling launches or the visible flashes. The issue reproduces in a project-independent Codex task and with unrelated gstack/browser processes stopped. This is more than process churn: the temporary console steals focus and interrupts/captures typing. This may also relate to the focus/terminal ownership symptoms in #23485, although this reproduction isolates the Windows desktop process-manager polling path specifically.

Thanks — this appears closely related and confirms an additional Windows process-spawning loop in the same desktop build.

Your trace isolates repeated desktop process-manager polling:

ChatGPT.exe → powershell.exe → conhost.exe

My main reproduction appears to involve an additional Git polling/retry loop. In a clean isolation test, I recorded:

• 2,837 git.exe launches in 45 seconds
• 1,408 conhost.exe launches in 45 seconds
• Another test produced 2,065 git.exe and 1,033 conhost.exe launches in 60 seconds
• Rapidly increasing PoolMon Proc, MiP2 and PsIn allocations
• RAM eventually reaching 90–99%

It reproduces in:

• Codex Windows desktop app 26.707.12708.0
• VS Code Codex extension/runtime 0.144.5
• A completely clean test project
• A fresh Codex conversation
• After moving/resetting the shared .codex folder
• Even when the prompt explicitly instructs Codex not to run Git commands

This suggests there may be two overlapping Windows loops: the desktop process-manager polling described here and a broader Codex Git-state polling/retry loop.

Could a maintainer confirm whether these are believed to share the same root cause?

Is there currently any reliable workaround, feature flag or configuration setting that can disable the repeated Git polling and process-manager polling? Would running through WSL avoid the affected native Windows path, or is the only safe option to use Codex cloud and wait for a corrected release?

Also, is resetting or reinstalling the existing build expected to help, or will this require an updated Codex runtime/app version?

Adding another quantified reproduction of the orphaned git.exe accumulation on Windows.

Environment

• Codex Windows desktop MSIX package: OpenAI.Codex_26.707.9981.0_x64
• ChatGPT.exe file version: 150.0.7871.115
• Git for Windows: 2.51.0.windows.1
• Git executable: C:\Program Files\Git\cmd\git.exe
• Observed: 2026-07-17 (Europe/Berlin)

Direct process measurements

At the first snapshot there were 144 live git.exe processes. After one additional Codex tool execution, the count was 151 (+7).

Command distribution in the 144-process snapshot:

• 36 × git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v
• 35 × git.exe config --null --get core.fsmonitor
• 33 × git.exe -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse HEAD
• 29 × git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain
• 6 × git.exe -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse --git-dir
• a few additional remote get-url origin / rev-parse --abbrev-ref HEAD probes

Almost every recorded immediate parent process had already exited. The Git processes were mostly idle (typically 0–0.03 seconds of accumulated CPU) but remained alive.

Aggregate resource use at 151 processes:

• Working set: 862.5 MB
• Private memory: 4,945.9 MB
• Handles: 13,920
• Threads: 181

Thread-state summary:

• 147 × Wait / Executive
• 30 × Wait / EventPairLow
• 3 × Wait / UserRequest
• 1 × Running

This looks like blocked/orphaned repository-metadata probes, not merely frequent short-lived polling. The reporter also observes that the accumulated processes remain after fully closing Codex, matching the original report.

One potentially related data point: during the same investigation, ordinary sandboxed PowerShell launches repeatedly failed with CreateProcessAsUserW failed: 1312 (“A specified logon session does not exist”). Process inspection outside that sandbox path still worked. I cannot yet prove that error is causally related to the orphaned Git children, but it may help narrow the Windows process/token lifecycle path.

Additional Windows reproduction on Codex Desktop 26.715.2305.0, including parent-lifecycle and PID-reuse checks.

At 00:56:29 local time:

• 178 git.exe processes were alive.
• 161 had no live recorded parent.
• 149 orphan candidates were older than two minutes.
• 147 exactly matched read-only Codex metadata probes:
• config --null --get core.fsmonitor
• rev-parse HEAD / --git-dir
• remote -v
• status --porcelain

Parent validation distinguished genuinely missing parents from reused PIDs by comparing parent and child creation times.

During a second observation at 00:58:47–00:58:53:

• 71 common candidate PIDs showed no CPU delta.
• None of those PIDs exited.
• The candidate count increased from 71 to 72.
• 88 git.exe processes still remained after an earlier conservative partial cleanup.

The proven orphan probes accounted for up to approximately 950 MB working set and 258 MB private memory.

Expected:
Git metadata probes terminate with their owning request or parent process.

Actual:
Read-only metadata workers remain alive and idle after the parent disappears, while subsequent refreshes create additional workers.

Temporary mitigation:
Only proven orphan metadata probes were terminated, using an exact command allowlist, missing/reused-parent validation, an age gate, and a five-second zero-CPU gate. Active Git operations and the main Codex process were not touched.

Additional quantified reproduction on Codex Windows desktop 26.715.4045.0, with a valid Git repository and a visible Not Responding UI state.

Environment

• Codex MSIX package: OpenAI.Codex_26.715.4045.0_x64
• Desktop executable product version: 150.0.7871.124
• Windows 10 Pro 22H2, build 19045.6456, x64
• Git for Windows: 2.54.0.windows.1
• Native Windows workspace on a local drive
• The workspace is a valid private Git repository. Its name, remote, paths, and contents are intentionally omitted.
• No WSL process was running and WSL_DISTRO_NAME was absent.

Visible reproduction

A 21-second local recording shows this sequence:

1. Launch Codex.
2. The sidebar and local project list load normally.
3. The empty project overview appears; no conversation is opened.
4. At approximately 15 seconds, the window title changes to ChatGPT (Not Responding).
5. The UI remains frozen through the end of the recording.

The recording is not attached publicly because it contains private project names and conversation titles. I can provide sanitized diagnostics through an appropriate private support channel.

Git process evidence

Codex repeatedly creates the following read-only metadata probes:

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

The immediate parent PIDs had already exited when sampled. The retained Git processes were idle, normally had one thread in Wait / Executive, used about 5.7 MB working set each, and held 93 handles each.

Observed progression:

• First cleanup: 39 confirmed orphaned read-only metadata probes were terminated. Within about eight seconds the main desktop process changed from Responding=False to Responding=True.
• Later recurrence: six confirmed orphan probes were present; the main process moved from Responding=False to Responding=True during a 15-second sample without user interaction.
• The count subsequently grew from 6 to 15 while Codex remained open.
• A later conservative snapshot found 16 candidates. All 16 were at least five seconds old, had missing parents, and showed no CPU delta during a five-second sample.
• Those 16 processes accounted for approximately 90.8 MB working set, 537.8 MB private memory, and 1,488 handles.
• After terminating only those 16 verified candidates, three new matching probes had already appeared eight seconds later. In that later sample the main UI process still reported Responding=False, so cleanup is temporary and does not recover every freeze.

No active Git operation was terminated. Candidate selection used an exact read-only command allowlist, a missing-parent check, a minimum age, and a zero-CPU gate.

Repository and Git differential checks

The same commands complete normally when run outside Codex in the same repository:

| Command | Exit | Duration |
| --- | ---: | ---: |
| rev-parse HEAD | 0 | 30.4 ms |
| remote -v | 0 | 18.0 ms |
| status --porcelain | 0 | 23.4 ms |
| config --null --get core.fsmonitor | 1 (unset, expected) | 18.8 ms |

This makes an intrinsically slow repository or broken Git installation unlikely.

Remediation already attempted

• Repaired the installed app.
• Uninstalled and reinstalled the Codex app twice.
• Installed all available Windows updates and rebooted.
• Rotated an oversized local diagnostics database and let Codex create a fresh one.
• Rebuilt the local Codex state/index from a reversible backup and quarantined old rollout history without deleting it.
• Started with a much smaller live history/state set.
• Confirmed the repository itself and the exact metadata commands are fast.

The hang still reproduces immediately after launch. The history/database cleanup reduced local state substantially but did not resolve this failure.

Current interpretation

High confidence: this is an app-side Windows child-process lifecycle, cancellation, or reaping failure around repeated Git metadata probes. Git itself and repository latency do not appear to be the bottleneck.

Moderate confidence: orphan-process/handle accumulation materially contributes to the renderer/UI hang. One cleanup directly coincided with recovery from Responding=False to True, but a later cleanup did not immediately recover the UI, so I cannot claim it is the only cause.

Possible secondary factor: the Chromium renderer/GPU process also consumed CPU during a freeze. A --disable-gpu launch remains a useful differential test, but the repeated orphaned Git probes are independently confirmed.

The Windows process-tree cleanup proposed in #30428 appears consistent with this reproduction: on timeout or cancellation, retain and reap the wrapper, terminate the full Windows child tree (for example with the established taskkill /PID <pid> /T /F pattern), and avoid overlapping metadata refreshes. Short-TTL deduplication/backoff for repository metadata probes would also limit recurrence. I am not claiming this is definitively the complete fix.

Questions for maintainers

1. Is the Windows process-tree cleanup proposed in #30428 expected to address the orphan mechanism tracked here?
2. Is there currently a supported feature flag or configuration to disable or back off background Git metadata polling on Windows?
3. Can support provide a private upload route for the recording and sanitized diagnostics if needed?

Reproduced on Windows with Codex Desktop 26.715.4045.0, ChatGPT/Chromium 150.0.7871.124, and bundled Codex CLI 0.145.0-alpha.18.

I observed repeated orphaned git.exe processes using these commands:

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

This also reproduced from a non-Git workspace under C:\Users\<user>\Documents\...: 8–20 Git processes accumulated, their parent processes had exited, and the Git processes remained alive. Over an 8-second delta measurement, each stuck process showed 0 CPU-time delta, 0 read bytes, and 0 write bytes; the threads were waiting, mostly with WaitReason=Executive.

Running the same commands manually from the same directory completed in 23–30 ms and returned exit code 128 with not a git repository. Only the processes started through Codex Desktop remained stuck. Killing the known probe processes reduced the count to zero, but a later user turn spawned eight again. No public or experimental feature flag in codex features list appeared to disable this Git probing.

Windows Error Reporting also recorded AppHangTransient events for ChatGPT.exe. This looks like the same child-process cleanup/polling bug reported here, still reproducible in 26.715.4045.0.

Follow-up with two important differential results from the same Windows reproduction:

--disable-gpu does not prevent the hang

Codex was launched through the packaged-app activation API with --disable-gpu. Process inspection confirmed the switch on the main desktop process and renderer processes.

The desktop still entered Responding=False. During a five-second frozen-state sample:

• main window process: 0.000 s CPU delta;
• measured main-process threads: 0.000 s CPU delta and waiting;
• GPU process: approximately 0.781 s CPU delta;
• busiest renderer: approximately 0.078 s CPU delta.

Windows Application log contains five formal event ID 1002 hangs for ChatGPT.exe version 150.0.7871.124 during the investigation period.

Windows Wait Chain Traversal, captured during a short responsive interval, reported the window thread as blocked but found no supported multi-node chain or deadlock cycle. This does not identify the waiting Chromium/Electron IPC path, but it rules out a simple WCT-visible mutex/COM cycle in that sample.

The UI can hang with zero orphaned Git probes

A bounded 45-second monitor kept a strict count of the known orphaned Git metadata probes. The main window changed from responsive to non-responsive while the orphan count remained zero throughout the measured period.

This means the orphaned Git lifecycle bug is real and independently reproducible, but it is not sufficient to explain every desktop UI hang.

Remote versus Windows delivery

While the Windows window remained Not Responding, the remote/mobile client sometimes displayed newly generated text first. Approximately ten seconds later, the Windows client rendered the same text in a batch, remained usable briefly, and then returned to Not Responding after roughly five seconds.

This suggests two layers:

1. the shared response/event stream continues to advance;
2. the Windows desktop main process intermittently fails to process or render those events.

The active long-running thread has a local rollout of approximately 31.2 MB and 10,267 JSONL records. This may amplify event/rendering cost, but I cannot claim it is the root cause because earlier hangs also occurred on the empty project overview.

Current confidence:

• high: Windows desktop process/UI lifecycle bug;
• high: separate Windows Git child-process cleanup bug;
• moderate: long-thread/status-event processing amplifies the desktop hang;
• low: GPU acceleration is the primary cause.

Additional isolation results from the same Windows reproduction. No private workspace names, paths, repository contents, screenshots, or configuration values are included.

Clean renderer profile does not resolve the hang

The entire per-user Codex renderer profile was moved to a timestamped recovery location and Codex regenerated a fresh profile. The app still became visibly Not Responding approximately 3–4 seconds after launch, including on the project overview.

This makes corrupted Chromium cache/storage and the old renderer profile unlikely to be the primary cause.

Fresh central Codex configuration does not resolve the hang

The existing ~/.codex/config.toml was reversibly isolated and Codex generated a new default configuration.

• old configuration size: 14,379 bytes;
• fresh generated configuration size: 2,350 bytes;
• the old configuration inventory included 75 project sections, 9 plugin sections, 4 MCP roots, hooks, and custom UI configuration;
• the visible desktop hang still occurred immediately with the fresh configuration.

Sessions, authentication, repositories, and project files were not deleted for this test.

This makes the project registry, plugin/MCP startup configuration, hooks, and the prior custom configuration unlikely to be the root cause.

Additional negative differentials

• WinINET user proxy: disabled;
• PAC URL: absent;
• HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY: absent;
• WinHTTP proxy: direct access;
• no common VPN/proxy process was present;
• Windows was fully updated and rebooted before retesting;
• app repair and two uninstall/reinstall cycles did not resolve it.

Main-thread and Git cleanup result

Windows Wait Chain Traversal identified the visible desktop process's UI thread as blocked, but returned a one-node chain with no supported multi-node wait dependency or deadlock cycle.

In a clean-profile run, 20 conservatively identified orphaned, inactive, read-only Git metadata probes were terminated. The WCT result remained identical immediately afterward: the same UI thread stayed blocked and the visible app remained frozen.

Together with the earlier 45-second sample in which the UI transitioned to non-responsive while the orphan count stayed zero, this confirms:

1. the Windows Git child-process cleanup bug is real;
2. it is not sufficient to explain this desktop UI hang.

Remote/client differential

The mobile Remote client continues to receive generated output promptly while the Windows desktop remains frozen. The Windows client later renders accumulated text in a batch, is briefly usable, and freezes again. The agent/backend therefore continues progressing while the Windows desktop main/render path stalls.

Current interpretation

• High confidence: app-side Windows desktop main-thread, renderer IPC, or event-delivery/processing regression in desktop package 26.715.4045.0 / executable 150.0.7871.124.
• High confidence: a separate orphaned Git subprocess lifecycle bug is also present.
• Low confidence: GPU, proxy/VPN, repository latency, renderer cache/profile corruption, or the old config.toml is the primary cause.
• Not yet proven: the exact native wait inside the closed-source desktop process.

I am attempting a local non-invasive WinDbg stack capture. Any dump or potentially sensitive diagnostics will remain local unless maintainers/support provide a private upload route and confirm exactly what is needed.

Could maintainers provide one of the following?

1. a private diagnostic upload route;
2. the preferred hang-dump/WPR capture procedure for this packaged desktop build;
3. confirmation whether a newer internal desktop build contains Windows main-thread/event-delivery fixes beyond the Git child-process work;
4. a supported way to disable workspace restoration/background project scanning as a temporary diagnostic workaround.

Case-specific resolution and corrected root-cause evidence from the same Windows reproduction. This contains no private workspace names, paths, repository contents, screenshots, or configuration values.

Correction to my previous isolation result

Resetting ~/.codex/config.toml did not reset the separate .codex-global-state.json workspace/UI state. Therefore my earlier statement that the fresh configuration made workspace restoration unlikely was too broad. It ruled out config.toml, plugins/MCP configuration, hooks, and related settings, but not the persisted desktop workspace registry.

Strong differential: global workspace state

Reversibly isolating .codex-global-state.json had two simultaneous effects:

1. all locally restored projects disappeared from the Windows sidebar;
2. the recurring Not Responding hang stopped.

The same projects/chats remained visible through the Remote client, confirming that this was local Windows desktop state rather than account/project deletion.

A historical automatic state snapshot contained 20 saved workspace roots. Because this machine had previously been migrated from another Windows user/profile and between drives:

• 14 saved roots used logical paths below the old Windows profile;
• those 14 paths resolved through directory junctions from the system drive to a second drive;
• all 20 directories existed;
• all final targets were unique;
• direct one-shot filesystem/Git probes were fast.

So this was not a missing-directory or intrinsically slow-repository problem. The risky condition was restoring logical workspace identities that traversed an old-profile, cross-volume junction topology.

Recovery performed

I built a selective replacement state from the current clean/stable state and the historical project registry:

• imported all 20 project roots and necessary project/sidebar/thread mappings;
• replaced the 14 old-profile aliases with their direct canonical target paths;
• retained 6 projects that genuinely live on the system drive;
• excluded bulky historical persisted UI atoms, prompt history, heartbeat/permission cache, drafts, output-directory state, and queued follow-up state;
• did not change config.toml;
• did not move, copy, edit, or delete any repository/project files;
• created a rollback copy before applying it.

Post-application validation:

• 20 registered roots, 20 existing, 20 unique;
• 0 registered old-profile aliases;
• direct root distribution: 6 on the system drive, 14 on the second drive;
• all projects and this long-running thread became visible again in the Windows sidebar;
• no recurring Not Responding state observed afterward.

A 30-second health sample showed stable aggregate working set around 1.07–1.11 GB, near-zero CPU while idle, no growing handle/process trend, and zero new WER event-ID-1002 hangs. A later check showed zero git.exe processes and zero WER hangs in the preceding 15 minutes.

As a heavier validation, a bounded local audit scanned 23,067 text/configuration files across all 20 registered roots over several minutes while the desktop app remained usable. The user continued typing and receiving streamed responses in the Windows app without another Not Responding transition.

For this machine, canonicalizing the persisted workspace roots and rebuilding only the minimal workspace/sidebar state appears to have resolved the desktop hang. I am not claiming this is the universal cause of every hang reported in this issue.

Likely mechanism (inference, not proven native stack evidence)

The strongest current hypothesis is that desktop startup/restoration treated logical junction paths and canonical target paths as distinct or repeatedly reinitialized identities. That may multiply or invalidate filesystem watchers, Git metadata refreshes, workspace/thread subscriptions, or renderer events. Once persisted state crossed a threshold, replaying it on each launch caused the Windows main/render path to stall approximately 3–4 seconds after startup.

This is consistent with another report here correlating focus/thread switching with background workspace/runtime restoration bursts. It also explains why reinstalling the app did not help: the per-user global state survived. However, the exact closed-source Electron/Chromium wait path remains unproven.

Separate Git lifecycle issue remains real

The earlier orphaned git.exe metadata probes remain independently reproduced. Canonical state recovery stopped the observed UI hang even though earlier samples proved the UI could hang with zero Git orphans. Therefore:

• canonical workspace restoration fixed this user's recurring UI hang;
• Git child-process cancellation/reaping and metadata throttling still need product fixes;
• a short timeout for git status --porcelain is useful, but is unlikely to cover the full UI failure mode by itself.

Product feedback / suggested safeguards

1. Canonicalize and deduplicate Windows workspace roots by final path/volume identity before registering watchers or Git metadata work.
2. Detect roots that traverse an old user-profile junction or cross-volume reparse point and show a migration/review prompt instead of silently restoring them.
3. Restore workspaces progressively and keep one problematic root from blocking the desktop UI thread.
4. Add a supported “start without workspace restoration” safe mode and a “reset only workspace/sidebar state” action that preserves authentication, sessions, config.toml, and project files.
5. Bound, deduplicate, cancel, and back off Git metadata probes; on timeout/cancellation, reap the full Windows child process tree.
6. Expose a privacy-safe diagnostic summary: logical root count, canonical unique root count, reparse/cross-volume root count, watcher/subscription count, and active metadata probes.
7. Apply size/count limits and compaction to persisted UI atoms so a large historical desktop state cannot indefinitely replay into the renderer.
8. During uninstall/reinstall or repair, explain that per-user workspace state is retained and offer an explicit, reversible reset option.

I am leaving the issue open because the local recovery is a workaround for a desktop state-restoration failure that the app should detect and handle safely.