Codex generates 214-character loose checkpoint refs that exceed Windows path limits
What version of the Codex App are you using (From “About Codex” dialog)?
26.721.4979.0
What subscription do you have?
ChatGPT Plus
What platform is your computer?
- Windows 10 Pro 22H2
- OS build: 19045.6466
- x64 - SourceTree: 3.4.31
- Git configuration:
core.longpaths=true
What issue are you seeing?
Codex creates deeply nested loose Git references under:
.git/refs/codex/turn-diffs/checkpoints/
The fixed refs/codex/turn-diffs/checkpoints prefix is not the main problem. Each checkpoint adds two full 64-character hashes, a timestamp, and a UUID:
refs/codex/turn-diffs/checkpoints/
<64-character hash>/
<64-character hash>/
<timestamp>/
<UUID>
In an affected repository:
- The generated ref name was 214 characters long.
- The complete filesystem path was 266 characters long.
- The repository was stored in a normal Windows development directory.
- Git already had
core.longpaths=true.
SourceTree fails when LibGit2Sharp enumerates these loose refs:
ERROR [SourceTree.Repo.RepoHandlerGit] - Failed to get commit labels, falling back to git.exe
LibGit2Sharp.LibGit2SharpException: path too long:
F:/workspace/<group>/<repository>/.git/refs/codex/turn-diffs/checkpoints/<64-character-hash>/<64-character-hash>/<timestamp>/<UUID>
After this error, SourceTree may display incomplete branch or commit-label information.
Running the following command fixes SourceTree immediately:
git pack-refs --all --prune
This command does not delete the Codex refs or change their target object types. It only moves the loose refs into .git/packed-refs.
The fact that packing the refs fixes the problem demonstrates that the failure is caused by the generated loose-ref filesystem path length.
What steps can reproduce the bug?
- On Windows, open a Git repository located under a normal development path.
- Use the Codex desktop app for several tasks so that checkpoint refs are created.
- Inspect the generated refs:
git for-each-ref --format="%(refname)" refs/codex/turn-diffs/checkpoints
- Observe refs with a structure containing two 64-character hashes, a timestamp, and a UUID.
- Open or refresh the repository in SourceTree 3.4.31.
- SourceTree logs
LibGit2SharpException: path too long. - Branch or commit-label information may be incomplete.
- Close SourceTree.
- Run:
git pack-refs --all --prune
- Reopen SourceTree.
- SourceTree works normally again.
What is the expected behavior?
Codex-generated internal checkpoint paths should remain within Windows-safe path lengths and should not break Git clients that enumerate loose refs.
Possible mitigations include:
- using shorter checkpoint identifiers;
- avoiding multiple nested full-length hashes;
- automatically packing internal refs;
- storing checkpoint metadata outside loose Git refs;
- cleaning up obsolete checkpoint refs.
Additional information
This is related to #28241, but it is a separate failure mode.
Issue #28241 primarily discusses Git clients failing because Codex refs point directly to tree objects. This report concerns the filesystem path length of the generated loose refs.
Packing the refs fixes this issue without deleting them or changing whether they point to tree or commit objects. Therefore, the path-length failure is independent of the tree-object compatibility issue.
Also related: #30214 mentions deeply nested Codex checkpoint paths approaching Windows MAX_PATH, although that issue reports a different data-loss scenario.