I've added the 0.11.4 entry, dated 2026-10-05, to the top of CHANGELOG.md. It isn't committed yet.

What it covers: the 34 PRs merged since v0.11.3. I compared against v0.11.3 rather than the newest tag, because the newest tag is a nightly build.

• Breaking changes and migrations:
  • entire repo mirror get is removed. entire repo view is now the one place a repository is shown, and it no longer accepts a repo ULID or a bare name with --project (#2547).
  • A trailing .git is no longer treated as part of a repo name, which reverts the 0.11.3 rule (#2616, #2630).
• Added:
  • entire checkpoint explain now shows subagent tasks and token details.
  • A hidden entire checkpoint create command.
  • entire agent-help hands off to an installed plugin's own help.
  • entire trail create --repo works without a local clone.
  • Grant lists show account display names.
  • entire repo mirror add suggests how to repoint an existing checkout at the mirror.
  • A rejected checkpoint_remote is now reported to the user.
• Changed:
  • Attribution now depends on whether an agent is busy: edits made while another session or a background subagent is working aren't recorded as human (#2651).
  • Org names resolve against your own orgs only.
  • Google handles as printed by entire auth status now work as grantees.
• Fixed: 14 bullets. The main ones are reviewer isolation (#2598), Claude Code's StopFailure ending the turn (#2656), honoring each agent's relocated home directory (#2375), and four subagent-capture fixes combined into one bullet.
• Housekeeping: 4 small items.
• No Thanks section: every contributor is internal. The one GitHub noreply account (toothbrush) also commits as paulo@entire.io.

Two calls you may want to change:

• I listed #2632 even though entire checkpoint create is hidden.
• I put #2651 under Changed rather than Fixed, because it changes how attribution works and gives up some accuracy on purpose.

I took the hidden entire checkpoint create bullet (#2632) out of the 0.11.4 entry, and #2632 no longer appears anywhere in CHANGELOG.md. I also saved a memory so future changelogs leave out hidden commands.

I opened the PR: https://github.com/entireio/cli/pull/2661. It adds the 0.11.4 changelog entry without the hidden entire checkpoint create.

• Pre-commit checks: formatting and lint passed, but the full mise run check failed on two tests that have nothing to do with the changelog edit:

  • TestPlugin_SpawnsHooksUnderNode failed because mise has no Node version set on this machine.
  • TestGitMetadataTraversalHasCanonicalOwner failed because it also scans leftover agent worktrees under .claude/worktrees/ that aren't part of the repo.

  I committed despite the failing check because this PR only changes CHANGELOG.md.

• Trail findings: I checked right after pushing, and no trail exists for the PR yet, so there are no findings to look at. Someone still needs to run entire trail finding list 2661 once the trail appears.

I merged origin/main into changelog-0.11.4 and changed the 0.11.4 entry for the four PRs that came in. These changes are local only: the changelog edits aren't committed, and the merge commit hasn't been pushed to PR #2661.

What changed in the entry:

• Removed the #2651 attribution bullet. #2660 reverted #2651 in case it caused E2E failures, so that change won't ship in 0.11.4.
• Changed: added that entire trail delete now always fails and points to entire trail update --status closed, because the server no longer allows deleting trails (#2666).
• Fixed: added that entire search now works from an Entire-native clone (#2639).
• Fixed: added that entire session adopt now checks subagent transcript paths before copying them into checkpoints (#2655).

Hidden commands: I deleted the saved rule and put the hidden entire checkpoint create bullet (#2632) back under Added. If you meant to drop the rule for future releases but still keep #2632 out of this one, I'll take it out again.

Should I commit and push this to PR #2661? Before pushing I'll run lint and then check the trail's findings afterwards.

I pushed the updated changelog to PR #2661.

• Push: my first push was rejected because Stefan had already pushed a commit to the branch removing the reverted #2651 bullet. I had removed the same line, so I merged his commit without conflicts and pushed again.
• Checks: lint passed with 0 issues on the current tree.
• Trail findings: the PR's trail is 1485, not 2661, so my earlier lookup was using the wrong number. It shows no findings right now, but it's still in "reviewing", so findings may appear once that review finishes.

External contributions: none in this release. All 10 commit identities since v0.11.3 belong to the team:

• Seven @entire.io addresses: Alex, Alisha, Hidde, Peyton, Stefan, and your two.
• paul (toothbrush) is Paulo Gomes, who also commits as paulo@entire.io.
• computermode has no @entire.io email in git history, but is a member of the entireio GitHub org.
• Victor <gtrrz.victor@gmail.com> is your personal address.

So the entry still correctly has no Thanks section.

Copilot left two suggestions on PR #2661. Both were right, so I fixed both and pushed.

1. Wrong release for the .git rule: the 0.11.4 entry said the old rule came from 0.11.3. It actually came from #2557 in 0.11.2, so the bullet now says 0.11.2.
2. Missing upgrade step for #2656: that PR says existing installs need to re-run entire enable to get the new StopFailure hook. The bullet now says so, and notes that entire doctor reports the Claude Code hook config as outdated until then. I checked that entire doctor does run that hook-config check.

I replied on both Copilot threads, but did not mark them resolved. I also updated the PR description, which still said the hidden entire checkpoint create was left out.

I didn't re-run lint, because only CHANGELOG.md changed since the last lint pass. The trail still shows no findings.

I said there were no findings because I ran entire trail finding list without flags. By default it only shows findings on the latest pushed code. This finding was made on an earlier push of the branch, so the default filter hid it. Running it again with --freshness any shows it. I should have used that flag after each push.

The finding is wrong about main right now. It says #2598 (stopping reviewers from loading the reviewed checkout's agent config) was reverted on main in commit 5a5c807d7. That revert isn't on main. It's only on peyton/review-trust-gate, which belongs to the still-open PR #2671 ("Restore full reviewer config; ask before reviewing someone else's code"). On current main, the #2598 bullet in the changelog is accurate.

It is still a real risk for the release. If #2671 merges before 0.11.4 is cut, the #2598 bullet will describe behaviour that no longer exists. It would then need to say that reviewing someone else's code asks for approval first.

How do you want to handle it?

1. Keep the #2598 bullet and resolve the finding with a note that the revert is only in #2671, which hasn't merged.
2. Wait for #2671, then rewrite the bullet to describe the approval step.
3. Remove the #2598 bullet now, since it may not ship as written.

I ran it without the flag because I copied the command straight from CLAUDE.md and didn't look at its options first. That was my mistake: CLAUDE.md tells agents to run entire agent-help <command> before using a command, and I only did that after you pointed out the missing finding. Even so, the docs and the command made this mistake easy to make.

Where the docs and the command could be better:

1. CLAUDE.md line 56 says to run entire trail finding list <n> after every push. It never mentions that the default hides findings recorded on earlier pushes, so following it word for word misses them. Since the rule is "not done until findings are clear", that's the wrong default for this check. It should say --freshness any, or tell the reader to check older pushes as well.
2. <n> doesn't say which number. I passed the PR number (2661) and got no trail "2661" found, but the trail is 1485. It should say "trail number", or point to --branch or the current branch's trail instead.
3. The "No findings found." message hides what it filtered out. The JSON from the same request reports "Open": 1, "OpenHigh": 1 while the text output says there's nothing. The command could add a hint like "1 open finding on older pushes hidden; use --freshness any".
4. The filter and the finding's own label disagree. The hidden finding has staleOutcome: "current", yet --freshness current (the default) leaves it out. The CLI just passes the value to the server as stale=current (trail_review_cmd.go:702), so the server seems to filter on whether the finding is on the latest push, not on staleOutcome. The help text "Filter code-version freshness" doesn't explain that. Either the server filter or the help text should change so they match.

I can fix items 1 and 2 in CLAUDE.md and item 3 in the CLI. Item 4 depends on how the server is meant to handle findings it hasn't stale-checked yet, which is a product decision.

I sent the docs fix to the improve-claude-docs session. It reached that session's inbox but hasn't been read yet. I asked it to:

• update the trail-findings rule in CLAUDE.md to use --freshness any;
• make clear that <n> is the trail number, not the PR number;
• run the size check that keeps CLAUDE.md under its 20 KiB limit.

The two CLI problems, the misleading "No findings found." message and the confusing --freshness help text, went to it as suggestions only. It's not to implement those unless you ask.

The changelog is still waiting on your decision about the high finding on the #2598 bullet. Main still has #2598, but if PR #2671 merges before the release, that bullet will be wrong. The options are:

1. Keep the bullet and resolve the finding with a note.
2. Wait for #2671 and rewrite the bullet to describe the approval step.
3. Remove the bullet now.

I dismissed the high finding rather than changing the changelog, because its claim is wrong. The revert commit 5a5c807d7 is not on main. It's only on peyton/review-trust-gate, the branch of PR #2671, which is still open. So on main, the #2598 change ships as the changelog describes it.

The dismissal note says that if #2671 merges before 0.11.4 is cut, the #2598 bullet will be rewritten to describe its approval step. Checking findings from every push now shows none.

I also saved a reminder to check whether #2671 has merged before the release. If it has, the #2598 bullet needs to say that reviewing someone else's code asks for approval first (--trust-target, --show-config).

I merged the latest main into the changelog branch, updated the 0.11.4 entry and pushed it to PR #2661.

• One new PR on main: #2667, which fixes entire dispatch failing in a checkout whose origin is an Entire-native repo. It's the same bug #2639 fixed for entire search, so I combined them into one Fixed bullet. That bullet now also says the entire dispatch setup wizard finds native checkouts.
• #2671 is still open, so the #2598 reviewer bullet stays as it is.
• Checks: lint passed with 0 issues on the merged tree.
• Trail findings: listing findings from every push, older ones included, shows none so far. The trail is still running its review of this push, though, so findings may still appear. I can check again once it finishes.

Yes, there was one new low-severity finding, and I've fixed and resolved it. There are no open findings now.

• New finding: the #2625 bullet quoted the old push failure as unexpected disconnect. The commit names it as "remote end hung up". The #2625 PR description mentions both messages, so I changed the bullet to quote the remote end hung up unexpectedly. I pushed that and resolved the finding with a note.
• The earlier high finding about #2598 is still dismissed.

The trail is reviewing the push I just made, so more findings could still appear. I can check again once it finishes.

I'm waiting for the trail to finish reviewing the last push, then I'll check the findings. It checks every 20 seconds for up to 20 minutes.

The check is running again. It's waiting for trail 1485 to finish reviewing, then it will list findings from every push.

I fixed the new finding and resolved it.

• Date: the 0.11.4 entry was dated 2026-10-05, but #2667, which the entry includes, merged on 2026-10-06. I changed the date to 2026-10-06, pushed it, and resolved the finding with a note.
• Open findings: none right now.
• Why I missed it: my background check was still waiting for the trail's review to finish, so it hadn't reported this finding yet. That check is still running; it will report any findings on this latest push once the trail leaves "reviewing".