Only first commit per session gets Entire-Checkpoint trailer; subsequent commits silently skipped

[SvenMeyer]

Summary

When using entire configure --agent claude-code with the manual-commit strategy, only the first commit per turn gets the Entire-Checkpoint trailer. Subsequent commits within the same turn, and all commits in later turns, are silently skipped — no trailer is added, no checkpoint is created, and no error is logged.

This breaks the documented "Multiple checkpoints, single session" workflow described at https://docs.entire.io/web/sessions:

"A developer might have a single session running in a terminal while creating multiple commits throughout that session and thereby creating multiple checkpoints. Entire will match up these checkpoints to the single session."

Environment

• Entire CLI: 0.5.1 (d46fdc2)
• OS: Linux (Manjaro)
• Agent: claude-code
• Strategy: manual-commit
• Git hooks path: .husky/_ (via core.hooksPath)

Observed behavior

Prompt-by-prompt breakdown

1. Prompt 1 — generated a single commit 7917a85. ✅ Linked to session with checkpoint 1754c2af9609.

2. Prompt 2 — generated 3 commits while Claude Code was working:

   • 0dd88fa ✅ Linked to session with checkpoint 07386117e61f (first commit of this turn)
   • abb3213 ❌ No Entire-Checkpoint trailer
   • e1f6802 ❌ No Entire-Checkpoint trailer

3. Prompt 3 (same session, new turn) — generated 1 commit:

   • 482a585 ❌ No Entire-Checkpoint trailer

Pattern: Only the first commit ever made in a turn gets linked. After the post-commit hook runs for that first commit, all subsequent commits in the session are orphaned.

Dashboard view

Only 2 out of 5 commits show the "Claude Code" badge and checkpoint:

#	Commit	Message	Linked?
5	482a585	chore: clean up dependencies...	❌ No trailer
4	e1f6802	feat: integrate Openfort + Viem...	❌ No trailer
3	abb3213	refactor: remove Particle Network...	❌ No trailer
2	0dd88fa	style: format entire codebase...	✅ checkpoint 07386117e61f
1	7917a85	docs: add v0.1.0 status report...	✅ checkpoint 1754c2af9609

Root cause (from .entire/logs/entire.log)

The post-commit hook deletes the shadow branch after condensing the session. When the next commit happens, prepare-commit-msg cannot find the shadow branch, and silently produces no trailer.

Sequence from the log:

# Prompt 1, commit 1 (7917a85) — works
prepare-commit-msg: agent commit trailer added   (checkpoint: 1754c2af9609)
session condensed
shadow branch deleted                            ← shadow branch gone

# Prompt 2, commit 1 (0dd88fa) — works (shadow branch recreated between turns)
prepare-commit-msg: agent commit trailer added   (checkpoint: 07386117e61f)
session condensed
sessionHasNewContent: no shadow branch, checking live transcript
shadow branch deleted                            ← shadow branch gone again

# Prompt 2, commits 2-3 (abb3213, e1f6802) — NO prepare-commit-msg log entries at all
# The hook runs but entire silently exits without adding a trailer
# At turn-end, entire notices HEAD moved:
updated session base commit (HEAD changed during session), new_base: e1f6802

# Prompt 3, commit 1 (482a585) — also not linked
# No prepare-commit-msg log entry, shadow branch not available

The key gap: between 23:39:00 (shadow branch entire/7917a85-e3b0c4 deleted after commit 0dd88fa) and 23:47:42 (turn-end), two more commits were made with zero prepare-commit-msg activity in the log. The hook script pipes stderr to /dev/null (2>/dev/null || true), so any errors from entire hooks git prepare-commit-msg are silently swallowed.

No workaround available

We checked the available CLI commands (entire clean, entire reset, entire doctor) — none of them address this issue:

• entire clean — only removes orphaned data, doesn't recreate shadow branches
• entire reset — deletes shadow branch + session state, would make it worse
• entire doctor — fixes stuck sessions, not the shadow branch lifecycle

Even a "one commit per prompt" workflow doesn't reliably work — Prompt 3's single commit (482a585) also failed to get linked.

Expected behavior

Every commit made during an active session should receive the Entire-Checkpoint trailer, as documented. The shadow branch should either:

1. Not be deleted until the session ends (not after each commit), or
2. Be recreated before returning from the post-commit hook, so it's available for the next commit's prepare-commit-msg, or
3. prepare-commit-msg should not depend on the shadow branch existing to decide whether to add the trailer — it should be sufficient that an active session exists for the worktree.

Steps to reproduce

1. entire configure --agent claude-code in any repo
2. Start a Claude Code session
3. Make 3+ commits in the same session (either in one turn or across turns)
4. Only the first commit gets the Entire-Checkpoint trailer
5. Dashboard shows subsequent commits without the Claude Code badge

entire.log

entire.tar.gz

[Soph]

Hey, thanks for the detailed report! In general the shadow branch is deleted if all changes that were in the shadow branch were committed. This is expected. Also in your sequence in the log you can see how this worked for the second commit. In general this is a common scenario and should work.

Now after looking at your attached log we have a suspicion:

1. Commit 0dd88fa (the last working commit) committed 102 files including package-lock.json - this means the agent ran npm install during this turn.

2. Your repo has core.hooksPath = .husky/_, so Entire's hooks are installed in .husky/_/prepare-commit-msg. Husky's prepare lifecycle script runs on npm install and reinstalls its own hooks into that same directory, overwriting Entire's hooks.

3. The timeline from the logs:

   • 23:38:50 - prepare-commit-msg fires normally, trailer added (checkpoint 07386117e61f)
   • 23:38:50–23:39:00 - post-commit runs condensation (takes ~10s due to transcript flush timeouts)
   • 23:39:00–23:47:42 — Agent continues working, makes 2 more commits (abb3213, e1f6802). Zero prepare-commit-msg log entries — not even the "hook invoked" debug line that always fires first. The entire binary was never called.
   • 23:47:42 — Stop hook fires (via Claude Code's lifecycle, not git hooks). Detects HEAD moved: "updated session base commit (HEAD changed during session), new_base: e1f6802"

4. The fast path in prepare-commit-msg handles this scenario correctly — for agent commits (no TTY), it adds the trailer unconditionally for any ACTIVE session without needing the shadow branch or transcript content. If the hooks had still been installed, commits 2 and 3 would have gotten trailers.

We actually have an E2E test TestRapidSequentialCommits which covers exactly this scenario (3 agent commits in a single turn) and passes. The fast path (tryAgentCommitFastPath) adds trailers to all commits during an active turn regardless of shadow branch or transcript state.

This would explain the scenario until Prompt 3. Since in the user-prompt-submit hook we run EnsureSetup which makes sure the git hooks are there and would have recreated them. But still, can you check?

[Soph]

I also now build an integration test covering your scenario and it basically validates that if the hooks get overwritten during a turn the next prompt will recover them: #791

I also thought a bit if we can recover during the turn but that would mean we have to listen to all tool invocations and figure out if a git commit is done, and then validate hooks. Since doing it on every tool hook would be expensive.