[judewang]

Follow-up to #3489. That PR anchored the WorktreeRemove hook at CLAUDE_PROJECT_DIR, which fixes the case where the variable names the repository. It cannot help when the anchor itself is not inside a repository — which is the normal situation for the claude agents view, and the case I still hit after #3489 landed.

Why the project dir isn't a usable anchor here

The claude agents view is a single list spanning every repository you have run a background session in. It is launched from one directory, and for anyone managing several repos that directory is typically a parent that merely contains them rather than a repository itself:

claude daemon run --origin transient \
  --spawned-by {"label":"claude agents","cwd":"/…/Repositories/github.com/<org>",…}

/…/Repositories/github.com/<org> holds several clones and is not a git repository. The daemon supervisor's own cwd is $HOME, and its environment carries no CLAUDE_PROJECT_DIR at all. So both the anchor and the :-. fallback land outside any repository, and wt remove <path> dies exactly as it did before #3489:

✗ Failed to remove worktree
  fatal: not a git repository (or any of the parent directories): .git
# exit 1 → "WorktreeRemove hook failed" → session undeletable

The deletion runs in the long-lived daemon, so relaunching claude agents from inside a repository does not change the outcome. More generally: CLAUDE_PROJECT_DIR can only ever name one directory, but the agents view is inherently multi-repo — no single value is correct for every row in the list.

This is probably why it has stayed quiet: it only bites background sessions driven from the agents view, and only once the anchor directory isn't itself a repository.

Change

Resolve against the worktree path itself, using the existing global -C:

-bash -c 'p=$(jq -er .worktree_path) || exit 1; cd "${CLAUDE_PROJECT_DIR:-.}" || exit 1; [ -e "$p" ] || exit 0; bash "$CLAUDE_PLUGIN_ROOT/hooks/wt.sh" remove --foreground "$p"'
+bash -c 'p=$(jq -er .worktree_path) || exit 1; [ -e "$p" ] || exit 0; bash "$CLAUDE_PLUGIN_ROOT/hooks/wt.sh" -C "$p" remove --foreground "$p"'

$p is strictly more specific than any environment variable: a linked worktree carries a .git file pointing at <repo>/.git/worktrees/<name>, so discovery from inside it resolves the owning repository wherever the worktree lives on disk. That makes the fix layout-independent — it behaves identically for the default out-of-tree layout and for a worktree-path pointing inside the repo. The [ -e "$p" ] guard from #3493 already runs first, so -C "$p" is only reached when the directory exists.

Reproduction

cwd $HOME, CLAUDE_PROJECT_DIR unset, worktree clean and pushed. Run against both layouts — an out-of-tree worktree (default worktree-path) and one inside the repo:

hook body	out-of-tree	in-repo
cd "${CLAUDE_PROJECT_DIR:-.}" … remove (current)	fatal: not a git repository, exit 1	fatal: not a git repository, exit 1
-C "$p" … remove (this PR)	✓ Removed … worktree & branch, exit 0	✓ Removed … worktree & branch, exit 0

With CLAUDE_PROJECT_DIR set to the repository, both forms succeed — this PR only changes the case where it isn't.

Knock-on: which .config/wt.toml supplies the removal hooks

The anchor also selects the project config that pre-remove / post-remove are taken from — they come from the invoking worktree, so -C "$p" makes that the worktree being removed rather than the project dir. Approvals are keyed on the repo-level project identifier, so a checked-in config the session never touched resolves identically and nothing changes.

The one behavioural delta is a session that edited .config/wt.toml inside its own worktree: those commands are then unapproved, and because the hook's stdin isn't a TTY, prompt_for_batch_approval returns NotInteractive and wt remove exits nonzero instead of continuing hookless. That is fail-closed, which seems right for a command the agent itself wrote — but it does mean that particular session stays undeletable from the agents view, so this trades one instance of the symptom for a narrower one rather than removing it outright.

Tests

Initially none: an anchor regression surfaces loudly rather than silently, unlike #2939 / #3545, and #3453 / #3489 / #3493 each landed as a one-line hooks.json change with the test file untouched. On review it's a fair point that this is the fourth change to these two commands and test_plugin_layout_is_consolidated is where each prior fix was pinned, so the second commit adds an assertion there: the WorktreeRemove command must resolve via -C "$p", and must not depend on CLAUDE_PROJECT_DIR. It sits next to the existing -D and pipefail checks on worktree_remove_cmd, and fails against the pre-fix hooks.json.

The existing assertions still hold: every hook command references $CLAUDE_PLUGIN_ROOT unbraced — unchanged; the WorktreeRemove command contains no -D / --force-delete — -C is neither. test_claude_hook_commands_parse_in_all_shells checks the outer command line under fish/zsh/bash, and the edit stays inside the single-quoted bash -c body.

Alternatives considered

• cd "$p" rather than -C "$p" — also works, but it moves the shell into the directory that is about to be deleted. -C leaves the cwd alone and matches how wt step prune -C is already used elsewhere.
• Keeping CLAUDE_PROJECT_DIR as a fallback — adds nothing. When it names the right repository, -C "$p" resolves to that same repository; when it doesn't, it is the bug being fixed.

Out of scope

A path that exists on disk but holds no worktree (a skeleton left by an interrupted create/remove) still fails, because [ -e "$p" ] passes and wt remove then finds nothing to remove. That is orthogonal to the anchor — tracked separately in #3753.

[worktrunk-bot]

Holding this one for a human rather than approving: the diff edits the WorktreeRemove entry in plugins/worktrunk/hooks/hooks.json, and that command is shipped automation that runs wt remove unattended (worktree directory removal plus branch deletion) when Claude Code tears a session down. Repo policy is that changes reaching that surface get a maintainer's sign-off — @max-sixty, over to you. The reasoning in the description holds up on my read: $p carries a .git file pointing back at <repo>/.git/worktrees/<name>, so -C "$p" resolves the owning repository regardless of where the worktree sits, the [ -e "$p" ] guard from #3493 still runs first, and passing "$p" positionally as well as to -C is what keeps a non-worktree path a hard error — resolve_worktree falls through to BranchOnly { branch: "/abs/path" }, which can't name a real branch, rather than falling back to the enclosing worktree.

Two things worth putting on the record:

The anchor also decides which .config/wt.toml supplies the removal hooks. pre-remove / post-remove are selected from the invoking worktree's project config (approve_remove in remove.rs), and -C "$p" makes that the worktree being removed instead of the project dir. Approvals are keyed on the repo-level project identifier (remote URL, else repo root), so a checked-in config the agent never touched resolves identically and nothing changes. The delta shows up when the agent session edited .config/wt.toml in its own worktree: those commands are then unapproved, and because the hook's stdin isn't a TTY, prompt_for_batch_approval returns NotInteractive and the whole wt remove exits nonzero instead of continuing hookless. Fail-closed is the right direction for an unapproved project command, but it's a new way for the hook to fail that the description doesn't cover.

A test would be cheap here. I take the point that an anchor regression surfaces loudly rather than silently, unlike #2939 / #3545. But this is the fourth PR against these two hook commands (#3453, #3489, #3493, #3546), and test_plugin_layout_is_consolidated is already the place where each prior fix got pinned — an assertion that the WorktreeRemove command resolves against worktree_path rather than depending on CLAUDE_PROJECT_DIR would sit next to the existing -D and pipefail checks and stop the anchor from being re-litigated a fifth time. It's outside this diff, so I haven't left it inline; happy to push it as a commit on this branch if you want it.

[judewang]

Thanks — both points taken, and the second one is a real gap in my description.

On the project-config anchor. You're right, and I'd missed it: remove.rs says it outright — every pre-remove / post-remove / post-switch hook is "selected from the invoking worktree's .config/wt.toml — the worktree wt remove ran in". So -C "$p" does move that selection from the project dir to the worktree being removed. As you say, approvals are keyed on the repo-level project identifier, so a checked-in config the session never touched resolves identically; the delta is exactly the case you describe, where the session edited .config/wt.toml in its own worktree and prompt_for_batch_approval returns NotInteractive with no TTY.

Fail-closed is the right call for a command the agent itself wrote, but it's worth being explicit that it trades one undeletable-session case for a narrower one rather than removing it outright — I've added a section to the description rather than leave that implicit. The alternatives I can see are worse: --no-hooks in the hook command would drop legitimate post-remove cleanup (killing dev servers and the like), and anything --yes-shaped would silently approve commands the agent wrote itself. Happy to follow your preference if you'd rather it couldn't fail that way at all.

On the test. Fair — four PRs against these two commands is the argument, and I'd rather not have you push it. Added as a second commit: it sits next to the -D and pipefail checks on worktree_remove_cmd and pins both halves — resolves via -C "$p", and does not depend on CLAUDE_PROJECT_DIR. It fails against the pre-fix hooks.json and passes after.

Also noted your point about resolve_worktree falling through to BranchOnly { branch: "/abs/path" } — that's a sharper statement of why a non-worktree path stays a hard error than what I had in the description.

[worktrunk-bot]

The added test is the one I offered to push, and it checks out against the shipped command: it pins both halves next to the existing -D and pipefail assertions on worktree_remove_cmd, and !contains("CLAUDE_PROJECT_DIR") is scoped to that command, so the WorktreeCreate hook's cd "${CLAUDE_PROJECT_DIR:-.}" is unaffected. I also confirmed the flag placement: -C is declared global = true on Cli::directory and applied via set_base_path in apply_global_options before any repo discovery, so -C "$p" ahead of the subcommand does anchor discovery at the worktree. Nothing further from me on the diff.

Still not approving, for the reason in my earlier review rather than a new one: the diff edits the WorktreeRemove entry in plugins/worktrunk/hooks/hooks.json, which is shipped automation that runs wt remove unattended, and repo policy reserves that surface for a maintainer. Both points from that review are now closed — the description covers the project-config knock-on, and the test is in — so this is only waiting on @max-sixty, who is already on the review request.

[worktrunk-bot]

One thing my review just now didn't answer, since you asked directly: on whether I'd rather it couldn't fail that way at all — leave this PR as it is. --no-hooks and anything --yes-shaped are both worse, as you say. But I don't think the residual case is the hook command's to fix, and it's worth naming where it does live, because wt remove is currently stricter without a TTY than it is with one.

An explicit interactive decline continues the removal hookless — remove.rs prints Commands declined, continuing removal without hooks and proceeds with an empty plan. No TTY at all never reaches that arm: prompt_for_batch_approval returns GitError::NotInteractive, which propagates out of approve and aborts the whole removal. So a user who says "no" gets their worktree removed, and the hook that can't be asked doesn't.

CLAUDE.md already has the rule for a context that can't prompt — consult approvals read-only and run only the already-approved subset, which is what HookPlan::approve_readonly does for the picker and for wt step prune. A non-TTY wt remove taking that path would be strictly safer than the existing decline arm (which drops approved post-remove cleanup along with everything else), would still never run a command the agent wrote itself, and would leave no session undeletable — closing the narrower case this PR trades down to.

That's a change to wt remove's approval path with its own tests, and a policy call about non-interactive wt remove generally rather than about this hook, so it doesn't belong on a one-line hooks.json fix. @max-sixty, happy to open it as a follow-up if you want it; either way it doesn't block this.

[max-sixty]

thanks @judewang !