Twinned from https://github.com/cfsh/ninefold/issues/554 by tools/beads/import_github.py's reconcile pass.
Filed unclaimed and unlabelled from the CTO (cfsh/nf-office). Backlog, for a future triage round. Found by hitting it while spawning the first dev session from the office.
Claude Code keys permissions to the project path. A dev worktree is a new path every time — that is the point of ~/nf/devs/<topic> being disposable — so every dev session starts with zero remembered approvals and stops on every new command shape: gh issue, then git fetch, then python3, one prompt at a time. Unattended, it does not progress past the first one.
That makes a permission mode part of the same family as NuGet.Config: gitignored, machine-local, required, and not carried by git worktree add. .gitignore:23 already ignores .claude/settings.local.json, so nothing in the repo can supply it and nothing warns that it is missing.
NuGet.Config.example already solves exactly this problem for the SDK cache. The symmetric move:
``` .claude/settings.local.json.example -> cp to .claude/settings.local.json ```
carrying at minimum
```json { "permissions": { "defaultMode": "auto" } } ```
auto is the classifier-gated mode — the same one the Shift+Tab cycle reaches — not bypassPermissions. Whether the template should also carry an explicit allow list for the tier's common commands (git, gh, python3, ./presubmit.py) is the open question, and is why this is an issue rather than a one-line patch: an allowlist is narrower, but it goes stale silently — a dev blocked on an unlisted command stalls without saying so.
The office runbook currently pastes the JSON inline, which works but is unreviewed prose describing a config file for this repo's sessions. In-tree it would sit beside NuGet.Config.example, inherit the presubmit, and evolve with the tooling tier's actual command surface instead of with whoever last edited a runbook.
The trust-folder prompt ("Is this a project you created or one you trust?") fires before any settings file is read, on every new directory, and is answered interactively. A human presses Enter on each new worktree regardless. Worth knowing before anyone concludes a template makes spawning fully hands-off.
Related: an agent cannot grant another agent permissions, by design — the spawning session's own classifier refuses to launch a child with permissions disabled, to answer its prompts, or to write its settings file. So the template has to be applied by whoever is standing the session up, and cannot be automated away by the CTO. Reasoning recorded in the office's DECISIONS.md.
Context: the first office-spawned dev is #553 (from #545); the office-side runbook change is cfsh/nf-office@ba5ab22.
None.
No comments.