pickup.sh reports a worktree's uncommitted paths as "dirty in the primary checkout", the one line the never-work-there rule depends on

[lex00]

What

Run from inside a worktree, scripts/pickup.sh printed:

dirty 30 uncommitted path(s) in the primary checkout

and then listed paths belonging to the worktree it was run from, not to the primary checkout. Verified directly at the time: the primary checkout had zero modified tracked files, and its only untracked entries were .terraform/ plugin directories dated Aug 16.

Found by the board re-measure worker (PR #1011) while running from /Users/alex/Documents/checkouts/intentius/wt/board-remeasure-release.

Why it is worth fixing rather than living with

That line is load-bearing. HANDOFF.md's "Pick up here" table makes dirty paths in the primary checkout a disposition an agent must act on before anything else, and CLAUDE.md opens with "Never work in the primary checkout", recording five agents who got it wrong on 2026-08-29 and the silent not_run with exit 0 that followed. A false positive on exactly that line trains a reader to skim past it, which is the failure mode the rule exists to prevent.

Do

Find where pickup.sh computes the dirty set and make it ask the primary checkout specifically, rather than inheriting the caller's repository context: git -C "$PRIMARY" status --porcelain with $PRIMARY resolved from the known path or from git rev-parse --git-common-dir, not a bare git status that resolves to whichever worktree invoked the script.

Prove it both ways, since a check that cannot fail is not a check: with the primary genuinely dirty it must still report, and run from a dirty worktree with a clean primary it must report nothing. The second is the case that is broken today.

While there, check whether any other section of pickup.sh has the same context leak, since several of them shell out to git.

Refs #1011.

[lex00]

Fixed in #1013.

Mechanism: resolve PRIMARY once from git rev-parse --git-common-dir (absolute path to the primary's .git when run from a linked worktree; the bare relative .git when run from the primary itself), with the known hard-coded path kept only as a last-resort fallback if that command fails, never as the mechanism.

Audited all real git invocations in the script (25, not the 28 a naive grep counts — 3 of those are comments/an echoed string, not calls). Only the two bare git status --porcelain calls behind the dirty check (both same root cause) were wrong; everything else already scopes to a specific worktree with -C, asks about shared repository state that doesn't depend on cwd, or is the artifact/readiness section, which is deliberately "on this branch" per its own comments.

Proved both directions in the PR body: from a dirty worktree with the primary untouched, the reported count now equals the primary's own independently-measured count exactly (31, all pre-existing .terraform/ dirs — not 33, which is what the old bug would have shown); adding one genuinely untracked file to the primary moves the count to 32 and it is reported.

🤖 Generated with Claude Code