Summary
bin/fm-spawn.sh's claude launch template hardcodes --dangerously-skip-permissions as the only permission mode for crewmates:
claude) printf '%s' 'CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=false claude --dangerously-skip-permissions ...' ;;
This bypasses every permission check for autonomous crews. The apparent rationale is sound - a crew has no human at its pane to answer an interactive permission prompt, so bypass prevents it from hanging - but bypass is a heavy way to get non-blocking autonomy, and it removes all safety review from agents that run largely unattended.
Proposal
Launch claude crews with --permission-mode auto instead of --dangerously-skip-permissions, and/or make the mode configurable (e.g. a gitignored config/crew-permission-mode, defaulting to auto).
--permission-mode auto gives the same property that motivated bypass - it does not hang an autonomous agent, because the auto-mode classifier denies a risky action (the call fails with a message) rather than blocking on a human prompt - while keeping a safety classifier in front of genuinely dangerous operations. A crew that hits a real denial can then escalate rather than silently proceeding.
This preserves the sandbox/CI use case: a user who genuinely wants full bypass (e.g. a disposable sandbox) can opt back in via the config knob, so the default is safe and the escape hatch remains.
Evidence (empirical, per CONTRIBUTING's harness-change rule)
Verified live on Claude Code: crewmates launched with --permission-mode auto run fully unattended through real work (multi-step reviews and a backend smoke test), including driving a validation pipeline, with no hangs. claude --help confirms --permission-mode accepts auto. Verified on both the tmux and cmux runtime backends.
Scope
Only the claude adapter's launch line is in question here. The other adapters (codex --dangerously-bypass-approvals-and-sandbox, opencode allow-all, grok --always-approve) have their own autonomy flags and are out of scope for this issue; a follow-up could consider analogous safer defaults per harness if the maintainer agrees with the direction.
Happy to raise the PR through the no-mistakes fork workflow if this direction is welcome.
Summary
bin/fm-spawn.sh's claude launch template hardcodes--dangerously-skip-permissionsas the only permission mode for crewmates:This bypasses every permission check for autonomous crews. The apparent rationale is sound - a crew has no human at its pane to answer an interactive permission prompt, so bypass prevents it from hanging - but bypass is a heavy way to get non-blocking autonomy, and it removes all safety review from agents that run largely unattended.
Proposal
Launch claude crews with
--permission-mode autoinstead of--dangerously-skip-permissions, and/or make the mode configurable (e.g. a gitignoredconfig/crew-permission-mode, defaulting toauto).--permission-mode autogives the same property that motivated bypass - it does not hang an autonomous agent, because the auto-mode classifier denies a risky action (the call fails with a message) rather than blocking on a human prompt - while keeping a safety classifier in front of genuinely dangerous operations. A crew that hits a real denial can then escalate rather than silently proceeding.This preserves the sandbox/CI use case: a user who genuinely wants full bypass (e.g. a disposable sandbox) can opt back in via the config knob, so the default is safe and the escape hatch remains.
Evidence (empirical, per CONTRIBUTING's harness-change rule)
Verified live on Claude Code: crewmates launched with
--permission-mode autorun fully unattended through real work (multi-step reviews and a backend smoke test), including driving a validation pipeline, with no hangs.claude --helpconfirms--permission-modeacceptsauto. Verified on both the tmux and cmux runtime backends.Scope
Only the claude adapter's launch line is in question here. The other adapters (
codex --dangerously-bypass-approvals-and-sandbox,opencodeallow-all,grok --always-approve) have their own autonomy flags and are out of scope for this issue; a follow-up could consider analogous safer defaults per harness if the maintainer agrees with the direction.Happy to raise the PR through the no-mistakes fork workflow if this direction is welcome.