Codex-created Windows worktree leaves Git LFS files falsely modified after materialization

Codex-created Windows worktree leaves Git LFS files falsely modified after materialization

Summary

Codex-created Windows linked worktree e5ce contains the correct Git LFS
working-tree content, but Git reports all 154 LFS files as modified.

All 154 working-tree files match their HEAD LFS object IDs exactly. The
affected worktree index retains the cached stat size of the 131-byte LFS
pointer instead of the materialized file size. A control worktree with the
same materialized file has a matching cached stat size and is clean.

This report does not claim that Git LFS alone is the root cause. The exact
Codex process that materialized the files is not known.

Environment

• Host: Windows 11 Pro 10.0.26200, x86_64
• Codex surface: Codex Desktop worktree
• Codex Desktop version: not available from the shell
• Git: 2.55.0.windows.3
• Git LFS: 3.7.1
• PowerShell: 7.6.4
• User: redacted
• Repository: redacted
• Affected worktree: e5ce

Expected behavior

After Codex creates a linked worktree and LFS content is available, the
worktree should report clean when no user file changes exist.

git lfs pull should either leave the worktree clean or return a failure that
explains why the worktree cannot be normalized.

Actual behavior

The affected worktree reports:

• 154 LFS-managed binary files as M.
• 3 unrelated non-LFS Unity .meta files as M.
• git lfs pull exits without an error and does not remove the LFS M entries.
• git lfs status lists the LFS files as LFS: -> File: .
• git lfs fsck --objects reports Git LFS fsck OK.
• git update-index --refresh reports every LFS file as needs update.

The 3 .meta files are separate Unity/UPM changes and are not part of this
LFS report.

Reproduction evidence

Representative tracked LFS asset (path redacted):

Check	Affected e5ce	Clean control f65f
Working-tree bytes	184044	184044
SHA-256	ff8eb1b8ecc48379fb1a7999fcf22c3129abbabeb5bbcaf7e984d12df08b1fd0	same
Index cached size	131	184044
git status	modified	clean
git lfs status	LFS files not staged	clean

The affected index cached size matches the pointer file size. The working
tree contains the full LFS object.

Full working-tree verification:

• LFS files enumerated: 154
• Exact SHA-256 matches against git lfs ls-files -l: 154
• Mismatches: 0
• Missing files: 0
• git lfs fsck --objects: passed

The affected worktree index stat was created at worktree creation time. The
LFS files received a later bulk write timestamp. The index did not receive a
matching materialized-file stat update.

Control comparison

Other Codex worktrees on the same repository and machine do not show the same
condition:

• f65f: materialized LFS files and clean index stats; status is clean.
• 06da: pointer files and pointer-sized index stats; status is clean.
• d300: pointer files and pointer-sized index stats; status is clean.

This narrows the issue to the affected worktree materialization sequence,
not to all Git LFS objects or all worktrees on the host.

Verified / Inferred / Uncertain

Verified

• All 154 affected LFS working files match their recorded SHA-256 OIDs.
• The affected worktree index caches the pointer size for materialized files.
• A control worktree with materialized files has clean status and matching
  cached stat sizes.
• git lfs pull did not report an error.
• git lfs fsck --objects passes.
• No application source change or staged change is involved in this report.

Inferred

• LFS content was materialized after the affected worktree index was created.
• The materialization path did not refresh the Git index stat information.
• The false M state is caused by the index/worktree stat mismatch.

Uncertain

• The exact Codex component or command that performed the bulk materialization.
• Whether git lfs pull caused the materialization or only observed an earlier
  materialization.
• Whether the same sequence reproduces in a repository-independent fixture.
• Whether Git LFS alone reproduces the condition without Codex worktree
  management.
• The Codex Desktop application version.

Related issue / duplicate assessment

This report is related to #34953, but it describes a distinct failure mode.

• #34953 reports repeated Git LFS filter-process activity and full-size temporary-file growth under .git/lfs/tmp.
• This report shows correct materialized LFS contents with stale index cached stat data, which causes false M entries.
• No .git/lfs/tmp growth or LFS object corruption was observed here.
• #34005 and #34854 concern broader Git process churn and performance issues. They are not exact duplicates of this report.

The same Codex root cause is not confirmed.

Impact

• Clean-worktree checks become unreliable.
• PR review and scoped staging become harder because binary assets appear dirty.
• Users may attempt destructive recovery commands such as git reset --hard.
• No LFS content corruption was observed.

Suggested impact: medium priority. The state is operationally disruptive and
creates a data-loss risk through likely user workarounds, but a separate clean
worktree remains available as an operational workaround.

Requested fix

When Codex creates or prepares a linked worktree containing Git LFS files:

1. Materialize LFS files through the normal Git checkout/filter path, or
2. If Codex must materialize files externally, refresh the affected index stat
   information after successful materialization.
3. Verify git status --short and the LFS filter result before reporting
   worktree setup success.
4. Return a non-zero setup result when LFS materialization or index
   normalization fails.

The fix should preserve user edits and must not silently run destructive reset
or checkout operations.

Safe diagnostic commands

These commands were used without resetting, checking out, staging, or deleting
the affected files:

whoami
git --version
git lfs version
git lfs env
git lfs status
git lfs fsck --objects
git lfs ls-files -l
git update-index --refresh
git status --short --branch

Notes for triage

Git documents git update-index --refresh as a stat re-match operation. It does
not recalculate content hashes or repair content changes:
https://git-scm.com/docs/git-update-index

Git LFS checkout documents that existing non-placeholder working-tree files
are not overwritten by a normal checkout. This may explain why a later
git lfs pull did not repair the stale index stat:
https://github.com/git-lfs/git-lfs/blob/main/docs/man/git-lfs-checkout.adoc

The current worktree's 157 dirty paths must be preserved. Do not use
git reset --hard, git checkout --, git lfs uninstall, or broad staging as part
of triage.

Start by reproducing the linked-worktree materialization sequence and checking the listed Git and Git LFS commands, especially git update-index --refresh and git status --short --branch. Trace the Codex worktree setup and materialization entry points to determine which component leaves stale index statistics. Done means preserving user edits while producing a clean status after successful materialization, or returning a non-zero setup result when normalization fails.