Repository navigation
v0.1.55
New tasks appear immediately, and no longer copy other checkouts' dependencies or secrets (#209)
If you keep another tool's worktrees inside a repo (a .claude/worktrees directory, a vendored clone, a submodule), creating a task in 0.1.54 walked straight into them. On one monorepo that meant 370 node_modules trees copied instead of 11, and 28 .env / .dev.vars files belonging to six unrelated checkouts landing in every new task worktree, readable by any agent launched there.
It also made task creation look broken. The task's row was written only after all that copying finished, so the board showed nothing for the best part of a minute, the click read as a no-op, and the same task got created several times over. Deleting the duplicates then failed with block timeout reached, leaving cards pointing at half-deleted worktrees that could never be removed.
Three fixes:
- Ask git what belongs to this repo instead of walking the directory tree.
git ls-filesnever crosses a repository boundary, so a nested checkout is a single entry whose contents are never listed, and it owns ignore semantics for free. - The task's card now appears as soon as its worktree exists (~3s), with the dependency copy running afterwards. Launching an agent waits for it, so nothing ever starts in a half-seeded worktree.
- A removal git could not finish now completes.
git worktree removeprints nothing while it unlinks, which tripped an inactivity timeout at five minutes on large worktrees. Narrowly scoped to that case: git refusing to remove a dirty worktree still refuses, so uncommitted work is never discarded.
Measured on a repo with 433 worktrees: card in 2.9s (was ~54s), 11 dependency trees (was 370), 5 env files with none borrowed (was 33 with 28 borrowed), delete in 10s (was a five-minute timeout).
Worth updating if you are on 0.1.54 and have nested checkouts inside a repo, since that version copies unrelated checkouts' secrets into every task worktree.