index emptied between staging and commit resulting in `git commit` recording an empty tree

[markmont]

What happened?

Staging and then commiting files can sometimes result in a commit deleting the entire repository.

Example (commands run by a person in a terminal window in a dev container):

$ # make a change to the file hello-express/server.js
$ git status  # tree is normal
On branch main
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   hello-express/server.js

no changes added to commit (use "git add" and/or "git commit -a")

$ git status ; git add hello-express/server.js ; sleep 1 ; git status  # index is deleted while entire does its work
On branch main
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	deleted:    .claude/rules/behavior.md
	deleted:    .claude/rules/knowledge-graph.md
	deleted:    .claude/rules/memory.md
	deleted:    .claude/settings.json
	deleted:    .claude/skills/graphify/.graphify_version
	deleted:    .claude/skills/graphify/SKILL.md
	deleted:    .claude/skills/graphify/references/add-watch.md
	deleted:    .claude/skills/graphify/references/exports.md
	deleted:    .claude/skills/graphify/references/extraction-spec.md
	deleted:    .claude/skills/graphify/references/github-and-merge.md
	deleted:    .claude/skills/graphify/references/hooks.md
	deleted:    .claude/skills/graphify/references/query.md
	deleted:    .claude/skills/graphify/references/transcribe.md
	deleted:    .claude/skills/graphify/references/update.md
	deleted:    .devcontainer/DISABLED_init-firewall.sh
	deleted:    .devcontainer/Dockerfile
	deleted:    .devcontainer/container-post-start-root.sh
	deleted:    .devcontainer/container-post-start-user.sh
	deleted:    .devcontainer/devcontainer.json
	deleted:    .entire/.gitignore
	deleted:    .entire/settings.json
	deleted:    .gitattributes
	deleted:    .githooks/commit-msg
	deleted:    .githooks/post-commit
	deleted:    .githooks/post-merge
	deleted:    .githooks/post-rewrite
	deleted:    .githooks/pre-push
	deleted:    .githooks/prepare-commit-msg
	deleted:    .gitignore
	deleted:    .mcp.json
	deleted:    CLAUDE.md
	deleted:    README.md
	deleted:    docs/agents/domain.md
	deleted:    docs/agents/issue-tracker.md
	deleted:    docs/agents/triage-labels.md
	deleted:    graphify-out/graph.json
	deleted:    hello-express/.gitignore
	deleted:    hello-express/package-lock.json
	deleted:    hello-express/package.json
	deleted:    hello-express/server.js
	deleted:    scripts/bootstrap-git-hooks.sh

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.claude/
	.devcontainer/
	.entire/
	.gitattributes
	.githooks/
	.gitignore
	.mcp.json
	CLAUDE.md
	README.md
	docs/
	graphify-out/
	hello-express/
	scripts/

On branch main
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   hello-express/server.js


$ sleep 10 ; git status  # entire completes its work, tree goes back to normal
On branch main
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   hello-express/server.js


$ 

To work around this problem, both people and agents need to insert a long enough delay between the git add and git commit, or check the status and only proceed to the commit if/when the number of files to be committed matches what we expect to be committed.

If the empty tree accidentally gets committed, git reset --mixed HEAD~1 can be used to revert back to the last good commit.

Steps to reproduce

This does not happen every time, but can be reproduced in a small number of attempts (under 5). Note I'm running in a container with limited CPU and RAM, which may trigger the problem more than a less resource-constrained environment.

1. Modify a file in the repo
2. git status shows everything is as expected
3. git add NAME_OF_FILE ; sleep 1 ; git status shows the problem (does not happen every time)
4. git status after a few more seconds shows the problem has resolved itself. But if either a person or an agent runs git commit while the problem still exists (between steps 3 and 4), then all files are deleted from the git tree.

Entire CLI version

Entire CLI 0.10.2 Go version: go1.26.6 OS/Arch: linux/arm64

OS and architecture

Linux 6.12.76-linuxkit aarch64 GNU/Linux

Agent

Claude Code

Terminal

Zed

Logs / debug output

{"time":"2026-08-22T11:37:36.121720177-04:00","level":"INFO","msg":"turn-start","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"lifecycle","agent":"claude-code","event":"TurnStart","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","session_ref":"/home/node/.claude/projects/-workspace/cf0a7299-d289-44c6-a782-37d5e5419e19.jsonl","model":""}
{"time":"2026-08-22T11:37:36.158698511-04:00","level":"INFO","msg":"phase transition","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"session","agent":"claude-code","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","event":"TurnStart","from":"idle","to":"active"}
{"time":"2026-08-22T11:40:02.648421467-04:00","level":"INFO","msg":"prepare-commit-msg: agent commit trailer added","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"checkpoint","strategy":"manual-commit","source":"message","checkpoint_id":"01M0N221PRZM8XPS7ZGCZWWFJW","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19"}
{"time":"2026-08-22T11:40:04.690928177-04:00","level":"INFO","msg":"session condensed","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"checkpoint","strategy":"manual-commit","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","checkpoint_id":"01M0N221PRZM8XPS7ZGCZWWFJW","checkpoints_condensed":2,"transcript_lines":392}
{"time":"2026-08-22T11:40:04.70602176-04:00","level":"INFO","msg":"post-commit: carried forward remaining files","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"checkpoint","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","remaining_files":1}
{"time":"2026-08-22T11:40:04.710591718-04:00","level":"INFO","msg":"shadow branch deleted","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"checkpoint","strategy":"manual-commit","shadow_branch":"entire/7d296d6-e3b0c4"}
{"time":"2026-08-22T11:40:04.71061976-04:00","level":"WARN","msg":"perf","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"perf","op":"post-commit","duration_ms":2009,"slow":true,"steps.open_repository_and_head_ms":2,"steps.find_sessions_for_worktree_ms":2,"steps.resolve_commit_trees_ms":6,"steps.process_sessions_ms":1991,"steps.process_sessions.0_ms":1991,"steps.process_sessions.0.resolve_shadow_branch_ms":0,"steps.process_sessions.0.check_session_content_ms":535,"steps.process_sessions.0.transition_and_condense_ms":1437,"steps.process_sessions.0.extract_session_data_ms":1089,"steps.process_sessions.0.redact_transcript_ms":252,"steps.process_sessions.0.calculate_session_attribution_ms":0,"steps.process_sessions.0.write_committed_v1_ms":84,"steps.process_sessions.0.write_committed_v1.chunk_transcript_ms":0,"steps.process_sessions.0.write_committed_v1.chunk_transcript.write_transcript_blobs_ms":33,"steps.process_sessions.0.write_committed_v1.chunk_transcript.write_transcript_blobs.write_transcript_content_hash_ms":2,"steps.process_sessions.0.write_committed_v1.write_compact_transcript_ms":35,"steps.process_sessions.0.carry_forward_files_ms":15,"steps.process_sessions.0.write_carry_forward_shadow_ms":13,"steps.cleanup_shadow_branches_ms":1,"hook_type":"git"}
{"time":"2026-08-22T11:41:33.629912343-04:00","level":"INFO","msg":"prepare-commit-msg: agent commit trailer added","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"checkpoint","strategy":"manual-commit","source":"message","checkpoint_id":"01M0N24THXB9W0FZFZ23YZWDK0","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19"}
{"time":"2026-08-22T11:41:34.577849885-04:00","level":"INFO","msg":"attribution calculated","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"attribution","agent_lines":70,"human_added":270,"human_modified":0,"human_removed":0,"total_committed":340,"agent_percentage":8.31353919239905,"accumulated_user_added":0,"accumulated_user_removed":0,"files_touched":1}
{"time":"2026-08-22T11:41:34.688973802-04:00","level":"INFO","msg":"session condensed","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"checkpoint","strategy":"manual-commit","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","checkpoint_id":"01M0N24THXB9W0FZFZ23YZWDK0","checkpoints_condensed":2,"transcript_lines":436}
{"time":"2026-08-22T11:41:34.70366226-04:00","level":"INFO","msg":"shadow branch deleted","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"checkpoint","strategy":"manual-commit","shadow_branch":"entire/82083e2-e3b0c4"}
{"time":"2026-08-22T11:42:03.310612218-04:00","level":"INFO","msg":"turn-end","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"lifecycle","agent":"claude-code","event":"TurnEnd","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","session_ref":"/home/node/.claude/projects/-workspace/cf0a7299-d289-44c6-a782-37d5e5419e19.jsonl","model":""}
{"time":"2026-08-22T11:42:03.964946551-04:00","level":"INFO","msg":"no files modified during session, skipping checkpoint","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"lifecycle","agent":"claude-code"}
{"time":"2026-08-22T11:42:03.966716968-04:00","level":"INFO","msg":"phase transition","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"session","agent":"claude-code","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","event":"TurnEnd","from":"active","to":"idle"}
{"time":"2026-08-22T11:42:03.966726426-04:00","level":"INFO","msg":"finalizing turn checkpoints with full transcript","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"checkpoint","agent":"claude-code","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","checkpoint_count":2}
{"time":"2026-08-22T11:42:04.351615927-04:00","level":"INFO","msg":"finalize: checkpoint updated with full transcript","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"checkpoint","agent":"claude-code","checkpoint_id":"01M0N221PRZM8XPS7ZGCZWWFJW","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19"}
{"time":"2026-08-22T11:42:04.414681427-04:00","level":"INFO","msg":"finalize: checkpoint updated with full transcript","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"checkpoint","agent":"claude-code","checkpoint_id":"01M0N24THXB9W0FZFZ23YZWDK0","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19"}
{"time":"2026-08-22T11:59:49.696391086-04:00","level":"INFO","msg":"turn-start","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","component":"lifecycle","agent":"claude-code","event":"TurnStart","session_id":"cf0a7299-d289-44c6-a782-37d5e5419e19","session_ref":"/home/node/.claude/projects/-workspace/cf0a7299-d289-44c6-a782-37d5e5419e19.jsonl","model":""}

Additional context

No response

[atirna]

I can investigate the background Git-write path that temporarily replaces the user index during checkpoint work and keep the fix scoped to preserving independently staged entries. Is that direction approved for a PR?

[Soph]

Thanks - the two-git status transcript is what made this diagnosable, and your git reset --mixed HEAD~1 recovery is correct. I made a PR #2143 that prevents git status from refreshing the index on disc so this takes entire out of the responsibility for your issue. But multiple agents running git commands do the same. I posted you below the full suggested response from my agent session with more details. If you have time for the last two items that would be really appreciated.

Mechanism. git status is a write: it refreshes the index's stat cache and renames a fresh index over .git/index. On a filesystem where rename-over-existing isn't atomic against a concurrent lookup, a reader gets ENOENT — and git silently treats ENOENT on the index, and only ENOENT, as an empty index. So a git commit in that window records the empty tree with exit code 0 and no warning. That silence is why it destroys work instead of erroring.

We reproduced it in a virtiofs container: 2,939 ENOENT in 29,596 open() calls during continuous replacement (9.9%), versus 0 in 1.9M on container-native ext4. Your environment matches the precondition, and this looks like docker/for-mac#6787 — still open, spurious ENOENT for files that exist on bind mounts: 89/100 runs on gRPC-FUSE, 68/100 on VirtioFS, 0/100 on legacy osxfs.

Fixed on our side: #2143. Our checkpoint hook ran git status without --no-optional-locks, replacing your index about once per commit cycle. Running git status wasn't wrong — but we only read its output and discard it, so we were paying that write for nothing. It's gone, output byte-identical.

What that doesn't fix. On an affected mount any concurrent git status opens the same window — yours, another tool's, a watcher's, or several agents each running their own hooks. And our own numbers cut against us being your culprit: racing our real hook cycle against your workflow gave 0 empty-tree commits in 6,667 attempts. One checkpoint per turn with a microsecond window doesn't explain "under 5 attempts", so something with a higher duty cycle was likely holding it.

Workaround covering all of them, today — in your devcontainer:

"containerEnv": { "GIT_OPTIONAL_LOCKS": "0" }

--no-optional-locks is literally setenv(GIT_OPTIONAL_LOCKS, "0"), so this covers every git process in the session. Verified against the real binary. It also prevents a second symptom you may have hit — fatal: Unable to create '.git/index.lock': File exists while git status still works.

One correction, because it changes the workaround. The broken state doesn't persist and then heal: your block 2, a second later, shows a complete index with server.js staged, so the file was intact throughout and only block 1's reader missed it. Each command races independently, so sleeping between git add and git commit doesn't reliably help — the commit can lose on its own.

Two things that would help:

1. findmnt -T /workspace, stat -f /workspace, and your Docker file-sharing backend. Falsifiable prediction: on a container-native named volume this shouldn't reproduce at all — if it does, our model is wrong.
2. Does it reproduce with Entire disabled? git add fires no hook, so we can't tell which writer held your window: our hook, your own git status on the preceding command line (also an index replacement), or graphify's watcher — its references include add-watch, and a per-file-change watcher has a far higher duty cycle than our per-turn hook.

[markmont]

Thanks, Soph! I only enabled Entire recently; the problem did not occur before then. When I disable Entire, I am no longer able to reproduce the problem. It is possible that Graphify or another process is interacting with Entire and resulting in this problem. Thanks for #2143; I'll also set the GIT_OPTIONAL_LOCKS=0 environment variable and see if the problem still happens.

My Docker sharing type is virtiofs

$ findmnt -T /workspace
TARGET     SOURCE                                     FSTYPE   OPTIONS
/workspace host[/Users/markmont/wws/cloudflare/cfcfm] virtiofs rw,nosuid,nodev,relatime,ignore_atime,no_xattr

$ stat -f /workspace
  File: "/workspace"
    ID: 0        Namelen: 255     Type: fuse
Block size: 1048576    Fundamental block size: 4096
Blocks: Total: 975666340  Free: 678185940  Available: 678185940
Inodes: Total: 1370562902 Free: 1357633824

$