warn when a coding agent commits in an enabled repo but no session is being recorded

Problem or use case

an enabled repo can silently accept agent-driven commits while recording nothing. entire's git hooks run on every commit, in the right repo, with settings loaded, and when they find no session they log a debug line (manual_commit_hooks.go:414) and move on. the user finds out much later, when they go looking for a session that was never recorded. i'd like to propose that this combination becomes a warning instead.

how i got here: i ran a long claude code session against this repo. it created a worktree, wrote a fix, committed twice, opened a pr. days later i wanted to look back at the session:

~/W/o/e/c/fix-checkpoint-metadata-bloat> entire checkpoint list
  branch       fix-checkpoint-metadata-bloat
  checkpoints  0

nothing on the branch and nothing in the web ui. the mistake was mine: i use a bare-clone worktree layout (a parent folder holding .bare/ plus one directory per worktree) and i started the agent in the parent folder instead of inside a worktree. agents read their repo-level config from the directory the session starts in, and that's where entire's hooks live (.claude/settings.json in my case, and the equivalent checked-in files for the other integrations). the parent folder has none, so no agent hook ever fired. the folder doesn't feel wrong either: its .git file points at the bare gitdir, so git commands work, branches resolve, commits succeed.

but the specific mistake matters less than the shape of it. "agent committing, nothing recorded" is reachable many ways:

• the agent session started outside the worktree (my case, and possible with any integrated agent, and from any directory above a normal repo)
• the hooks are registered but the binary they invoke fails at startup (i also had a second, older entire on my path that can't parse this repo's current settings schema; every hook invocation through it would die silently)
• the hooks were removed or drifted out of the agent's settings file
• session state was wiped mid-conversation with entire clean

no one warning can name the cause, and it doesn't need to. the commit is the anchor: at that moment the git hook already has everything needed to notice. entire is enabled in the worktree. the commit is agent-driven (claude code sets CLAUDECODE=1 in the environment of every command it runs, verified, and it also sets CLAUDE_CODE_SESSION_ID, so the warning could even name the unrecorded session; the interactive package already reads GEMINI_CLI, COPILOT_CLI and PI_CODING_AGENT as agent markers for tty detection; markers for the remaining integrations would need to be verified per agent). and no session anywhere in the repo has seen recent activity.

Desired behavior

$ git commit -m "fix: ..."
[entire] a coding agent is committing but no session is being recorded.
did the agent session start outside this worktree? run 'entire doctor' to check.

$ entire doctor          # run from the layout root
  ✗ you're at the root of a bare-clone worktree layout, not inside a worktree.
    entire is enabled in 3 worktrees below this directory:
      main/  fix-a/  fix-b/
    agent sessions started here are not recorded. start them inside a worktree.

a nice property of the git-hook route: hook stderr goes to whatever process ran git commit, which is the agent itself, so the warning lands in the agent's transcript and the agent can pass it on to the user immediately.

Proposed solution

warn when: settings are enabled, an agent env marker is present, and no session anywhere in the repo shows recent activity (session state carries LastInteractionTime, so "recent" is a cheap check against a live window rather than a guess). cause-agnostic on purpose: it catches every path into "nothing recorded" without having to detect any of them specifically. rate-limited the way warnStaleEndedSessions already does it (sentinel file mtime in the session-state dir, fail-open), once per worktree until a live session appears.

a note on why the condition is "no recently active session" rather than the more obvious "no session state files at all": ended sessions deliberately leave their state files behind (they're kept for amend-trailer restoration), and stray files accumulate in long-lived repos. i checked my own repo while writing this: .git/entire-sessions/ contains leftover state from months ago, so a zero-files condition would never fire anywhere a session has ever run. recency is the version of the signal that keeps working after the first week.

stay quiet when: a session is recently active somewhere in the repo, even if not in this worktree. that shape is usually deliberate (task fan-out into fresh worktrees, review in isolated worktrees, an agent cd-ing between checkouts), the driving session is alive and recording in its own worktree, and entire session adopt already covers moving it. warning here would mostly nag power users.

supporting pieces:

• the env markers could live in the agent registry, next to the per-agent facts each integration already declares (protected dirs, transcript layout). the hook checks the union over registered agents instead of a hardcoded list, each integration verifies its own agent's marker, and new integrations get detection for free.
• entire doctor could learn to diagnose the most common cause. detection: cwd .git is a file pointing at a bare gitdir, registered worktrees are children of cwd, and at least one of them has entire enabled while cwd has none. output: the message shown above, listing the enabled worktrees by name so the fix is a visible cd. no auto-fix on purpose: writing agent config at the layout root would be wrong (there's nothing to record against) and would teach the wrong habit. doctor's existing wiring checks (checkClaudeCodeHookDrift) already help with the hook-drift causes.
• these two land together or not at all: the warning's "run entire doctor" hint is only honest once doctor can actually recognize the situation. today doctor reports a healthy worktree (correctly, the worktree's wiring is fine) and has no concept of the layout root.

edge cases i thought about:

• human commits with no agent env never warn.
• a human committing from a shell that inherited an agent marker gets misread once, then the rate limit caps it.
• someone deliberately running an untracked agent in an enabled repo eats one line, and a settings switch (warnings.unrecorded_agent_commit: false or similar) turns it off for good.
• agents without a verified marker are missed, which is the status quo; registry-driven detection makes each fix a one-liner in the integration.
• there's no race with the first commit of a healthy session: session state is written at session start (lifecycle.go initializes it on the session-start event), before the agent can run anything, so if hooks fired at all a recently-active session exists. its absence is exactly the signal.
• a human committing by hand while no agent has run recently, in a repo with an agent marker leaked into the shell: the worst-case false positive, one line, once, suppressible.

happy to take this if the shape sounds right, and equally happy if you'd rather solve it differently.

Alternatives or workarounds

• discipline: always cd into a worktree before starting the agent. works until it doesn't, which is how i got here.
• running entire doctor proactively from inside a worktree confirms the wiring, though it reports healthy in this scenario, and in practice you only run doctor once you already suspect something.
• entire import (experimental) can backfill the lost session from the agent's own transcript after the fact, which recovers the data but not the moment the warning was needed.

Start at the commit-hook path in manual_commit_hooks.go:414 and compare its behavior with warnStaleEndedSessions, then inspect lifecycle.go, the agent registry, and the existing checkClaudeCodeHookDrift doctor wiring. Run the relevant hook and doctor checks; done means agent commits with no recently active session produce a rate-limited warning and doctor identifies the bare-clone layout case while human commits remain quiet.