Launch Manager terminal in auto permission mode by default

[dhilgaertner]

Summary

• Adds a managerAutoPermissionMode setting (default true) that passes --permission-mode auto to the Manager's claude launch, eliminating per-call approval prompts for the crow, gh, and git commands the Manager runs to orchestrate workspaces.
• Exposes a Settings → General → Manager Terminal toggle so users on plans or providers where auto mode is unavailable (Pro plan, Bedrock/Vertex/Foundry, Claude Code < 2.1.83) can opt out.
• Scope is Manager-only — worker sessions and crow new-terminal–spawned terminals keep the default permission mode.

Implementation mirrors the existing remoteControlEnabled plumbing added in #163: field on AppConfig → mirror on AppState → new optional parameter on ClaudeLaunchArgs.argsSuffix(...) → wired into both Manager launch paths in SessionService (first-time creation and hydration rebuild).

Closes #187.

Test plan

• make build — clean build.
• swift test --package-path Packages/CrowCore — 112 tests pass (3 new ClaudeLaunchArgs cases, 2 new AppConfig cases including forward-compat default).
• swift test --package-path Packages/CrowPersistence — 7 tests pass (new ConfigStore round-trip for the new field, plus the forward-compat test extended to assert legacy configs default to true).
• Fresh launch with no .claude/config.json key — confirm Manager's ps argv contains --permission-mode auto.
• Toggle off in Settings → relaunch → confirm flag is gone from Manager argv and running gh issue view … now prompts for approval.
• Toggle back on → relaunch → confirm flag returns and the same gh call runs without a prompt.
• Confirm worker sessions and CLI-spawned terminals do not include --permission-mode auto.

🤖 Generated with Claude Code

[dgershman]

Code & Security Review

Critical Issues

None found.

Security Review

Strengths:

• Auto permission mode is scoped exclusively to the Manager terminal — worker sessions and CLI-spawned terminals are explicitly unaffected, preserving the principle of least privilege for user-facing code sessions.
• The setting defaults to true but provides a clear opt-out path via Settings UI, with documentation explaining which plans/providers support it.
• No secrets, credentials, or sensitive data are exposed. The feature simply passes a CLI flag (--permission-mode auto) — the actual permission enforcement remains in Claude Code itself.
• Shell argument construction uses shellQuote() for safe interpolation, preventing command injection via session names.

Concerns:

• None. The blast radius is well-contained: one boolean flag on a single terminal type, with the underlying permission enforcement delegated to Claude Code's own auto-mode implementation.

Code Quality

• Clean implementation that mirrors the established remoteControlEnabled plumbing pattern (AppConfig → AppState → ClaudeLaunchArgs → SessionService), making it easy to follow.
• argsSuffix refactored from early-return guard to additive string building — handles the 2×2 matrix of (remoteControl × autoPermissionMode) cleanly.
• Default parameter autoPermissionMode: Bool = false preserves backward compatibility for all existing call sites without requiring changes.
• Forward-compatible decoding via decodeIfPresent(...) ?? true ensures legacy configs without the key automatically get auto mode — good UX for existing users.
• Both Manager launch paths (first-time creation at SessionService.swift:265 and hydration rebuild at SessionService.swift:72) are updated consistently.
• Comprehensive test coverage: 3 new ClaudeLaunchArgs tests (auto-only, auto+RC, default-off), 2 new AppConfig tests (round-trip, missing-key default), and 1 new ConfigStore persistence test. All 136 tests pass.
• Settings UI toggle includes clear guidance text about requirements and when to opt out.
• Documentation updated in README.md and docs/configuration.md with accurate plan/provider/version requirements.

Summary Table

Priority	Issue
🟢	Consider: the docs/configuration.md section lists specific model names (Sonnet 4.6, Opus 4.6, Opus 4.7) — these may need updating as new models ship, but that's a docs maintenance concern, not a code issue.

Recommendation: Approve — well-scoped feature with clean implementation, good test coverage, and no security concerns. Follows established patterns and is properly documented.