feat: Permission model for spawned agents — safety rails on job capabilities

[nigel-dev]

Source

Audit report — Section 2: Competitive Landscape (Where MC Falls Behind) + Section 4: Ecosystem Patterns

Description

Spawned MC jobs have full unrestricted access — they can modify any file, run any command, push to any branch. There are no safety rails. The ecosystem plugin opencode-background-agents demonstrates a read-only permission model for background agents, with strict safety constraints.

Current State

• Jobs run with full filesystem and git access in their worktree
• No way to restrict a job to read-only operations
• No capability-based permissions (e.g., "can modify files but not push")
• No file-scope restrictions (e.g., "can only modify files matching src/ui/**")

Proposed Solution

1. Permission levels: full (default, current behavior), restricted (limited write), readonly (no modifications)
2. File scope restrictions: Combine with touchSet to enforce which files a job can modify
3. Operation restrictions: Block specific operations (e.g., no git push, no npm publish)
4. Enforcement: Via worktree filesystem permissions, git hooks, or agent prompt constraints
5. Configuration: Per-job in mc_launch and per-plan-job in mc_plan

Ecosystem Precedent

• opencode-background-agents: Read-only permission model with strict safety rails
• General principle: spawned agents should have least-privilege access

Priority

P2 — improves safety for production use. Especially important when MC is used on sensitive codebases or in team environments.