Windows desktop: deleted worktree causes an unbounded one-second Git live-query retry and sustained high CPU
What version of the Codex App are you using (From “About Codex” dialog)?
26.803.10989.0
What subscription do you have?
Not specified in this draft — please confirm before submission
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
The Codex Windows desktop app continued running git status against Codex-managed worktree paths after those directories no longer existed and were no longer registered by Git. Each failed live query was retried approximately once per second without stopping or backing off.
With three orphaned paths, the Codex main process continuously consumed about 12.36% of a 16-logical-processor machine, equivalent to roughly two logical CPU cores. This caused sustained fan noise while the app was otherwise idle.
Affected request sources:
review_modellocal_conversation_thread
Sanitized log signature:
[git] git.command.complete command="git ... status ..." cwd=C:/Users/<user>/.codex/worktrees/<worktree-id>/<repo> failureReason=wait_failed requestKind=subscribe-live-query source=review_model success=false
The same signature occurred with source=local_conversation_thread. No real username, repository name, worktree ID, thread ID, branch, commit, prompt, or filesystem path is included.
What steps can reproduce the bug?
This is the observed sequence and should be treated as a probable reproduction until independently confirmed:
- Open conversations backed by Codex-managed Git worktrees.
- Allow Git Review or local-conversation live queries to subscribe to those worktrees.
- Archive/clean up the conversations and remove their managed worktree directories.
- Leave the desktop app running.
- Observe that existing subscriptions continue invoking
git statusagainst the deleted directories approximately once per second.
Verification from the affected system:
- All affected directories returned
exists=false. git worktree list --porcelaincontained no entry for the affected paths.- The failing commands reported
failureReason=wait_failedandrequestKind=subscribe-live-query.
What is the expected behavior?
When a subscribed worktree directory no longer exists, Codex should terminate or invalidate that live query. Archiving or deleting a managed worktree should unsubscribe the review and conversation queries that own the path. If a retry is appropriate for a transient error, it should use bounded exponential backoff rather than retrying forever once per second.
Additional information
Recovery verification
After the orphaned subscriptions were cleared and the app reloaded:
- The new session contained zero references to the deleted paths.
- It contained zero
failureReason=wait_failedevents. - All app processes together measured about 1.66% total machine CPU during active use; the main process measured 0.09%.
Suggested fix
- Validate the worktree
cwdbefore starting or retrying a Git live query. - Treat a permanently missing worktree path as a terminal subscription state.
- Unsubscribe
review_modelandlocal_conversation_threadqueries when the worktree/conversation is archived or removed. - Use bounded exponential backoff for genuinely transient Git process-start failures.
- Add a regression test that removes a subscribed managed worktree and asserts no further
git statusprocesses are spawned.
Secondary UI observation
Settings search exposes a Disable Git-Based Review result in this build, but the Git settings page does not display the corresponding control, so that mitigation is unavailable through the visible UI. This may be a separate feature-gating or settings-search indexing issue.
Privacy
This report is intentionally sanitized. It contains no raw logs, session transcripts, prompts, repository/company names, usernames, real paths, thread/worktree IDs, branches, commits, account information, credentials, or tokens. No session or screenshot is attached.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
yes duplicate of #38109