Agent sessions should adopt enabled repos when a long session switches git common dirs

[peyton-alt]

Summary

A long-running agent session can move from one git repository into another enabled repository and make commits that get no Entire-Checkpoint trailer, even though the CLI is installed and git hooks are present in the second repo.

This is distinct from same-repo sibling worktree matching. In this case the two repositories have different git common dirs, so the second repo's prepare-commit-msg hook cannot see the session state that was initialized in the first repo.

Observed repro from local investigation

While working on entirehq/entire.io, a Codex session was active in:

/Users/peytonmontei/Documents/entire/devenv/entire.io/.worktrees/merge-in-trails

The session state exists in the entire.io repo:

/Users/peytonmontei/Documents/entire/devenv/entire.io/.git/entire-sessions/019ed223-016e-7181-b420-dafc7d141cf4.json

Summary of that state:

agent_type: Codex
phase: active
worktree_path: /Users/peytonmontei/Documents/entire/devenv/entire.io/.worktrees/merge-in-trails
last_interaction_time: 2026-06-16T19:44:57-04:00

During the same conversation, the agent switched to the CLI repo worktree:

/private/tmp/entire-session-match-fix

and committed/pushed:

f9005540ed2b822363cf9aeefa87574a83517073 Match sessions across sibling worktrees

That commit has no trailer:

git show -s --format=%B f9005540ed2b822363cf9aeefa87574a83517073

Match sessions across sibling worktrees

The CLI repo did have hooks installed:

/Users/peytonmontei/Documents/entire/devenv/entire/.git/hooks/prepare-commit-msg

#!/bin/sh
# Entire CLI hooks
entire hooks git prepare-commit-msg "$1" "$2" 2>/dev/null || true

But its repo-local session store was empty:

/Users/peytonmontei/Documents/entire/devenv/entire/.git/entire-sessions
# no *.json session states

The git common dirs are different:

entire.io repo: /Users/peytonmontei/Documents/entire/devenv/entire.io/.git
cli repo:       /Users/peytonmontei/Documents/entire/devenv/entire/.git

So the hook in the CLI repo fired, looked in the CLI repo's .git/entire-sessions, found no active session, and skipped trailer insertion.

Expected behavior

If an agent session with Entire enabled moves into a second enabled git repository and commits there, Entire should not silently lose provenance.

Possible acceptable behaviors:

1. Adopt/create a repo-local session state in the second repo, keyed to the same agent session/transcript, so commits in that repo get trailers/checkpoints.
2. Detect that an agent session is active elsewhere but missing in the current repo and emit a clear warning before/when the commit hook skips.
3. Provide an explicit multi-repo/orchestrator session model that can attach one agent transcript to multiple repo-local checkpoint streams.

Actual behavior

The commit hook silently skips because the current repo has hooks installed but no repo-local session state. The resulting commit has no Entire-Checkpoint trailer.

Why this matters

Users reasonably expect "Entire is installed and the agent session is active" to mean commits made by that agent are checkpointed. Long agent sessions often inspect or patch multiple repositories. Today, a repo switch can produce uncheckpointed commits without any visible warning.

This is especially confusing because same-repo worktree fixes do not help here: the failure crosses git common dirs, so session lookup by shared common dir is intentionally not enough.

Related

• Support orchestrator sessions launched outside git repos (multi-repo worktree workflows) #529: orchestrator sessions launched outside git repos / multi-repo worktree workflows
• [Feature Request] Global auto-enable: track agent sessions without per-repo configuration #1098: global auto-enable / track sessions without per-repo configuration
• Only first commit per session gets Entire-Checkpoint trailer; subsequent commits silently skipped #784 / prepare-commit-msg hook silently fails to add Entire-Checkpoint trailer #686: other prepare-commit-msg missing-trailer reports

Fix direction

Investigate agent lifecycle hooks for repo transitions. In particular:

• Codex/Claude hooks should be able to initialize or adopt session state when the active agent begins operating inside a different enabled repo.
• prepare-commit-msg should distinguish "Entire disabled" from "hooks installed but no active session in this repo during an agent-driven commit" and surface an actionable diagnostic.
• Any cross-repo adoption must avoid accidentally attaching one repo's checkpoint metadata to another repo's commits; the checkpoint streams should remain repo-local even if they share an agent transcript/session identity.

[Sokcevic]

Related scenario, and a vote for fix direction 3.

Scenario: a parent directory containing several independent sibling repos (e.g. microservices), each already entire enabled, where a single agent session needs to make coordinated changes across two or more of them. Different root cause path than the original #529 report, but it lands on the same open question this issue raises. Worth noting PR #1440 (matching sessions across sibling worktrees) explicitly doesn't cover this — it's scoped to sessions within one git common dir, and its description defers cross-common-dir adoption here.

I'd like to make a case for direction 3 over 1/2, and sketch a possible mechanism, since this issue doesn't have anything in flight yet.

Directions 1/2 ("adopt into the second repo" / "warn when session is active elsewhere") both assume a session belongs to one repo at a time and gets handed off or flagged as it moves. That works for the "long session wandered into another repo" case, but not for genuinely joint work — a single prompt intentionally producing coordinated commits in repo A and repo B should show up as two checkpoints, one per repo, not a handoff from one to the other. Direction 3 is the only one of the three that models that correctly.

A possible mechanism, building on machinery that already exists for a different purpose: PostToolUse[Task] → TaskStepContext → SaveTaskStep already tracks subagent work independently of the top-level session, and TaskStepContext.ModifiedFiles is already extracted from that subagent's own transcript slice, not a global diff. If the orchestrating agent delegates per-repo work to dedicated subagents (which entire could actively encourage, e.g. via a shipped skill/plugin, rather than relying on the model to do it unprompted), each PostToolUse[Task] firing is already naturally scoped to one repo's file set. What's missing to turn that into direction 3:

1. Generalize file→repo attribution: resolve each modified file's nearest-ancestor .git instead of assuming everything belongs to the one resolved WorktreeRoot.
2. Fan the checkpoint write out to each touched repo's own .git/entire-sessions, linked by a shared parent/joint session id, rather than writing only to the orchestrator's (possibly nonexistent) repo.
3. Reuse the multi-repo, multi-common-dir locking that entire session adopt already implements (session_adopt.go, strategy.WithSessionStateLocks across two common dirs) — generalized from a one-shot transfer into a fan-out-create across N repos.

One thing worth deciding early: joint-session metadata that names sibling repos could leak project topology across repos with different access grants (e.g. a client-confidential repo referencing an internal tooling repo by name). That probably needs to default to off/redacted rather than on.

Happy to take a pass at this if a multi-repo/orchestrator session model (direction 3) is the direction maintainers want — wanted to check in here first per the contributing guide before writing code.