git worktree of an already-trusted repo still re-prompts "Workspace not trusted" on 2.1.284, despite the documented fix

Version: 2.1.284

Expected behavior (per maintainer @bcherny's comment on #23109, closed as completed 2026-08-17): "workspace trust is now keyed on the repository's main checkout, so git worktrees of an already-trusted repo don't prompt again."

Actual behavior: A brand-new git worktree add directory under an already-trusted parent repo (confirmed via ~/.claude.json: the parent repo path has hasTrustDialogAccepted: true) still fails on first claude --bg dispatch with:

Workspace not trusted. Run `claude` in <worktree path> once and accept the trust prompt, then retry.

Running claude interactively in the worktree shows the full "Quick safety check" trust dialog, exactly as if the parent had never been trusted at all. Accepting it manually clears it for that one worktree, but the underlying ~/.claude.json never gains its own hasTrustDialogAccepted entry for the worktree path either before or after acceptance — trust for worktrees does not appear to persist to ~/.claude.json the same way it does for an ordinary trusted repo root, which may be related to why it doesn't inherit.

Repro:

1. Trust a repo (hasTrustDialogAccepted: true present for its path in ~/.claude.json).
2. git worktree add <repo>/.claude/worktrees/some-branch -b some-branch
3. cd <repo>/.claude/worktrees/some-branch && claude --bg "..." (or launch claude interactively)
4. Trust dialog / "Workspace not trusted" error appears, even though the parent is trusted and this is a worktree of that exact repo (not a separate/nested clone).

Context: We run a high-volume ops workflow that creates a fresh git worktree per dispatched task (many per session, across several repos) and previously relied on this exact inheritance working — it did, reliably, earlier the same session, before a mid-session Claude Code CLI update to 2.1.284. Per #23109's own history, worktree-trust inheritance was deliberately tightened in 2.1.232 (nested git repos each requiring their own confirmation) and then reportedly fixed again before 2.1.284 specifically so worktrees wouldn't be caught by that tightening. This report is the repro @bcherny asked for in that case: "If you're on a current version and still see the prompt for a worktree of a trusted repo, please reopen with your version and how the worktree was created."

Related: #23109, #96928, #97048, #84402