standards: distribute pre-approved safe-command settings.json allowlist via sync (1→2 residue)

[kyle-sexton]

Problem

No shipped pre-approved safe-command allowlist: each repo/machine accumulates its own
settings.json permission grants ad hoc, so auto mode keeps hitting blocking permission prompts
for commands that are safe everywhere (read-only git/gh, standard build/test verbs).

Boris's step-2 guardrail names this verbatim: "Pre-approve common safe bash and MCP commands
in settings.json".

Fix shape

Author the canonical safe-command allowlist in melodic-software/standards and distribute it
via the standards sync manifest (managed materialization into consumer .claude/settings.json
or a merged fragment), so the fleet shares one reviewed allowlist with local-owned extension
seams. Relation: #495 (permission preflight for unattended loops) consumes this list; the
fewer-permission-prompts skill is the per-repo discovery aid, not the distribution mechanism.

Source

1→2 residue item from the AI-adoption-ladder gap map; #239 directed "file via /work-items" —
this files it.

---

Reference: Boris Cherny, "Steps of AI Adoption" (Google Doc)

[kyle-sexton]

This was generated by AI during triage (historic normalization, rule 8g — closing out the 55-issue historic sweep).

Routing human: the fix shape names melodic-software/standards as the authoring/distribution owner (shared lint/hygiene/allowlist policy is that repo's ownership per this org's own cross-repo convention), so the actual work happens in a different repo via its sync manifest — a cross-repo policy routing, not a design fork this lane can default. This repo's role is limited to consuming the distributed allowlist once standards ships it.

[kyle-sexton]

Delivered end-to-end (2026-07-20)

The canonical safe-command allowlist ships as the standards claude-permissions component and reaches machines through the reviewed sync chain:

1. Component (feat(claude-permissions): fleet permission floor component, distributed to dotfiles standards#210, MERGED): components/claude-permissions/claude-permissions.json — 60 allow rules (read-only git/gh inspection, routine non-destructive working verbs, lint tooling, and PowerShell read-parity: the one additive gap the claude-ops: tune auto-mode classifier from observed team usage (step-3 guardrail, 1→2 residue) #697 transcript mining surfaced) + 244 deny rules (the strictest observed union: force/destructive git spellings in both shells and multiple flag positions across seven review rounds, gh api DELETE surface, hook bypass, secret reads). README records the composition model, the machine-layer (managed policy) deferral trigger, the change discipline (allow additions need observed-usage evidence; deny lands on sight), and an explicit threat-model boundary (glob rules pin common spellings as defense-in-depth — the structural fix for flag permutation is classifier-side decomposition, recorded in claude-ops: tune auto-mode classifier from observed team usage (step-3 guardrail, 1→2 residue) #697).
2. Distribution (sync manifest): managed materialization into dotfiles' .chezmoidata/claude-permissions.json — landed via the standards sync PR (melodic-software/dotfiles#244, MERGED). Runner-policy contract note: registering a new reusable workflow also flows through this chain (proven today with standards#211 → sync chore: sync standards components #729).
3. Composition (melodic-software/dotfiles#242, MERGED): the ~/.claude/settings.json modify-template UNIONS the component's rules into the live lists on every apply — locally-accumulated rules survive, the floor is always present, guarded no-op before first materialization.

Verified live on this machine post-apply: settings now carry 118 allow / 264 deny; floor rules present (PowerShell(git status *) allow, Bash(git push --mirror*) deny); pre-existing local rules intact.

Local-owned extension seams: repo/project settings and runtime-added user rules (union semantics). Consumers: #495's preflight (PR #730, in flight) points here as the canonical remediation; #697 closed on this component as the tuning surface.

[kyle-sexton]

Post-close research note — machine-layer (managed settings) facts, verified 2026-07-20

The component README defers machine-level distribution with a trigger ("fleet machines operated by more than one person, or an org-enablement adoption"). Facts verified from the official docs after close, for whoever fires that trigger — they de-risk the deferred leg:

• Allow lists UNION additively across sources (managed, user, project, local) and evaluation is deny → ask → allow with first-match-wins; a deny at any scope supersedes allow from any other scope; managed settings cannot be overridden. So a managed-layer materialization of this component's rules composes safely with the existing user-layer seam — same union semantics the dotfiles composition relies on.
• Managed-settings paths (current): Windows C:\Program Files\ClaudeCode\managed-settings.json (the ProgramData path is deprecated since v2.1.75), macOS /Library/Application Support/ClaudeCode/managed-settings.json, Linux/WSL /etc/claude-code/managed-settings.json.
• Managed layer supports drop-in directories (managed-settings.d/, alphabetically merged) on macOS/Linux — a natural exact-file materialization target for the sync engine (no merge primitive needed), though user/project settings have no such mechanism (which is why the dotfiles chezmoi seam carries the user layer).

Sources: https://code.claude.com/docs/en/permissions · https://code.claude.com/docs/en/settings (recheck at adoption time — paths and semantics are vendor-owned and the Windows path already moved once).