[Windows][Desktop 26.818.8289.0] canceled review-summary git diff leaves stale .git/index.lock

Summary

Codex Desktop on Windows repeatedly leaves a zero-byte .git/index.lock after its background Git review worker cancels a long-running git diff.

The correlated commands are emitted with:

requestKind=review-summary
source=review_model
aborted=true
failureReason=canceled
subcommand=diff

After the cancellation, no git.exe or git-lfs.exe process remains, the zero-byte lock can be opened exclusively, and subsequent user Git operations fail because .git/index.lock already exists. The user has had to remove the stale lock repeatedly.

This reproduced on two consecutive days, including once while collecting evidence for this report.

Environment

• Codex Desktop MSIX: OpenAI.Codex_26.818.8289.0_x64__2p2nqsd0c76g0
• Windows 11 Enterprise, version 10.0.26200, build 26200, x64
• Git for Windows: 2.55.0.windows.1
• Repository: large native-Windows source repository with a large local diff
• GIT_OPTIONAL_LOCKS: unset (Git default behavior)

Correlated evidence

All local times below are UTC+08:00.

Normalized log record from the second reproduction:

warning [git] git.command.complete
aborted=true
command="git ... diff ... <base> --find-renames --raw --no-abbrev --numstat -z"
durationMs=30555
exitCode=null
failureReason=canceled
requestKind=review-summary
source=review_model
stderrBytes=173
stdoutBytes=29664961
subcommand=diff
success=false

Within the inspected 8-second window around the second lock creation, this was the only logged git.command.complete event.

The cancellation rate is also unusually high:

• 2026-08-27 log: 1,658 review-summary Git completions; 1,655 canceled
• 2026-08-28 log at capture time: 1,066 completions; 1,065 canceled (99.91%)

For both stale locks:

• file size was 0 bytes
• no active git.exe or git-lfs.exe process existed when inspected
• exclusive read/write open with no sharing succeeded
• moving the lock aside immediately restored the repository for normal Git use

Steps to reproduce

1. Open a large native-Windows Git repository in Codex Desktop, with a sufficiently large working-tree or branch diff.
2. Let the Desktop review pane/background review-summary path refresh repository state.
3. Continue interacting with tasks so review-summary requests are replaced or canceled while a large git diff is running.
4. Wait for a canceled requestKind=review-summary, source=review_model Git operation.
5. Inspect <repo>/.git/index.lock.
6. Observe a zero-byte stale lock with no live Git writer; a later Git write fails with Unable to create .../.git/index.lock: File exists.

Expected behavior

Background read-only review queries must not leave repository locks or interfere with user Git operations, including when requests are canceled.

Potential mitigations:

• run background read-only Git queries with git --no-optional-locks or GIT_OPTIONAL_LOCKS=0
• make cancellation wait for the owned Git process tree to exit cleanly
• use single-flight/debounce/backoff for repeatedly invalidated review-summary work
• if cleanup is needed, make it ownership-aware; do not unconditionally delete .git/index.lock, because it may belong to a legitimate user Git writer

Related issues

I did not find an exact existing report that correlates canceled review-summary diffs with a reproducible stale .git/index.lock.

• #30820 — eager review-summary snapshots / CPU and I/O spikes
• #38062 — Git review cancellation and hidden disable toggle
• #29408 — repeated/stuck Windows Git polling; stale index.lock noted on one machine
• #35776 — runaway background Git cancellation loop

Privacy

The log evidence above is normalized. No source paths, filenames, remotes, commit identifiers, diff contents, account identifiers, or full logs are included. Additional sanitized diagnostics can be provided through an official private feedback channel if needed.

Trace the Codex Desktop review-summary background Git path, focusing on canceled git diff operations and the requestKind=review-summary completion records described in the issue. Reproduce with the listed large-repository steps and verify that cancellation leaves no repository lock and does not interfere with later user Git operations.