I've started four read-only investigations, one per issue, to trace each to a cause in the code (with file:line). When they finish I'll check the key claims myself and come back with a ranked list of causes and fixes. I won't edit anything until you pick which issues to fix.

I've checked the investigation of issue 4 (checkpoint explain) against the code. Three others are still running.

Issue 4: explain doesn't expose subagent data

• The tokens are dropped by a partial copy, not left out of the output. token_usage is already printed, just per session (sessions[].token_usage), not at the top level where the report looked.
  • The per-session copy uses its own four-field struct, checkpointSessionTokens (cmd/entire/cli/explain_export.go:437).
  • sessionMetadataToJSON copies those four fields one by one (explain_export.go:569). That leaves out SubagentTokens, SubagentTokensComplete and APICallCount.
  • Fix: use *types.TokenUsage directly. One side effect: zero cache counts would print as 0 instead of being omitted, so the export tests need updating.
• Nothing reads task records back. tasks/<tool_use_id>/{task.json, agent-<id>.jsonl} is only ever written, by writeTaskRecordEntry (cmd/entire/cli/checkpoint/persistent.go:491). No reader exists in any checkpoint store.
  • Fix: add a TaskReader interface with ListTasks and ReadTaskTranscript. It has to be implemented in both storage backends, the fan-out and routing wrappers, and the file store. The API reader used by --repo should return "unsupported".
  • Then add a top-level tasks[] to --json, and a --task <tool_use_id|agent_id> flag that requires --transcript.
  • Tasks belong at the top level because task.json doesn't record which session it came from.
  • No new command or agent-help classification is needed. Only the existing checkpoint explain guidance text changes.

I'll add the other three issues once their investigations finish.

I've checked the issue 2 and issue 3 findings against the code. The investigation of issue 1 (attribution) is still running.

Issue 2: task.json is missing fields

The record struct does have files, token_usage and completed_at, and the writer passes them through. They come out empty because of how each agent's completion paths work.

• Claude Code, token_usage (confirmed): the per-task tokens are copied from the subagent-stop hook payload (lifecycle.go:1993). No Claude parser fills that payload field; only Cursor's does. Claude subagent tokens are only ever added into the session total.
  • Fix: when the payload has no tokens, compute them from the subagent's transcript in completeSubagentTaskRecord.
• Claude Code, files (likely but not confirmed): on the stop path, files come only from reading the subagent's transcript. There is no worktree scan.
  • The list ends up empty in three cases:
    • The transcript path can't be resolved.
    • The paths fall outside the repo root.
    • filterToUncommittedFiles drops them.
  • The test repo's .entire/logs will say which. Look for the warning "subagent transcript unresolvable; final capture proceeding without file attribution".
• Codex, all three fields (code path confirmed): Codex's subagent-stop hook only records that the stop happened; it never completes the task record (lifecycle.go:1557). Completion happens only in refreshCodexInventory, which runs at the parent's turn end or at session end.
  • In this scenario the parent waited for the subagent and committed within the same turn, so the commit stored the record while it still looked in progress.
  • That same refresh is also the only thing that sets subagent_tokens_complete back to true, which is why it reads false.
  • Fix: run the same refresh before condensation writes the task records.

Issue 3: the redactor removes non-secrets

Every case is caught by the entropy check: any run of [A-Za-z0-9+_=-]{10,} scoring above 4.5 (redact/redact.go:29, :67). The only exemptions are based on the JSON key name (redact/redact.go:1340). Nothing exempts a value because of its shape.

Any change to the entropy check must also bump configFingerprintVersion (redact/fingerprint.go:19). Otherwise the redaction cache keeps serving the old output.

I've traced all four issues to causes in the code. The pasted report's guess about issue 1 is wrong, and so was one of my own saved notes.

1. Claude subagent edits credited to the human (high)

The reported guess is wrong: the code does read the subagent's own transcript to find the files it changed, and that works on 2.1.288. The real cause is timing:

1. The parent agent's turn ends while the background subagent is still running, so the last snapshot doesn't contain the subagent's edits.
2. When the subagent finishes, Claude Code wakes the parent with a notification. That notification starts a new turn, in the same millisecond as the subagent's stop event.
3. At the start of every turn, calculatePromptAttributionAtStart counts every difference from the last snapshot as human work (manual_commit_attribution.go:533). The 37 subagent lines become user_lines_added: 37.
4. At commit, agent lines are the snapshot diff minus the human lines on agent files: 37 − 37 = 0. That matches the reported checkpoint exactly.

Codex is unaffected because its parent waits for the subagent inside the same turn, so no new turn starts in between.

• Fix: at turn start, leave out files a subagent changed since the last snapshot. Taking a snapshot when the subagent stops wouldn't help, because the new turn starts in the same millisecond.
• Trade-off: a human edit to the same file in that window would be credited to the agent. That is the same compromise the code already makes within a single turn.
• Not yet confirmed by a test. The last two steps are read from the code; no test has reproduced the whole sequence. An integration test that simulates the subagent stop, then the notification's prompt, then a stop and a commit should show agent_lines: 0 today.

Correction to my notes: they said Claude Code 2.1.288's subagent-stop event never includes tool_use_id. This session's own log shows one that did, and nothing fills it in after the fact. I've corrected the memory to say "re-check before relying on it".

2. task.json missing fields (medium)

The fields exist; the paths that should fill them don't.

• Claude token_usage: never computed per task. Fix: calculate it from the subagent's transcript when the task completes.
• Claude files: probably the subagent transcript couldn't be found or the files were filtered out. Not confirmed; the scenario repo's .entire/logs will say which.
• Codex completed_at, files and tokens: a task is only marked complete at the parent's turn end. This parent committed earlier in the same turn, so the record was stored while it still looked in progress, and subagent_tokens_complete stayed false. Fix: run the same refresh before the commit stores task records.

3. Redactor false positives (low to medium)

All of it comes from the high-entropy check, and the only exemptions are by JSON key name.

• toolu_ ids: exempt only an exact toolu_01 + 22-character match. The suggested toolu_[A-Za-z0-9]+ prefix rule would let a secret appended to an id through.
• Claude project-folder names: only folders made from scratchpad or temp directories get redacted (17 of your 369). The memory-path example didn't reproduce. Exempting them by shape is unsafe, since a secret in a directory name would pass. Either exempt only the exact name derived from that line's cwd, or accept it.
• Codex gAAAA… tokens: don't exempt them, because apps produce the same format with real keys. Instead, strip encrypted_content from Codex agent_message items (agent/codex/transcript.go:907); it's unreadable anyway.
• Any change to the entropy check also needs a bump to configFingerprintVersion (redact/fingerprint.go:19), or the cache keeps serving old output.

4. checkpoint explain (medium)

• subagent_tokens is lost because the session's token_usage is copied into a four-field struct (explain_export.go:437). Use the full type instead.
• Nothing reads task records back at all. That needs a new reader in both storage backends, then a top-level tasks[] in --json and --task … --transcript.

I'd start with 1, then 2. Want me to write the failing test for 1 and then fix it?

Issue 1's fix is up as PR #2646. The new test failed on main and passes with the fix. Format, lint and the full test suite are clean except one test that fails the same way on main locally (TestOpenCodeSeedRepoPlantsDeps, which needs the e2e OpenCode setup step).

What was wrong: Claude Code runs every subagent in the background, so the subagent finishes after the parent's turn has ended. Its completion saved no snapshot. Claude Code's notification then starts a new turn, and the start of a turn counts every change since the last snapshot as human work. The turn after that didn't snapshot the file either, so the commit computed agent lines as 37 − 37 = 0.

Fix: the session state now keeps a list of files a subagent wrote that no snapshot holds yet.

• Filled: when a subagent completes. Also at the start of a turn, from the transcripts of subagents still running, which covers the notification beating the subagent's own stop event.
• Used: turn start leaves these files out of the human count, and the next turn end snapshots them.
• Commit with no snapshot yet: the committed content stands in for the snapshot.
• Trade-off: if a human edits a subagent's file between the subagent finishing and the next snapshot, that edit is credited to the agent. The code already makes the same compromise within a single turn.

Tests: one integration test with six variants:

• either order of the subagent's stop and the notification's new turn,
• a commit before any later turn ends,
• each with and without an earlier parent snapshot.

All six failed before the fix. With an earlier snapshot they reproduce the report's numbers; without one, the subagent's lines vanish into the "existing before the session" bucket instead. Turning off the turn-start scan makes the notification-first variants fail again. A unit test covers one edge case: a step skipped because nothing changed must still clear the list.

The review trail for #2646 hasn't been created yet. I'm waiting for its findings in the background and will go through them before starting on issue 2 (task.json missing fields) in its own PR.

The watcher is running for #2646 and #2647, and the redaction and checkpoint explain agents are still working. I'll handle whichever finishes first.

That notification is the first watcher run I stopped on purpose; the replacement is still running. Waiting on it and the two agents.

Status so far:

• #2647: fixed and pushed Bugbot's finding (an unreadable parent transcript no longer skips the Codex refresh).
• #2648: the redaction PR is open.
• Waiting on: the checkpoint explain agent, plus new comments or trail results on any of the three PRs.

All four PRs are open and every review comment so far is handled. The watcher keeps running; I'll address what comes in and then write the summary.

Waiting on the #2649 fixes and the watcher.

I've opened all four fixes as separate PRs. Each started with a test that failed and passes after the fix. All review comments and trail findings so far are addressed, either by fixing them or by a reason recorded on the finding.

#2646: a background subagent finishes after the parent's turn has ended, and Claude Code's notification starts a new turn at the same moment. That turn counted the subagent's lines as the human's.

• When a subagent's edit is observed, the file's content is now saved as a git blob. Attribution counts only changes made after that point as human, both at turn start and at commit.
• Review rounds caught real problems in my first version, all fixed:
  • Old edits were picked up again from the subagent's transcript.
  • User edits made after the subagent finished were credited to the agent.
  • session adopt copied stale pending files into the new worktree.
  • Lines the subagent deleted weren't credited to it.
  • A double count that probably happens without subagents too: a user edit to an untracked file the agent created, made between turns, was counted twice if the next turn didn't touch the file.

#2647:

• Claude per-task tokens are now computed from the subagent's own transcript.
• The git post-commit hook now reconciles Codex children first, so a mid-turn commit no longer stores a finished child as still running.
• After review, that refresh only runs for commits with a checkpoint trailer, and only for non-ended Codex sessions in this worktree.

#2648: a toolu_ id is exempt from redaction only when the whole match is exactly toolu_01 plus 22 characters, so a secret appended to an id is still redacted. Codex agent_message ciphertext is now stripped by the cleanup step instead of being redacted.

#2649:

• --json now shows full per-session token usage and a top-level tasks array.
• A new --task <id> --transcript streams one subagent's stored transcript.
• Review fixes:
  • A size limit on reading stored task files.
  • Read failures are no longer reported as "not found".
  • An exact tool_use_id match wins over agent-ID matching.
  • Nested token usage is capped in depth.

Open questions:

1. Empty Claude files in task.json (issue 2) is not reproduced. The scenario repo's .entire/logs would show the cause. Look for the warning "subagent transcript unresolvable; final capture proceeding without file attribution". Can you share that log or rerun the scenario?
2. #2646 trade-off: a human edit made between a subagent writing a file and Entire noticing it is credited to the subagent. That window is the next turn start or the subagent's completion. OK?
3. #2648: Codex spawn_agent tool calls carry the same ciphertext in arguments.message, and it's still redacted. Fixing it means rewriting tool-call arguments: drop the value or keep a placeholder?
4. #2648: I deliberately did not exempt Claude project-folder names in paths. A shape-based exemption would let a secret in a directory name through. Only folders made from scratchpad or temp directories are affected (17 of your 369). Accept that, or exempt only the exact name derived from that line's cwd?
5. #2649 product choices to confirm:
   • TaskReader is required on every checkpoint store, not optional.
   • token_usage now always shows the cache fields, even at zero.
   • --task matches exact IDs only and works only with --transcript.
   • --repo output leaves tasks out rather than showing an empty list.
   • Tasks appear only in single-checkpoint --json.
6. Not addressed: when a subagent is resumed with SendMessage, the resumed run's file edits aren't attributed to its task (from my earlier notes).

I didn't post any PR comments.

What would you like to clarify?

For context, the decision is how to capture files a background subagent writes through shell commands. The transcript analyzer only sees Write/Edit-style tool calls, so those files currently go unrecorded. They also stay credited to the human, even after #2646.

The three options I had in mind:

• Scoped diff plus marker (my recommendation): only when the subagent ran shell commands, add files that changed since its launch, and mark the record as worktree-derived. This needs a content baseline captured at launch. The risk: edits by the parent, a parallel subagent, or the human in that window get attributed to this subagent.
• Marker only: don't guess at files. Flag the record so null no longer reads as "read-only". Shell-written lines stay human.
• Unscoped diff: always fall back to a worktree diff when the analyzer finds nothing, like foreground capture does. Simplest, but it has the widest cross-attribution.

Here's what the data shows, and two more options. One of them works around the parallelism problem fairly well.

What your transcripts show (437 local Claude subagent transcripts across 104 parent sessions, most of them your own review and research agents, so skewed to your usage):

Three conclusions:

1. Missing shell writes is the normal case here, not an edge case. The current analyzer misses most subagent writes in your usage.
2. A diff over a whole subagent's lifetime is ambiguous most of the time, because 80% of subagents overlap another one.
3. Reading the write target from the command won't be precise. Only 92 of the 248 writing subagents had all their writes in a form a parser could read. The rest went through Python heredocs, formatters, git checkout/stash, builds and installs. My own regex classifier was visibly noisy on top of that, so treat its counts as rough.

Two more options:

• A. Match each file's modification time against the subagent's Bash call windows (my recommendation). Every Bash call in a subagent transcript has a start time (the call) and an end time (the result).
  • At stop, take the files changed since launch and check each file's last-modified time.
  • If it falls inside exactly one agent's call windows, credit that agent. That check covers this subagent, other live subagents and the parent, using their transcripts.
  • If windows overlap, mark the file ambiguous instead of guessing.
  • A later human edit moves the timestamp outside every window, so it naturally stays human.
  • It needs no new hooks and adds no per-call cost.
  • Limits: only the latest write per file is visible, deletions have no timestamp, and the per-call overlap (~17% upper bound) still leaves some files ambiguous.
• B. Snapshot the worktree around each Bash call. Hook every subagent Bash call (PreToolUse/PostToolUse) and diff the worktree around it. Windows of seconds make this the most precise option. But it costs a git status per Bash call (18k calls in this sample), and it only works if Claude Code's hook payload says which subagent made the call. I haven't checked that; it needs a small paid probe run.

Either way, I'd record where a task's file list came from (transcript, matched by timestamp, or ambiguous), so a null is never mistaken for "read-only".

Want me to prototype option A against these transcripts first, to measure how many changed files it would attribute unambiguously? That only takes the local data, and it would tell us whether A is good enough before writing the hook code.

Option A holds up well in the prototype. In the simulation it never credited a write to the wrong agent, and with two refinements 88% of subagent writes land on a single agent.

How I tested it: the old file timestamps are gone, so I used writes whose author is certain. That's every Edit/Write call, by the parent or a subagent, across 105 local sessions that used subagents: 786 writes, 339 of them by subagents. Each write's time is when its result was logged. I then asked which agents had an open call window around that moment (±0.5s).

Those rows are for subagent writes. The parent's own writes are 100% correct even without filtering.

Human edits credited to an agent: a human edit gets credited to an agent if its timestamp falls inside some agent's write window. While subagents are running, those windows cover about 4% of the time in the median session and 23% in the 90th percentile. That is the chance a human edit made then gets misattributed, versus today, where every shell-written agent line goes to the human.

Caveats, so you don't over-trust these numbers:

• Ground truth is Edit calls only. A shell write can land anywhere in its Bash window (median 1.8s, 90th percentile 7s), so shell writes will be somewhat more ambiguous than this.
• The tie-break result is optimistic. A subagent usually Reads a file before Editing it, so for Edit ground truth the author almost always mentions the file. Shell writes usually name their target in the command, so it should mostly carry over, but this data can't measure that.
• "Looks like a write" is a regex heuristic. If it misreads a writing command as read-only, the file gets no candidate and falls back to human, which is no worse than today.
• A file's timestamp only shows its last write, and deletions have none. Deletions would need the diff alone.

What I'd build: at subagent stop, for files changed since launch that the transcript doesn't explain, match the file timestamp against Bash call windows across the session (write-looking calls only, with the path-mention tie-break):

• Single match: credit that agent, and record that the file was matched by timestamp.
• Ambiguous among agents: still agent work for line attribution, but list it separately (for example files_ambiguous) instead of claiming it for one task.
• No match: leave it to the human.

The same rule would also feed #2646's pending-file baselines, so shell-written subagent lines stop going to the human.

The prototype scripts are in the session scratchpad (mtime_proto.py, mtime_proto2.py, bash_analysis2.py). Should I implement this as a fifth PR on top of #2646, or wait until #2646 merges?

Mostly no, and it's not what we do today, because top-level agents usually don't need it. Each turn is already a window that belongs to one agent:

• At prompt start, Entire records which files are untracked and counts any changes since the last snapshot as human edits.
• At turn end, a git status scan picks up whatever changed during the turn, including Bash edits, and credits it to the agent.

Background subagents break this because they run outside any turn. The timestamp matching makes sense in general only where that window stops being exclusive. Three places:

1. An untracked file that existed before the prompt, then edited via Bash. I confirmed this one in the code (state.go:329): turn-end detection skips untracked files that existed at prompt start entirely. Tracked files are compared through git status; untracked ones are only checked for being new. So if the agent shell-edits an untracked file created in an earlier turn, and the transcript has no Edit call naming it, the turn doesn't snapshot it. The next turn start then counts those lines as human. This is the same blind spot behind the double count I fixed in #2646. A timestamp check fixes it cheaply: include pre-existing untracked files modified within this turn's window. Here the turn is the window, so there's no ambiguity. I'd do this regardless of the subagent work.
2. Two sessions in the same worktree. Turn-end detection has no cross-session filtering, so each session's turn-end scan likely sweeps in the other session's changes. Commit-time attribution does exclude files other sessions touched, so the agent-versus-human split probably survives. But which files each session claims is mixed. Likely, not verified. The same timestamp-plus-call-window matching would separate them, with exactly the ambiguity profile the prototype measured.
3. Human edits during an agent's turn. Today everything that changes during a turn counts as agent work. Timestamps could split off edits made outside any agent tool window. I'd not do this one by default: long-running commands, editor autosave and formatter hooks write outside tool windows, so it could move real agent work to the human. A precision gain with a real regression risk.

My suggestion:

• Do 1 now: a small, separate change with a clear failing test.
• Build the matcher once: the subagent timestamp matcher as planned, as a shared helper that works over any set of agent transcripts.
• Bring 2 in later: once the helper exists and we've confirmed the per-session file mixing is real.
• Leave 3 alone unless the human-during-turn case shows up in practice.

Want me to proceed in that order: 1 as its own PR, then the subagent matcher?

Yes, the matcher went into #2646, and the pre-existing-untracked-file gap is its own PR, #2650. Every new test failed before its fix and passes after.

#2646 now credits files a background subagent writes through Bash to that subagent:

• How it matches: a changed file is the subagent's when its last-modified time falls inside one of the subagent's write-looking Bash calls and inside no other agent's call. When calls overlap, the side whose command names the file wins.
• Ambiguous files: if neither side names it, the file still counts as agent work, but it isn't listed on that subagent's task.json.
• Human files: a file changed outside every agent tool call stays the human's.
• Test: a subagent writes a file with printf … > while a human writes another file. Before, it gave agent_lines=1 human_added=5 and an empty task.json file list. After, the shell lines are agent lines and the task lists the file. Turning the matcher off makes it fail again.
• Trail finding fixed: a long-running command (a build, an install) lost files written after the first scan. Scans now stop before a Bash call that is still running, with a test that reproduced it.

#2650: an agent's shell edit, during a turn, to an untracked file that already existed when the prompt arrived never reached the turn's snapshot. The next prompt counted those lines as the human's.

• Fix: turn end now includes such files when they were modified after the prompt arrived.
• Canary catch: the first version broke the deterministic canary. The prompt time had second precision, so a file written in the previous turn within the same second looked modified. The prompt time is now recorded with nanoseconds, and unit, integration and canary tests all pass.

I also updated #2647's description: the empty Claude files field was the Bash blind spot, fixed in #2646.

I'm watching all five PRs for comments and trail findings in the background.

Remaining open questions:

1. Imprecision #2646 still accepts.
   • A human edit inside an agent's Bash window counts as agent work. In your transcripts, those windows cover about 4% of subagent run time in the median session and 23% at the 90th percentile.
   • While a long Bash call is still running, Edit-tool changes after it get read again. A file already snapshotted since could get a newer baseline, which hides human edits made in between.
2. Ambiguous files are agent work but appear nowhere on a task record. Should task.json get a files_ambiguous list? #2649 is changing the task.json type, so I'd add it after that merges.
3. Codex spawn_agent ciphertext (#2648): it's still redacted. Drop the value, or keep a placeholder?
4. Claude project-folder names in paths (#2648): accept the over-redaction, or exempt only the exact name derived from that line's cwd?
5. #2649 product choices are listed in its PR description.
6. Not tested: two sessions in the same worktree claiming each other's files at turn end. Worth checking before reusing the matcher there.

I went through every PR comment and trail finding again. Four items had arrived since my last summary. I fixed three and dismissed one as wrong. All five trails now have 0 open findings, and every PR is waiting only on human approval.

#2646 (subagent attribution):

• High: gitignored files written to git. When a subagent touched a gitignored file like .env, its plaintext content was saved into the repo's git object store. The baseline capture now skips gitignored files, using the same check the normal snapshots use; if that check fails, nothing is saved. A new test confirms .env gets no baseline and its content isn't in the object store.
• Medium: two separate writes at turn end. Turn end saved the snapshot and the subagents' scan positions in two separate state writes. If the second write failed, the next turn could re-record already-saved files from content that included human edits. Both now happen in one write, whether a new snapshot is written or skipped as unchanged. A new test covers both cases.

#2650 (untracked files edited by the agent):

• Copilot: symlinks were skipped. An agent re-pointing an untracked symlink (ln -sfn) was missed. Symlinks are now included; snapshots already store a link as its target text. The symlink part of the test is skipped where symlinks can't be created (Windows without the right privileges).
• High: timestamp format, dismissed as wrong. The finding said Go's standard timestamp parser can't read the new nanosecond timestamps, which would silently disable the fix. It can: parsing accepts fractional seconds, and go run read a nanosecond timestamp exactly. I added a test that pins this, telling apart writes 300ms before and after the prompt, and recorded the evidence on the dismissal.

The review summaries posted on each PR only repeat inline comments that were already handled.

Unit, integration and canary tests pass on both branches, and lint is clean. The open questions from my last summary still stand, and I didn't post any PR comments.

I fixed and resolved the new finding on #2646, but the push went out with one unexplained test failure. Every other PR and trail is unchanged: 0 open findings and no new comments.

The finding: a still-running subagent that wrote the same file twice (a build appending to a log, or two Edits across a turn boundary) had its second write credited to the human. I had kept the first baseline recorded for a file. Since a scan only reports a file when the subagent shows new evidence of writing it, the later baseline now replaces the earlier one. The test TestSubagentEditCapture_LaterObservationWins failed first and passes now. The trade-off, documented in the code: a human edit made between two of the subagent's writes to the same file now counts as the subagent's.

The failure: after the fix, lint, the strategy unit tests, the integration tests and the canary passed. The cmd/entire/cli unit tests printed FAIL once, but my command only checked tail's exit code, so the commit and push went through anyway. I couldn't reproduce it: the package passed on four reruns. That's the second unexplained one-off failure in this package today; the first was on the #2650 branch. It looks like a load-sensitive flake, but I don't know which test it is. #2646's CI run on that commit will show whether it repeats.

The earlier open questions still stand.

There are seven open questions. The first two only need a yes or no on a trade-off I've already built in.

Trade-offs already in #2646:

1. When a human edit counts as agent work. Three cases:

   • The human edits a file while a subagent's Bash command that looks like a write is running. In your transcripts, those windows cover about 4% of subagent run time in the median session and 23% at the 90th percentile.
   • The human edits a file between two writes by the same subagent to that same file. A later baseline now replaces the earlier one.
   • While a long shell call is still running, Edit-tool files after it are read again and re-recorded from their content at that point.

   OK as is?

2. Ambiguous shell-written files. These are files written while several agents' calls overlapped. They count as agent work but appear on no task record. Should task.json get a files_ambiguous list? I'd add it after #2649 merges, because that PR changes the task.json type.

Product decisions:

1. Codex spawn_agent ciphertext (#2648). The encrypted arguments.message is still redacted. Drop the value, or keep a placeholder?
2. Claude project-folder names in paths (#2648). The folder name inside paths like ~/.claude/projects/<folder>/ gets redacted when it was derived from a scratchpad or temp directory: 17 of your 369. Accept that, or exempt only the exact name derived from that line's cwd?
3. #2649 choices to confirm:
   • Every checkpoint store must implement TaskReader.
   • token_usage now always shows cache fields and api_call_count, even at zero.
   • --task matches exact IDs only and works only with --transcript.
   • With --repo, the JSON leaves tasks out rather than showing an empty list.
   • Tasks appear only in single-checkpoint --json, not in the list view or text output.

Not done yet:

1. Two sessions in the same worktree. I believe each session's turn end sweeps in the other's changes, but haven't confirmed it. Investigate before reusing the matcher there?
2. A subagent resumed with SendMessage. The resumed run's file edits aren't attributed to its task. This comes from my earlier notes, and none of the five PRs touches it. Worth a PR?

The task record lists only files the matcher can prove came from that subagent. An ambiguous file was written while calls from several agents overlapped, so it can't honestly go on any one task. The plan was for it to live only at the session level, as a pending agent file.

Checking where pending files flow showed a gap, though, so I need to correct what I said earlier:

• Pending files never enter FilesTouched. FilesTouched is the session's list of agent-touched files: it decides commit linking, it becomes the checkpoint's files_touched, and it's the only list commit-time attribution walks. A file joins it only through a task's file list (applyTaskRecordCompletion) or a turn-end snapshot (SaveStep).
• Next turn ends first: that turn end snapshots the ambiguous file, adds it to FilesTouched, and it counts as agent work. Fine.
• User commits first: the file is in neither place. Commit-time attribution treats it as a file no agent touched and credits its lines to the human. Pending files are only consulted inside the FilesTouched loop (manual_commit_attribution.go:265), so this baseline is never used. A commit that contains only that file also doesn't get linked to the session.

So my earlier claim that ambiguous files "count as agent work" is false in the commit-before-the-next-turn case. That's exactly the "user commits right after the subagent finishes" flow.

Proposed fix: whenever a file is recorded as pending, also add it to the session's FilesTouched, in the same state update. That puts it in files_touched and makes commit-time attribution use its baseline. The task record still lists only provable files.

A separate files_ambiguous field on task.json is then optional extra detail, not what makes these files visible.

Shall I make that fix in #2646, test-first? The test would be a Bash write that overlaps the parent's Bash call, followed by a commit before the next turn.

Pending files are a field I added in #2646: PendingSubagentFiles in the session state. It maps a file path to a git blob hash:

What they represent: files a subagent wrote that no shadow snapshot holds yet. Normally a turn's snapshot captures what the agent did. A background subagent finishes outside any turn, and its completion writes no snapshot, so its edits sit in the worktree unaccounted for. The pending entry closes that gap until the next snapshot.

The blob is the "observed content": the file as it was when Entire saw the subagent's write. It's stored with the same git hash-object-style write the snapshots use, so it costs one object per file, and gitignored files are skipped. That content is what lets user edits and subagent edits be told apart later.

Lifecycle:

How it differs from FilesTouched: FilesTouched is "files an agent touched in this checkpoint window". It drives commit linking and files_touched. Pending files are narrower and temporary: "a subagent wrote this, and the snapshot doesn't know yet, so here's what it looked like." The gap is that recording a file as pending doesn't also put it in FilesTouched, so the commit-time half of the mechanism only works for files that got there another way.

Because FilesTouched only records that an agent touched a file. Attribution needs to know what the file looked like when the agent was done with it. Both halves of the bug come from missing content, not a missing name.

At turn start: prompt attribution diffs every changed file against the last snapshot. It doesn't consult FilesTouched at all. So with docs/shell.md in FilesTouched but no newer snapshot, the subagent's 3 lines still count as user lines. That's the original bug, unchanged.

At commit: for files in FilesTouched, agent lines are base→snapshot and user lines are snapshot→committed. The snapshot predates the subagent's write, so base→snapshot is 0 and snapshot→committed is 3, credited to the user. Membership puts the file in the right loop, but the loop still diffs against stale content.

The blob supplies that missing piece: what the snapshot would have held if one had been taken when the subagent's write was observed. It's a per-file stand-in for a snapshot.

That leads to the real alternative: take an actual shadow snapshot when the subagent finishes, instead of keeping blobs in session state. I considered it and kept the pending map, for three reasons:

1. Ordering. Claude Code fires the notification turn's UserPromptSubmit in the same millisecond as SubagentStop. If turn start wins, its attribution has already counted the lines before the snapshot exists. The pending map handles both orders, because turn start scans running subagents itself, and a snapshot can't be taken before it exists.
2. Snapshots carry turn bookkeeping. SaveStep consumes the pending prompt attribution, bumps the step count and anchors transcript offsets. The existing code deliberately keeps subagent completion out of that; there's a test asserting a completion doesn't consume the step count. A snapshot from outside a turn would interleave with the parent's turn state in ways that bookkeeping assumes can't happen.
3. Scope. A snapshot writes the listed files' current content into the shared shadow branch. While several agents are running, that also captures any concurrent human edits as of that moment. That's the same imprecision, but now baked into history rather than held per file.

So the minimum needed is both: the name, so the file is linked and walked at commit (the fix I proposed), and the content, so the walk diffs against the right state. The pending map is the content half. The bug I found is that I only wrote that half.

Right, and that's how it's built. Attribution only separates agent from human. Whether the parent or a subagent wrote a line doesn't matter; agent_lines is one number per checkpoint. So "ambiguous" files, written while several agents' calls overlapped, are equally agent work.

Splitting by agent only matters in one place: the per-task files list in task.json. The tie-break and the ambiguous/matched split exist for that list, not for attribution.

What that changes:

• Question 2 mostly goes away. files_ambiguous on task.json would only add per-task detail. If you don't need per-subagent file lists to be exhaustive, drop it.
• The bug I just found still matters, because it's on the agent-versus-human boundary. A pending file, matched or ambiguous, that isn't in FilesTouched gets credited to the human if the user commits before the next turn. That's the same agent-versus-human error #2646 exists to fix, so it should be fixed. And given your point, the fix is simply: every pending file joins FilesTouched. No per-subagent decision is involved.
• The matcher could be simpler for attribution. Credit a file to "some agent" if its timestamp falls in any agent's write window. The per-subagent tie-break only needs to run for task.json. I'd keep the current code, since it computes both from one pass and the agent-versus-human answer is already the union, but it shouldn't block anything.

The one subagent-specific thing that does matter for attribution is that background subagents work outside turns, so no snapshot captures their edits. That's a human-boundary problem, not an agent-versus-agent one, and it's why the pending baselines exist.

Shall I make the FilesTouched fix in #2646 and drop the files_ambiguous question?

Agreed, and that assumption is what makes most of today's complexity unnecessary. The current design treats human and agent edits as interleaved: it diffs at every prompt boundary, and #2646 adds per-file baselines, transcript scan positions, timestamp matching, and stand-in snapshots at commit. If they rarely overlap, attribution can rest on one question: was any agent busy when the change happened?

A simpler model:

• Busy means a turn is in progress, or a background subagent is still alive. Today a session counts as idle at Stop even while its subagents run, and that is the root of the #2646 bug.
• Busy → idle (last turn end with no live subagents, or the last subagent's stop when the parent is idle): take a full snapshot of the dirty worktree. Everything since the previous idle point is agent work.
• Idle → busy (a prompt arrives while nothing is running): diff the worktree against the last snapshot. That's human work. Today's turn-start attribution does exactly this; it only needs to skip the diff when a subagent is still alive, because then the session never went idle.
• Commit: unchanged. Snapshots hold agent work, and anything after the last snapshot is human work.

How the current bugs resolve:

• The notification-turn race disappears. A turn starting while a subagent is alive isn't an idle → busy transition, so it counts nothing as human.
• Shell-written subagent files need no timestamp matching for attribution. The snapshot at idle captures them whatever wrote them.
• #2650's untracked-file gap disappears if the idle snapshot captures all dirty, non-ignored files rather than a computed list.

What it would delete: pending baselines and their blobs, transcript scan positions, the turn-start scans, the commit-time stand-in, the "snapshot files the prompt attribution touched" patch, and most of #2650.

The timestamp matcher would remain only to fill per-task files in task.json, and it could become best-effort.

What it costs:

• A human edit made while any agent is busy counts as agent work. You're saying that's now the edge case.
• A crashed subagent that never sends its stop keeps the session busy. This needs a liveness timeout; the existing session-liveness checks could provide it.
• Concurrent sessions in one worktree would need to share the notion of busy. That's probably simpler than today.

For the open PRs:

• #2647, #2648 and #2649 are unaffected. They cover task-record fields, redaction and explain. They can proceed.
• #2646 and #2650 would mostly be replaced. I'd hold them rather than keep polishing machinery we plan to remove.

Before writing code, I'd do a short design doc that walks the model through the existing attribution scenarios and the agent-scenarios runs. It should list exactly which code and tests go away, since the current tests pin the interleaved behaviour. Then implement it as a replacement PR. Want me to start with the doc?

The plan is in. The last two sections, "What goes away" and "Open questions", depend on the code inventory, which is still running. I'll fill them when it reports.

The design doc is up: Attribution by agent-busy windows. You can edit it inline or comment, and I'll revise. It's private until you share it from the page.

Two things changed while writing it:

• Simpler than I proposed. Snapshots can happen at every agent stop. Only the human diff needs the worktree to be idle, so sessions don't need to agree on who finished last.
• Correction: there's no file rewind any more. The shadow tree feeds commit linking and carry-forward, so full snapshots affect those instead. The doc says so.

What the doc says:

• Size of the change: #2646's machinery (about 1,680 lines with tests) and turn-end file detection go away.
• Snapshots: the full-snapshot path already exists for a session's first checkpoint, so it becomes the only path. It must be built on the base tree, so files the agent reverted don't linger.
• Behaviour change: of 11 scenarios, only two change outcome, both a human editing while an agent works.
• PRs: merge #2647, #2648 and #2649. Hold #2646 and #2650, then land the model in three PRs.

Five open questions are listed at the end of the doc. One I can't answer from this repo: prompt_attributions is written to checkpoint metadata, and nothing in this repo reads it. Does the server or anything else read it?

Nothing consumes prompt_attributions outside the CLI, so it can be dropped or replaced freely.

• entire-api: one mention, in a comment in internal/ingest/checkpoint.go. It names prompt_attributions only as something that can make a session's metadata.json too large to read in one go. The ingest code doesn't parse the field.
• entire.io: the web app reads only the summary fields (initial_attribution and combined_attribution: agent_lines, human_added, human_modified and so on), never prompt_attributions.
• The other repos in ~/Work/entire/devenv: the only hits were search-benchmark result files in pgr/ that quote CLI source, and soph-entire-cli/, an old CLI fork.

One side effect worth knowing: dropping the field would also shrink metadata.json. That's the size problem the entire-api comment works around by re-reading oversized files.

I've updated that open question in the doc to "Replace it with per-edge human diffs, or drop it from metadata?". Dropping it is the simpler choice.

One entry per prompt, recorded when the prompt arrives, before the agent starts working. Each entry is a line count of changes since the previous checkpoint: what the user changed, and what the agent had added so far. The struct is PromptAttribution in cmd/entire/cli/session/state.go:789:

A real one from the integration test I debugged earlier:

That entry is the bug in a nutshell: the 3 "user" lines were the background subagent's.

How it's used: commit-time attribution sums the entries:

• the user totals become the human lines;
• the per-file maps let it subtract only the user lines that landed in agent-touched files from the agent's count;
• the per-file maps also feed the guess at whether a removal undid the user's own lines (estimateUserSelfModifications).

The cumulative agent fields aren't used in the final numbers. They're a running snapshot.

Why it bloats metadata.json:

• It's a list with one entry per prompt that saved a snapshot, so long sessions get many entries.
• Each entry's per-file maps name every file the user touched since the last checkpoint.
• The whole list is copied into each checkpoint's session metadata.json.

Under the new model: the same information shrinks to one human diff per idle→busy edge, with a per-file map. The per-file map is still needed so commit-time attribution can subtract human lines from agent files. Nothing outside the CLI reads the stored list, so it can stay internal session state rather than being written to checkpoint metadata. Only the summary initial_attribution needs to reach the server.

Yes, there's one more stored attribution field, combined_attribution. Both stored summary fields use the same Attribution type, and they're what the web app reads:

Attribution holds agent_lines, agent_removed, human_added, human_modified, human_removed, total_committed, total_lines_changed, agent_percentage, calculated_at, and metric_version (absent means the old additions-only percentage; 2 means percentage of changed lines).

The session state also has attribution-related fields that are never stored in a checkpoint:

• prompt_attributions and pending_prompt_attribution: the working copies of the per-prompt list.
• attribution_base_commit: the commit attribution measures from. Unlike base_commit, it doesn't move when the shadow branch is migrated after a pull or rebase. That keeps the agent's lines measured from where the session started.
• divergence_notice_shown: set once prepare-commit-msg has warned that the two base commits differ.

For the redesign:

• initial_attribution and combined_attribution are the output contract and keep their shape.
• attribution_base_commit is still needed for pull or rebase mid-session.
• Only prompt_attributions and pending_prompt_attribution are model-internal and can go.

I've recorded 1, 3, 4 and 5 as decided in the design doc, and added the liveness proposal there. The section is now "Open questions" with four ticked items and one open. The only open one is the liveness rule; if you agree with it, the doc is ready to implement from.

The liveness rule I'm proposing: treat a background subagent as finished when either of these holds:

• Its agent process has exited. Each session records the owning agent process (proclive), so this check is cheap and catches crashes and kills.
• It has been inactive for 1 hour. That means no new line in its transcript, and no tool call still waiting for its result. The open-call condition keeps a long build or install from being treated as dead while it runs. The 1 hour reuses the existing stuck-session threshold.

If it's too strict, real agent output written after the cutoff counts as human. If it's too loose, a hung subagent keeps crediting the human's edits to the agent until one of the two conditions trips.

I've updated the design doc with both answers, and recorded your decision to keep the matcher and remove its attribution coupling. The liveness rule is still marked "proposed" until you confirm it.

2. No. As I first wrote it, the timeout alone would have declared a subagent dead even with its process still running. The simpler rule: no timeout. A background subagent stops counting as busy at any of three points:

• its SubagentStop
• when its agent process is gone, checked at every hook, which is cheap
• when the existing session-end sweep completes its record

While the process is alive, Claude Code will still send the stop. The one gap is a stop lost to a hook failure while Claude Code keeps running. The worktree then stays busy until that session ends, so human edits until then count as agent work. I'd add a timeout only if that turns out to happen.

5. Fine to throw it away. Old state files still load: the new code simply ignores the old per-prompt fields. The one cost is for a session that's running during the upgrade:

• Human edits it recorded since its last commit get forgotten.
• Those edits are already in its snapshot, so its next commit counts them as agent work.
• That's one commit per such session, then everything runs under the new rules.

It saves the conversion code and its tests. A changelog line covers it.

Once you confirm the liveness rule, the doc has no open questions left. The next step would be the first replacement PR: busy includes live subagents, which alone fixes the notification-turn race.

Codex does fire a SessionEnd hook, which Entire already handles with a tight time budget. That matters: if the daemon breaks process liveness, session end can still close things out. Waiting for the Codex research to finish before drawing conclusions.

You're right: for Codex the process check says nothing. Since Codex #47179 made the daemon auto-start, every Codex hook runs under that one shared daemon process, and it stays alive across sessions.

What I confirmed in the Codex source:

• The daemon is on by default (daemon_auto_start is stable and enabled). One daemon serves each CODEX_HOME. The TUI is only a client over a socket; turns, tools and subagents all run inside the daemon.
• Hooks are spawned by the daemon through $SHELL -lc. So the process proclive records as a Codex session's owner is the daemon itself. The TUI never appears in the hook's ancestry.
• The daemon outlives the TUI and has no idle timeout. Turns the user sends to the background with "Run in background" keep running after the TUI quits.
• SessionEnd still fires when an idle thread unloads, 60 seconds after its last client leaves. A forced daemon shutdown (kill, crash) skips it.
• codex exec doesn't use the daemon, so its hooks still have a per-session owner process.

Today: nothing breaks. The liveness check only acts when the owner has exited, which never happens for Codex. Session-end detection falls back to the 1-hour stuck timeout and the SessionEnd hook.

For the new model: "busy until the owner process exits" can't work for Codex. The doc now proposes this order instead:

1. Completion events first:
   • SubagentStop for Claude Code
   • the child's rollout showing its turn complete for Codex (Entire already reads this)
   • the SessionEnd sweep for both
2. Process exit as a fast path, only for agents whose hooks run under a per-session process: Claude Code and codex exec. A small agent capability would declare that.
3. A 1-hour safety net for every agent: a subagent counts as finished after 1 hour with no growth in its transcript or rollout, while it has no tool call waiting for a result. That covers a killed Codex daemon, where no event ever arrives.

So the timeout comes back, as the backstop for lost events rather than the main signal. I've updated the open question and the matching row in the costs table. Does that ordering work for you?

Yes to both. Stop events are more reliable with the daemon, and the process check still catches the daemon dying. That makes the timeout and the per-agent flag unnecessary.

• Stop events: Codex hooks fire from the daemon, which is the process running the turn. Closing or killing the TUI no longer cuts a turn off, so its Stop and SubagentStop still arrive. Without the daemon, killing the TUI lost them. A Codex subagent's completion also doesn't need a hook at all: Entire reads it from the subagent's rollout.
• Process check: for Codex the recorded owner is the daemon. "Owner alive" says nothing about one session, but "owner gone" means everything the daemon ran is gone. That's exactly the forced-shutdown case where Codex skips SessionEnd.

So the rule is now the same for every agent: a background subagent stops counting as busy at its completion event, or when its session's recorded owner process is gone.

I've updated the open question and the costs-table row in the design doc. Two edge cases are listed there:

• A hook fails while its owner keeps running. The worktree stays busy until that session ends, so human edits until then count as agent work. Add a timeout only if this shows up in practice.
• The Codex daemon restarts or auto-updates mid-turn. The new daemon resumes interrupted turns, but Entire sees the old owner gone. Writes after the restart count as the human's until that thread's next hook records the new daemon as its owner.

If this rule works for you, the doc has no open questions left.

Partly. The root thread does fire a hook when it's picked up again. Resumed subagents don't. With two small rules, that root-thread hook is enough to cover the restart case.

From the Codex source:

• Restart sequence: the new daemon marks the interrupted turn as aborted in the rollout, then starts a continuation turn. That turn's input is an internal "the server restarted, continue" message, not a user prompt, so UserPromptSubmit most likely doesn't fire.
• Root thread: gets a SessionStart with source resume at the start of that continuation turn. The new daemon fires it.
• Subagent threads: skip start hooks on resume. They only fire SubagentStart for a fresh start or a fork. Their next hook is when the continuation turn ends.

The two rules:

1. Refresh the owner on SessionStart, not just at prompts. Today Entire records the owner only at prompt time. With this, the root thread's resume hook points the session at the new daemon as soon as the thread is picked up.
2. "Owner gone" pauses a subagent's busy status instead of completing its record. The record stays live, so once the owner is refreshed, the session's subagents count as busy again. If owner-gone completed the records, resumed subagents would stay "done" and their writes would count as the human's.

What's left exposed is the few seconds between the old daemon dying and the continuation turn starting, and only during daemon restarts or updates.

One thing to check when implementing: whether Entire's Codex rollout reader treats that abort marker on a subagent's old turn as "finished". If it does, it would complete the record even though the subagent continues.

The design doc's liveness item now reflects all of this; I left it open for you to tick. If this works for you, the doc has no open questions left.

If you agree, here's the order:

1. Close out the current PRs

• Merge #2647, #2648 and #2649. They don't touch attribution, have no open findings, and their CI is green apart from the approval gate. They need a human approval each.
• Convert #2646 and #2650 to drafts and mark them "superseded by the busy-window redesign". Their failing-first tests get moved into the new PRs as acceptance tests. Any test that asserts "a human edit made while an agent is busy stays human" gets flipped to assert agent, by design. I'd add a short PR comment linking the design doc, but only if you want one posted.

2. One small check first. Confirm whether Entire's Codex rollout reader treats the TurnAborted that a daemon restart writes as completion. It decides whether the rule "owner gone pauses a record's busy status instead of completing it" is enough on its own. It's a quick read plus a unit test.

3. Three replacement PRs, each leaving attribution working:

A and B are independent; C needs both. After each PR, I'd rerun the agent-scenarios single-subagent and straddle cases: the subagent lines should come out as agent lines.

4. Release. One changelog line covering the one-time skew for sessions in flight at upgrade, and the behaviour change: human edits made while an agent is busy now count as agent work.

I can start right away with the rollout check and PR A. Want me to go ahead, and should I post the "superseded" comments on #2646 and #2650?

No, assuming you mean #2647. None of the three is a prerequisite: the redesign branches from main, and none of them changes how attribution works. Merging them first only reduces rebase work later:

• #2648 (redaction): unrelated code (redact/, the Codex transcript sanitizer). No interaction at all.
• #2647 (task-record tokens, Codex completion before commit): touches lifecycle.go near the subagent-stop and post-commit paths, which PR A also edits. Expect minor textual conflicts, not logical ones. It also helps Codex under the new model: with #2647, a finished Codex child is seen as finished at commit time, so it stops counting as busy sooner.
• #2649 (checkpoint explain): changes the task record type in api/checkpoint. PR C keeps the task.json timestamp matcher and writes the files list, so C is where a conflict would show up. A and B don't touch it.

So I can start the rollout check and PR A now on a fresh branch from main, and rebase whenever those three merge. The only hard ordering is inside the redesign: C goes last, after A and B.

The redesign is up as #2651, plus a small separate fix, #2652. Each started with tests that failed on main. Lint, unit, integration and canary tests all pass on both.

#2651, attribution by busy windows:

• Busy check: a prompt records human edits only when the worktree is idle: no other session mid-turn, and no live background subagent in any session. A subagent whose session's agent process is gone stops counting without being marked finished. The owner process is re-recorded at every SessionStart, so a Codex thread resumed by a restarted daemon counts again.
• Full snapshots: every snapshot now captures the whole dirty worktree from git status, so shell writes are included. Files reverted since the previous snapshot are reset to their base content. Snapshots are also taken when a background subagent stops, and at turn ends where change detection found nothing. A snapshot is skipped when nothing changed.
• Acceptance tests: all of #2646's and #2650's acceptance tests pass, both race orders included. One flipped by design: a human edit made while a subagent is still running now counts as agent work. Edits made after it stopped stay human.
• Two guards the unit run exposed:
  • A turn whose human-edit diff failed (git status error or timeout) doesn't add its snapshot's files to the session's touched files.
  • A session's first snapshot without any prompt doesn't either.
  • Without these, pre-existing untracked files were attributed to the agent.
• One test changed meaning: TestWriteTemporary_PathNormalizationAndSkipping. Snapshots no longer take content from the agent's reported file list, so it now pins only that bad reported paths never become tree entries.

#2652, Codex aborted turns: a turn_aborted now closes the turn, the same way task_complete does. Before, one interrupt or daemon restart meant the Codex subagent was never seen as complete. Under #2651, its record would have kept the worktree busy until the session ended.

Correction to the plan I gave you: "busy" and full snapshots only fix the race together, so they're one PR. The doc's plan section now says so. The cleanup is the second and last redesign PR:

• remove prompt_attributions and the per-prompt machinery
• move the timestamp matcher to fill task.json file lists only

It needs #2649 first, because #2649 changes the task-record type the matcher writes.

Your call:

• I haven't touched #2646 and #2650. #2651 supersedes them, so they can be closed once it merges.
• The PR descriptions link nothing private. The design doc stays private until you share it from its page.

I'm watching #2651 and #2652 for review comments and trail findings in the background.

I've addressed everything raised on #2651 so far: seven review comments and one trail finding, all in two commits. #2652 has no comments or findings yet. Lint, unit, integration and canary tests pass.

The review comments:

1. A race the PR was meant to close (high): when a background subagent stopped, its record was marked complete before its snapshot was taken. A prompt landing in between saw an idle worktree and counted the subagent's edits as human. The snapshot now comes first, while the record still keeps the worktree busy.
2. Unreadable session store: this counted as idle. It now marks the human diff as incomplete and skips it.
3. Unknown process liveness: a live record whose owner process couldn't be checked kept the worktree busy forever. It now counts only while its session interacted within the existing 1-hour stuck threshold, the fallback the owner contract already names. A new test covers this.
4. Snapshot option docs now describe full-worktree snapshots.
5. Shared worktrees: a snapshot no longer adds files another live session in the worktree already touched to this session's FilesTouched. A test failed on the old behaviour ([mine.txt other.txt]).
6. Sessions with no recorded worktree are skipped by the busy check, matching how sessions are matched elsewhere. Also tested.

The trail finding: Copilot CLI subagents complete through a separate code path, which skipped the new snapshot. The snapshot now runs before both completion paths. Finding resolved.

The first fix is a reordering whose interleaving isn't directly tested; the existing race-order tests still pass. I'm watching #2651 and #2652 in the background.

Nothing new to act on.

• The 4 comments: they're the same seven review comments as before. All were posted against the first commit at 12:26–12:27 UTC; GitHub just re-anchors the ones whose lines still exist to my latest commit. All seven are fixed in the two commits I pushed.
• Trails: #1476 (#2651) and #1477 (#2652) have no open findings.
• The watcher: it stopped because a trail's status changed, not because of a new comment.

I fixed both findings, with new failing-first tests, and pushed them to #2651. Lint, unit, integration and canary tests pass.

1. Lost turn tokens (P2): fixed. A turn where change detection found nothing now goes through the normal turn-end path, which computes and records the turn's tokens. It snapshots only if the worktree actually changed (a shell edit to a pre-existing untracked file). If nothing changed, it ends the turn the old way, including the out-of-band token handling for agents like Antigravity. New test: a turn where a shell command appends to a pre-existing untracked file now ends with a checkpoint carrying its 200 input and 50 output tokens. Before the fix, it ended with none.
2. The "no resurrection" check racing cleanup (P2): fixed. The check now happens inside SaveStep under its own state lock, via a new existing-session-only option. Snapshots taken when a subagent stops use it. SaveStep then never recreates a missing session and never writes to an ended one. New test: no state file appears for a missing session, and an ended session gets no snapshot.

One side effect of the first fix: turns that changed nothing now also go through the normal path, which computes token usage. That's slightly more work per idle turn, but no checkpoint is written for them.

These two findings weren't on #2651's trail, so there was nothing to resolve there.

I fixed that P2 on #2651, but my first push of the fix failed lint. A follow-up commit fixes it, and the branch is now clean, with all tests passing.

The fix: a Stop where change detection found nothing now also refuses to create or write to a session that's missing or ended. That's the same protection subagent-stop snapshots already had. An ended session counts as "nothing to snapshot", so the turn ends without a checkpoint. A new test reproduces your case (an ended session, a changed pre-existing untracked file, a late Stop). It failed before the fix with StepCount 1 and passes now with 0.

The lint slip: my command didn't stop on lint errors, so the fix went up while SaveStep was over the maintainability limit. I moved its token-accounting block, unchanged, into a helper (accumulateStepTokenUsage) and pushed that as a separate commit. Lint is clean, and the strategy and CLI unit tests plus the integration tests pass. The canary passed on the fix commit itself; I didn't rerun it after the refactor.

I fixed both findings and pushed them to #2651. Lint, unit, integration and canary tests all pass, and the push only went out once lint was clean.

F1 (Medium) — fixed as you suggested. Every snapshot now runs its changed files through the same git check-ignore --no-index filter as before. A tracked file that matches .gitignore stays at its base content. If an earlier snapshot already captured such a file, the existing reset step puts it back to base content. main's first-checkpoint path never applied this filter, so this also closes an older gap on that path.

F2 (Low) — your regression test is in ephemeral_full_snapshot_test.go, unchanged. Before the fix it failed with the secret in the snapshot (actual: "PASSWORD=REDACTED"); it passes now.

One edge case I didn't change: if git check-ignore itself fails, the filter excludes every file. The reset step then puts every previously captured file back to base content, so that one snapshot would show no agent work. That keeps the secrets safe, but attribution for that step would be wrong. I could instead skip the snapshot when the filter errors, but the filter currently can't report a failure, so that's a small refactor. Want me to do it?

Seven PRs are open, and none has merged yet. Every one is blocked only on a required review: no open findings, and the code checks passed when I last looked.

Ready to merge:

To close once #2651 merges:

I haven't commented on, drafted or closed #2646 and #2650. That's your call.

Still to write: the cleanup PR that removes the old per-prompt attribution machinery and prompt_attributions. It will also keep the timestamp matcher for task.json file lists only. It needs #2649 and #2651 merged first.

I resolved all 7 review threads on #2651 without commenting. Each one is fixed in a commit already pushed to the PR, so #2651 now has no unresolved threads. The last few problems you passed me (turn tokens, late Stop, gitignored files) were never posted on GitHub, so they had no threads to resolve.

Yes, the issue's bug is fixed on #2651 now. It wasn't before I checked: my new snapshot at subagent stop failed in exactly the ordering the issue describes.

Why it failed: the subagent-stop snapshot needs the session's metadata directory, which normally gets created at the first turn end. In #2653 the child finishes before the parent's turn has ever ended, so the snapshot errored (only a warning in the log). The mid-turn notification prompt then diffed against the base commit and counted the child's line as human. That's the issue's run 2, line for line. The fix creates the directory before snapshotting.

Tests: I added #2653's orderings as tests:

• commit right after the child stops (no parent Stop)
• the notification arriving mid-turn, then the commit
• the same, with a parent edit earlier in the turn

The mid-turn ones failed until the fix and pass now. The rest passes too: unit, integration, canary and lint. I also rewrote one older test whose invariant no longer holds: a subagent stop before the first turn end now uses up a step. It now checks what still matters: the snapshot holds the user's pre-existing work, and the transcript anchor is still set.

Covered by #2651:

One decision for you: I tried a further rule and backed it out. The rule: a prompt arriving while its own session is still mid-turn (for example a queued message) skips the human diff. In #2653 the subagent's snapshot already covers the agent's edits. Without a subagent, such a prompt still counts the agent's unsnapshotted edits as human, which is a pre-existing bug on main. The rule fixes that, but if an agent's Stop hook is ever lost, it would suppress human diffs in that session for as long as you keep prompting. Want it, maybe as its own PR?

Should I add "Fixes #2653" to #2651's description, so the issue closes on merge?

I shelved the mid-turn prompt issue as #6M3X4Y7, priority 3, seen once. No checkpoint could be linked: entire checkpoint create --json failed with "unknown flag: --json". The entire build on your PATH doesn't have that flag.

The item is titled "Mid-turn prompts count the agent's own edits as human". It records the candidate fix, why it was backed out (the lost-Stop risk), the test that reproduces it, and the three strategy tests that would need updating.

The shelved item #6M3X4Y7 is now linked to a checkpoint of this session: 01M44AZJ0SRDKFC0T8Q0HNKFXM. I created the checkpoint with entire checkpoint create and attached it with entire priority link, so the sighting count stays at 1. entire priority explain 6M3X4Y7 will reopen this session's log from the item.

Yes, your point about lines 1359–1365 holds, and it's in the rewrite I pushed to #2647. Non-Codex sessions were already skipped with continue, so the lazy Codex lookup only ever ran for Codex candidates. Loading it once before the loop behaves the same. The function now collects its candidates first, loads the Codex agent once if there are any, then refreshes them.

The trail had six open findings on #2647, all of which I fixed and resolved:

1. High: the refresh missed sessions that PostCommit condenses. It picked sessions with its own rule ("this worktree, any trailer"), unlike PostCommit. Sessions linked through a sibling or parent worktree, or as guests committing from another worktree, still had their child records stored as unfinished.
   • PostCommit now runs a hook right before condensing, with exactly the sessions it is about to condense.
   • The post-commit command registers the Codex refresh in that hook.
   • If the refresh changed anything, PostCommit re-reads the sessions before continuing.
   • That removes the worktree filter and the trailer check.
2. Low: inherited trailers triggered the refresh. Fixed by the same change: the refresh now runs only after PostCommit's own trailer decision.
3. Low: the doc comment was misplaced. The new function sat inside refreshCodexInventory's comment; it's now above it.
4. Low: misleading name. It's now refreshCodexInventoriesBeforeCondense.
5. Low: an empty subagent transcript was stored as exactly zero tokens. It now reports no usage.
6. Low: no tests for the skip rules. There's now a test for which sessions get refreshed (Codex only, with running subagents, not ended). The worktree and trailer rules are now PostCommit's own, and a separate test pins that the hook sees exactly the sessions PostCommit condenses.

Each new test failed before its fix, except the candidate-selection test, which pins rules that were already in place. Lint, unit, integration and canary tests pass.

One gap: the high finding also suggested an integration test that commits from a second worktree. I didn't write it. The guarantee comes from the hook receiving exactly PostCommit's session set, which the strategy test pins.

#2647's GitHub review threads (unreadable parent, performance, token assertion) are fixed in earlier commits but not marked resolved. Should I resolve them like I did on #2651?

Not much, probably under an hour. Most of the pieces exist:

• Fixture: the Codex scenario the existing test uses (newCodexSubagentScenario) already sets up the session, the child rollout and the provisional stop.
• Making the session cross-worktree: set its WorktreePath to a second worktree, created with git worktree add (which worktree_test.go already does). The commit happens in the test's main repo, so worktree matching alone won't select the session.
• Getting it guest-linked: PostCommit also links the session whose recorded owner process is an ancestor of the hook process. In a test, the hooks run as subprocesses of the test process, so recording the test process (proclive.IdentityOf(os.Getpid())) as the session's owner makes PostCommit link it as a guest.
• Assertion: same as the existing test. The stored task.json has completed_at and the child's files. On the old filter it would fail with the record still unfinished, since the old filter skipped sessions from other worktrees.

Risks:

• The ancestry match might not work in the harness. For example, the hook subprocess might sit under something proclive doesn't treat as transparent, and then the guest link wouldn't happen. I'd find out in the first run.
• prepare-commit-msg must stamp the trailer for a guest-linked session. The existing Codex test gets a trailer through task-record content, so it probably will.

The fallback path (same repo, different worktree, picked by the single-worktree or 15-minute recency rule) is harder to set up deterministically. I'd skip it: the guest case alone proves the refresh follows PostCommit's session set rather than its own filter.

Want me to write it?

The integration test worked on the first try, and it's pushed to #2647.

TestCodexSubagent_GuestLinkedCommit_CompletesTaskRecord sets up a Codex session that lives in a sibling git worktree. It's linked to the commit only through process ancestry, by recording the test process as the session's owner. The test then checks that the stored task.json shows the subagent as completed, with its files.

It catches the bug the review flagged. With the old "only sessions in this worktree" filter put back temporarily, the test fails: the record is stored unfinished. With the current code it passes. The Codex integration tests and lint pass too.

As planned, I didn't cover the other cross-worktree route, where a session is picked up because it's the only or most recently active one in the repo. It goes through the same hook.

Not fully. The earlier fix only covered part of the medium finding. The rest is fixed now, and the low one is the known gap.

Medium (fixed and resolved). My earlier fix only kept a session from claiming files already in another session's FilesTouched. The finding's ordering still lost work:

1. Session A shell-writes foo.go.
2. Session B's turn ends first and claims it.
3. A's snapshot is then compared with B's, which already holds A's content, so A never claims foo.go.

Now each session measures what changed since its own previous snapshot, not since the newest one on the shared branch.

The first version of the new test still failed, and that exposed a second gap. When A's worktree exactly matched B's latest snapshot, the write was skipped as a duplicate before A's claims were recorded. A skipped snapshot now still records the session's claims and takes over B's snapshot as A's latest.

If both sessions touched a file in the same window, both claim it. That only over-links, and the lines count as agent work either way. A session's very first snapshot still leaves out files other sessions already claimed.

The new test reproduces the finding's exact ordering and failed before the fix. Lint, unit, integration and canary tests pass.

Low (not fixed): a subagent that dies without a completion signal while its agent process keeps running. This is the limitation we accepted in the design doc. The finding itself says it isn't blocking and isn't detectable in general. Codex's part of it is #2652. The rest needs per-agent work: first check whether interrupting a Claude Code background subagent fires a SubagentStop. It's still open on the trail. Want me to shelve it with those steps and dismiss the finding as tracked?

#2651's conflicts are resolved and pushed. GitHub now reports it mergeable, blocked only on review.

#2651: while it was open, main gained #2647, #2648, #2649, #2652 and #2656. I merged main into the branch rather than rebasing, so no force-push was needed. The only conflict was in cmd/entire/cli/lifecycle_test.go, where both sides had added tests at the end of the file; I kept all of them. Lint, unit, integration and canary tests pass after the merge.

The other open PRs:

#2647, #2648, #2649 and #2652 have merged.

I'd close #2646 and #2650 once #2651 merges, since their tests already live in #2651. If you'd rather keep either one alive, I'll resolve #2646's conflicts. Want me to close them after #2651 lands, and post the "superseded" comment you held off on earlier?

#2651 had two new findings, both about one regression from my previous fix. Both are fixed with a test that failed first, pushed and resolved on the trail. There are no open review threads, and the only failing check is the approval gate.

The regression. My last fix measured each session's file claims from its own previous snapshot. When two sessions take turns in one worktree, that window spans the other session's whole turn. So B claimed A's a.txt, got linked to A's commit, and the file's agent lines counted twice.

Why not the suggested fix. The trail suggested excluding other sessions' files on every snapshot. That would bring back the previous finding: a session losing a file it shell-wrote when the other session claimed it first. Both orderings leave the same evidence in the snapshots. What differs is whether this session was busy when the other session snapshotted.

What I did instead. A session's claims window now starts at the newest snapshot when its turn starts, and each of its own snapshots moves it forward.

• Taking turns: whatever another session snapshotted while this one was idle is outside its window.
• Working at the same time: whatever this session wrote while the other snapshotted is still inside it. A file both sessions changed while both were busy is claimed by both.

Tests. The new test follows the reported B/A/B/A/B sequence with real turn starts. It failed with both sessions claiming both files, and now B ends with only b.txt and A with only a.txt. The concurrent-session test from the previous round still passes. Lint, unit, integration and canary tests pass, and attribution.md describes the rule.

Still open on the trail: the low finding about a subagent dying without a completion signal while its agent process keeps running (01M461TS56SV). It's the known, non-blocking limitation. I can shelve it and dismiss the finding as tracked if you like.

I shelved the finding as #2RT1QG69 (priority 3, seen once), linked to checkpoint 01M46AP575Y1G0XGK032XQVJ34. Then I dismissed it on #2651's trail as tracked, with a note pointing to the shelved item.

The shelved item records the three follow-up steps:

1. Check which agents can end a background subagent without a completion signal. Start with interrupting a Claude Code background subagent.
2. Add a completion signal per agent where one is missing. Codex's turn_aborted is already handled by #2652.
3. Optionally, log when a prompt skips the human diff because a subagent record has stayed live for a long time.

#2651's trail now has no open findings.

The E2E Tests workflow (real agents) failed on the #2651 merge commit. It passed on the commit before, and the other workflows pass. Finding which tests failed:

I've opened PR #2662 to fix the broken main: https://github.com/entireio/cli/pull/2662

What broke: after #2651, a shadow branch was left behind after a commit. That made TestDirtyWorkingTree and TestMidTurnCommit_DifferentFilesThanPreviousTurn fail for opencode, factoryai-droid, antigravity and cursor-cli.

Why: when the agent reports no file change, the turn end still takes a fallback snapshot. A mid-turn commit deletes the shadow branch and clears the step count and the pending prompt diff. The turn-end snapshot then has no human diff to compare against, so it can't claim anything as agent work. But the human's uncommitted changes still differ from HEAD, so it was written anyway. That recreated a shadow branch holding only human changes.

Fix: in SaveStep (cmd/entire/cli/strategy/manual_commit_git.go), a fallback snapshot is now skipped when the session has no human diff for its window.

My first version was broader: it skipped any fallback snapshot that held no agent work. That broke REDACTED. With a pending prompt diff kept and its snapshot skipped, the user's 2 lines were counted twice at commit, so I narrowed it.

Tests:

• The new integration test REDACTED fails on main and passes with the fix.
• mise run check: lint is clean and the integration suite passes. Two unit tests failed, neither caused by this change:
  • TestProbeConfigDir_AsksClaude passed when rerun alone; it had hit a 5s timeout under load.
  • TestOpenCodeSeedRepoPlantsDeps needs the opencode dependencies set up locally.
• I did not run the real-agent E2E tests.

There's no trail for #2662 yet, so I couldn't check findings. I'll look once it exists.

The PR was already open from the last step: https://github.com/entireio/cli/pull/2662

I've started the full E2E Tests workflow on its branch, soph/fix-shadow-after-midturn-commit, for all agents: https://github.com/entireio/cli/actions/runs/37347194617

It's still running. When it finishes, I'll check whether TestDirtyWorkingTree and TestMidTurnCommit_DifferentFilesThanPreviousTurn pass for opencode, factoryai-droid, antigravity and cursor-cli, the four agents that failed on main, and report any job that fails.

My first E2E run on the branch was cancelled before any results came in. All E2E runs share one queue that cancels the older run, so a push to main at 17:19 cancelled ours.

Starting again right away would have cancelled main's run instead. So I'm waiting for main's run (37347543462) to finish, then I'll start the branch run again and report the results.

PR #2639 (native-search-repo-routing) was merged into main. It's the only change since #2651 and has three commits, all search fixes:

• The default search scope now comes from the origin remote's host (GitHub or another forge), instead of a check that only knew GitHub.
• When the default scope can't be resolved, the error now says why the origin remote couldn't be resolved.
• Semantic lookups keep the forge, and the search TUI keeps the scope it started with.

None of it touches checkpoints or attribution. It doesn't fix main's E2E failures, so main's run (37347543462) will likely fail the same way.

I've rebased the branch onto main (8c0d19db9c), pushed it, cancelled main's run 37347543462 and started a new E2E run on the branch: https://github.com/entireio/cli/actions/runs/37348437798

I pushed before linting the rebased tree, so I ran lint afterwards: 0 issues. The run was still queued at last check. I'll report which jobs fail, if any, when it finishes.

The E2E run on the branch fixed the shadow-branch failures: TestDirtyWorkingTree and TestMidTurnCommit_DifferentFilesThanPreviousTurn now pass on every agent. One droid test still failed, TestFactoryCommittedCheckpointExcludesPreExistingUntrackedFiles. I traced it to a second regression from #2651, pushed a fix to #2662, and started a droid-only E2E run on it.

What broke: droid runs its Worker as a separate session. When the Worker finishes, Entire adds it to the parent session as a task record but takes no snapshot.

• Since #2651, the parent's turn end can snapshot first, because the test's untracked human file differs from HEAD. That creates a shadow branch before the Worker has written its file.
• At commit, a new file only counts as the session's work if its content is in the shadow branch. The Worker's file isn't, so nothing goes into the commit's checkpoint.
• Before #2651 there was no shadow branch at that point, and the check fell back to matching file names, which passed.
• This test passed on main at 14:52 and has failed on every run since #2651 merged.

Fix: when a Worker session ends, Entire now snapshots the worktree under the parent session before recording the task, as it already does for every other subagent stop. It's in saveSubagentSessionTaskStep in cmd/entire/cli/lifecycle.go.

Tests:

• The new TestFactoryDroidWorkerFileCommittedAfterParentSnapshot reproduces the failure without the fix and passes with it.
• I changed an existing test, TestFactoryDroidWorkerSessionBecomesTaskCheckpoint. It asserted no shadow branch exists after a Worker's turn, which the new snapshot breaks. Its comment says the real concern is shadow data written under the Worker's own session, so it now checks exactly that. I confirmed it still fails if the snapshot is written under the Worker's session.
• mise run check passes except TestOpenCodeSeedRepoPlantsDeps, which needs the opencode dependencies set up locally.

I also added the droid Worker snapshot and the skip from the first fix to docs/architecture/attribution.md. The PR is now titled "Fix E2E regressions from busy-window attribution (#2651)", and its description covers both fixes.

The droid-only E2E run is still going: https://github.com/entireio/cli/actions/runs/37351725066

The droid-only E2E run passed on the latest commit (f84b8fe): https://github.com/entireio/cli/actions/runs/37351725066

So both #2651 regressions are fixed on #2662. The earlier all-agent run already passed TestDirtyWorkingTree and TestMidTurnCommit_DifferentFilesThanPreviousTurn everywhere, and this run passes droid, including TestFactoryCommittedCheckpointExcludesPreExistingUntrackedFiles. The only change since that all-agent run is in droid's Worker path, so only droid was re-run.

The PR's trail is 1486. It's still reviewing and has no findings yet, so I'll check it again once the review lands.

gtrrz-victor opened a revert of #2651, PR #2660, about an hour ago. It's still open. If #2662 merges instead, #2660 can be closed; if the revert lands first, #2662 would have to be redone on top of a re-land of #2651.

No, neither comment is resolved. #2662 has two open review threads: one from Cursor Bugbot (medium severity) and one from Copilot. They describe the same gap, and it's real. Trail 1486 has no findings.

The gap. My first fix skips a stop snapshot when the session has no prompt diff for the current turn. But that state also happens for an ordinary reason: a mid-turn commit clears the step count and the prompt diff. So after the commit, a snapshot is skipped even when the agent changed something:

• A background subagent finishing after the parent's mid-turn commit. Its snapshot is skipped, so its new files are in the session's FilesTouched but not in any shadow branch. At commit, the overlap check doesn't find their content, and the commit gets no checkpoint. That's the same failure I just fixed for droid, coming back through a different path. This is the serious case. Neither E2E run covered it.
• The agent edits a file after its commit without the transcript showing it, for example appending to an untracked file through a shell command. The turn-end snapshot is skipped, and the next prompt counts that edit as the user's.

Before my change, main wrote those snapshots. They claimed nothing for the agent, but the content was in a shadow branch, so neither problem happened.

Why the skip can't decide. It can't tell "only the human's leftover changes" apart from "the agent changed something after its commit." After condensation there's nothing to compare against except HEAD.

Recommended fix: when a mid-turn commit condenses a session that is still mid-turn, record a snapshot of the remaining uncommitted changes as an unreferenced commit, with no shadow branch, as that session's starting point for the next stop.

• A later stop compares the worktree against that starting point.
  • If nothing changed, it's skipped and no shadow branch is left, so the E2E tests still pass.
  • If something changed (a subagent's file, a shell edit), the snapshot is written and the change is claimed for the agent. The worktree is busy for the rest of that turn, so that's correct.
• The humanDiffUnknown skip goes away.
• Cost: one extra snapshot in post-commit, and only for sessions that are mid-turn when the commit happens.

A smaller alternative is to apply the skip only to the turn-end snapshot and not to subagent stops. That fixes the lost-checkpoint case but leaves the shell-edit one.

Should I implement the recommended fix on #2662, with regression tests for both cases?

It changes how the code behaves, not just the tests.

What changes:

• In post-commit, when a session that is mid-turn gets condensed, Entire snapshots the remaining uncommitted changes as a commit with no branch pointing at it. It saves that commit's hash in the session state as the session's starting point.
• SaveStep compares a stop's worktree against that starting point instead of HEAD. If nothing changed, it writes nothing. If something changed, it writes the snapshot and claims those files for the agent.
• The humanDiffUnknown skip I added in the first fix goes away.

What users would notice:

• A background subagent that finishes after its parent's mid-turn commit gets its work checkpointed again. With the current PR, the next commit of those files gets no checkpoint.
• An edit the agent makes after its commit that the transcript doesn't show, such as a shell append, counts as agent work instead of the user's at the next prompt.
• The cost is one extra snapshot during the commit hook, only when a session is mid-turn at commit time.

The tests are two new integration tests that fail without the change, one per scenario above.

I agree with rolling back. Each patch so far has fixed one interaction and opened another. All three problems come from the same cause: full-worktree snapshots don't fit how shadow branches are created and deleted, or the commit-time content check. That needs a fix in the design, not more patches on main.

The revert is ready: #2660 (the revert gtrrz-victor opened) passes CI and merges cleanly, and is only waiting for an approval. Approving and merging it is yours to do.

What the re-land has to handle: I recorded these three regressions in memory so they carry into the redesign. The tests from #2662 can become acceptance tests for it.

1. Shadow branch left after a mid-turn commit. When the worktree has human changes, the turn-end snapshot recreates a shadow branch holding only those changes. #2662 has a test for this (REDACTED).
2. Droid Worker stops take no snapshot. The commit's content check then misses the Worker's new file, and nothing goes into the checkpoint. #2662 has a test for this (TestFactoryDroidWorkerFileCommittedAfterParentSnapshot).
3. No starting point after condensation except HEAD. Leftover human changes can't be told apart from agent edits made after the commit. The re-land needs a snapshot of the leftover changes taken at the commit. #2662 has no test for this; the re-land needs new ones for a subagent finishing after a mid-turn commit and for a shell edit after the commit.

Should I turn #2662 into a draft and keep the branch as the starting point for the re-land, or close it?

Yes. All four findings are on the revert PR #2660, and each describes behavior main already had before #2651, which the revert brings back. All four threads are marked resolved, and you've approved #2660. The trails for #2651, #2660 and #2662 have no findings of their own.

1. The first checkpoint skips the gitignore filter. I checked the code from before #2651: the first checkpoint takes every file git status reports without the git check-ignore filter, while later checkpoints do filter. A tracked file that matches .gitignore and has local secrets in it, such as .env, gets copied into the shadow branch, which can later be pushed. This is the only security-relevant one, and it doesn't depend on the attribution redesign. After the revert I can bring it back as a small standalone fix.
2. Later checkpoints only include files the transcript named. A file the agent changes through a shell command is left out, and the next prompt counts that change as the user's.
3. No snapshot when the turn reports no changed files. Same cause as 2: a shell edit is missed and later counted as the user's work.
4. No snapshot when a subagent stops. A subagent's file that the parent commits in the same turn gets counted as the user's work. This is the bug reported in issue #2653.

Numbers 2 to 4 are what the busy-window redesign set out to fix, so they belong to the re-land. Number 1 is worth fixing now, separately.