Codex Git LFS Files Look Modified? Verify Before Reset

If a new Codex worktree on Windows suddenly shows dozens or hundreds of Git LFS files as modified, do not reset, check out, stage, or delete them. First preserve the worktree, separate LFS-managed paths from real source edits, and compare one reported file's current bytes with the LFS pointer stored in HEAD.

An open Codex issue reports a worktree where 154 materialized LFS files matched their recorded object IDs exactly, yet Git marked every one as modified. The affected index still cached the 131-byte pointer size while the working tree contained each full asset. That is a specific reported failure, not proof that every dirty LFS worktree is harmless.

Freeze the Worktree Before Diagnosing It

Stop agents, editors, asset importers, and build tools that could keep writing into the affected worktree. Do not ask Codex to "clean everything" or "make Git status empty." Those goals can turn an index problem into data loss when unrelated edits are mixed into the same status output.

Capture the basic state in PowerShell:

git status --short --branch
git diff --name-only
git lfs version
git lfs env
git lfs status
git lfs ls-files -l
git lfs fsck --dry-run --objects

Save the output outside the repository if you need it for a bug report. The --dry-run option matters: the Git LFS manual says a normal fsck may move corrupt objects into .git/lfs/bad, while dry-run performs the checks without moving them.

Do not collapse all modified paths into one bucket. In issue 37877, 154 LFS-managed binary files had the false modified state while three non-LFS Unity metadata files were separate changes that still needed preservation.

Verify One Representative LFS File

Choose one reported LFS path that you know was not intentionally edited. Use forward slashes in the Git object path:

$File = 'Assets/path/to/example.psd'

git show "HEAD:$File"
git lfs pointer --file="$File"
git ls-files --debug -- "$File"
(Get-Item -LiteralPath $File).Length

The first command shows the pointer recorded in HEAD. The second asks Git LFS to build a pointer from the current file. Compare the oid sha256: and size lines.

• If the OIDs and sizes match, the working file contains the bytes expected by HEAD even though Git reports it as modified.

• If the OIDs differ, treat the file as a real change until you prove otherwise.

• If either command fails, stop. Do not infer that the asset is safe to overwrite.

Then compare the cached index size from git ls-files --debug with the filesystem length. A pointer-sized index entry paired with a much larger, OID-matching working file is consistent with the August 10 report. It is still only diagnostic evidence.

Understand the Three States

Git LFS makes this symptom confusing because one logical asset appears in three forms:

Git documents git update-index --refresh as a stat-information refresh. It does not stage new content or recalculate the object stored in the index. In the reported Codex worktree, it printed needs update for every affected LFS file and did not clear the false modified state.

If you run it, do so only after preserving the first status output:

git update-index --refresh
git status --short --branch

A remaining M does not prove corruption. A disappearing M also does not prove that every other path was safe. Continue to protect unrelated edits.

Why git lfs pull May Not Repair It

The issue reporter ran git lfs pull successfully, but the modified entries remained. Git LFS documents that checkout does not overwrite a working file that is already a non-placeholder, modified file. If the working bytes are already the correct full object and the mismatch is cached index metadata, another pull may have nothing useful to replace.

That is why repeated pulls, broad checkouts, and resets are poor first responses. They change more state without first answering whether the bytes differ.

Use a Separate Clean Worktree as the Workaround

If the affected worktree remains dirty after the evidence is captured, leave it intact and continue in another worktree created from the same commit. Verify the control worktree before moving any work:

git rev-parse HEAD
git status --short --branch
git lfs status
git lfs fsck --dry-run --objects

The control should use the intended commit, show no unexpected edits, and pass the LFS consistency check. Copy only reviewed source changes from the affected worktree. Do not delete the affected worktree until every non-LFS edit and every OID mismatch has been accounted for.

For more worktree safety context, see how to isolate a Windows Codex Git crash, how parallel agent worktrees should be separated, and how to prevent a coding agent from deleting files.

What Not to Do

Avoid these commands until the evidence proves exactly what they would discard:

• git reset --hard

• git checkout -- .

• git restore .

• git add . or another broad stage

• git lfs uninstall

• deleting or pruning the affected worktree

• setting assume-unchanged or skip-worktree to hide the status

The Git LFS FAQ describes other reasons LFS files can remain modified, including attributes that were added without renormalizing existing files. Do not apply that repository-wide repair merely because the symptom looks similar. It authors a real commit and is appropriate only when the repository's LFS tracking is actually wrong.

Check the Current Codex Issue With Aident Loadout

Before relying on this workaround, have your agent read the current upstream issue through a connected, read-only GitHub Action.

Start with:

Follow https://aident.ai/SETUP.md

Then ask:

Check Aident Loadout authentication and Vault status. Discover the current GitHub Action that reads one issue, inspect its schema, and preflight a request for openai/codex issue 37877. Execute only the read Action. Return the issue title, state, labels, updated timestamp, and URL. Do not comment, edit, close, or react to the issue, and do not run any Git command.

This gives you one measurable check against the live issue state without granting the recovery step permission to mutate either GitHub or the local worktree.

Set up Aident Loadout for the read-only issue check.

Report the Failure Without Leaking the Repository

After your files are safe, report:

• Codex app version and Windows version;

• git --version and git lfs version;

• whether Codex created the worktree;

• count of LFS and non-LFS modified paths;

• one redacted example with HEAD OID, generated OID, expected size, working size, and cached index size;

• whether a clean control worktree at the same commit reproduces the state;

• whether git lfs fsck --dry-run --objects passed;

• whether git update-index --refresh changed the result.

Do not attach proprietary assets, absolute user paths, repository URLs, or full environment output without reviewing them. Link the existing issue when the symptom matches instead of opening a duplicate.

Sources

• Codex issue 37877: Windows worktree leaves Git LFS files falsely modified

• OpenAI: Git worktrees

• Git status documentation

• Git update-index documentation

• Git LFS status documentation

• Git LFS pointer documentation

• Git LFS fsck documentation

• Git LFS checkout documentation

• Git LFS FAQ

Refresh this guide when issue 37877 changes state, OpenAI documents Codex worktree LFS behavior, or Git LFS changes the pointer, checkout, or fsck contracts used here.