fm: crewmate --dangerously-skip-permissions spawn pollutes the user's shared/symlinked settings.json

[tkt028]

Summary

Launching a crewmate with --dangerously-skip-permissions and accepting its one-time "Bypass
Permissions mode" warning makes Claude Code persist skipDangerousModePermissionPrompt: true
into the active settings.json. When the user's ~/.claude*/settings.json is a symlink to
a shared, git-tracked source (a common dotfiles/multi-account setup), this leaks a global
safety-guardrail change into the user's repo — affecting every account, and the whole fleet if
committed.

Root cause

Crewmates run in the user's own Claude config dir (fm-spawn launches bare claude, so it
resolves the default/shared config). Their launch-mode acceptances — and their auth — therefore
write to the user's config, not a crewmate-scoped one.

Reproduction

1. ~/.claude/settings.json is a symlink to a git-tracked source file.
2. Spawn a crewmate (--dangerously-skip-permissions) and accept the Bypass Permissions warning.
3. git -C <dotfiles> diff shows an uncommitted +"skipDangerousModePermissionPrompt": true
   in the shared settings — a guardrail the user never intentionally disabled, now affecting all
   accounts.

Impact

• Silent, global reduction of the dangerous-mode confirmation guardrail from a single spawn.
• Surfaces as an unexpected diff in the user's dotfiles repo; risks being committed/pushed
  fleet-wide.

Suggested fix

Launch crewmates with a dedicated CLAUDE_CONFIG_DIR (crewmate-scoped), so their settings,
auth, and launch-mode acceptances never touch the user's shared config. This is the same fix as
#599 (multi-account auth) — one dedicated-config-dir change resolves both: crewmates
authenticate in their own dir and stop polluting the user's shared settings.

Related

• fm-spawn: claude crewmate launch hardcodes bare 'claude', failing on multi-account machines #599 (bare claude fails on multi-account machines) — same root, same fix.

---

🤖 Claude Code · claude-opus-4-8 · 2026-07-15