Observed in a real overnight run (2026-08-07, Stephenson-Software/Kreatures).
create-dev-loop.md tells generated dev-loops to isolate concurrent work in a git worktree:
- line 540 (Edge cases): "work in a
git worktree to avoid colliding"
- line 172: "Under a
git worktree workflow the main checkout stays on {{DEFAULT_BRANCH}}..."
- line 470: the
--delete-branch note, which presupposes the same workflow
None of the three says where the worktree should live. Under gardener tend, that omission is fatal: the dispatched claude -p session is scoped via --add-dir to the gardener-managed checkout, so anything created outside it cannot be read or edited.
The Kreatures run created a worktree at /tmp/kr35 and was then locked out of it:
Error: Claude requested permissions to read from /tmp/kr35/tests/test_lag_prevention.py,
but you haven't granted it yet
The run's own account: "...the primary working directory, so every attempt to read or edit a file inside the worktree was refused."
That repo recorded 9 permission denials, the joint-highest of the run, and spent turns rediscovering a constraint that is structural and knowable in advance.
Why this is a create-dev-loop issue rather than a gardener one
The scoping is gardener's safety model working correctly — a dispatched session confined to the target checkout is the point, and widening --add-dir to /tmp would be a real regression. The fixable half is the instruction, which currently recommends a workflow that cannot succeed in the environment these skills are most often executed in.
Suggested change
Where the worktree is recommended, constrain the location and state the failure mode:
Place the worktree inside the repository checkout (e.g. .worktrees/<branch>, gitignored), never in /tmp or elsewhere outside it. A headless dispatch (gardener tend) is scoped to the checkout directory, so a worktree created outside it cannot be read or edited — every subsequent file operation is refused, and the cycle stalls.
Worth checking whether .worktrees/ inside the checkout interacts badly with the git clean -fdx that gardener's refresh runs; if it does, the honest guidance may instead be that the worktree workflow is for interactive sessions only, and a headless dispatch should use the checkout directly since gardener already guarantees a dedicated clone per run.
This was found while auditing permission denials across an overnight run; 8 of 9 repos recorded denials, and this was the only one where the denials actually impeded the work.
drafted by Claude on behalf of Daniel Stephenson
Observed in a real overnight run (2026-08-07,
Stephenson-Software/Kreatures).create-dev-loop.mdtells generated dev-loops to isolate concurrent work in agit worktree:git worktreeto avoid colliding"git worktreeworkflow the main checkout stays on{{DEFAULT_BRANCH}}..."--delete-branchnote, which presupposes the same workflowNone of the three says where the worktree should live. Under
gardener tend, that omission is fatal: the dispatchedclaude -psession is scoped via--add-dirto the gardener-managed checkout, so anything created outside it cannot be read or edited.The Kreatures run created a worktree at
/tmp/kr35and was then locked out of it:The run's own account: "...the primary working directory, so every attempt to read or edit a file inside the worktree was refused."
That repo recorded 9 permission denials, the joint-highest of the run, and spent turns rediscovering a constraint that is structural and knowable in advance.
Why this is a create-dev-loop issue rather than a gardener one
The scoping is gardener's safety model working correctly — a dispatched session confined to the target checkout is the point, and widening
--add-dirto/tmpwould be a real regression. The fixable half is the instruction, which currently recommends a workflow that cannot succeed in the environment these skills are most often executed in.Suggested change
Where the worktree is recommended, constrain the location and state the failure mode:
Worth checking whether
.worktrees/inside the checkout interacts badly with thegit clean -fdxthat gardener's refresh runs; if it does, the honest guidance may instead be that the worktree workflow is for interactive sessions only, and a headless dispatch should use the checkout directly since gardener already guarantees a dedicated clone per run.This was found while auditing permission denials across an overnight run; 8 of 9 repos recorded denials, and this was the only one where the denials actually impeded the work.
drafted by Claude on behalf of Daniel Stephenson