claude-code adapter: pass --dangerously-skip-permissions

[gabehamilton]

Summary

The spawned `claude -p` subprocess has `stdin=null`, so it cannot answer permission prompts. Without `--dangerously-skip-permissions` every tool call gets silently denied — stages report `partial_success` with N tool errors while doing no real work.

Why it took a real run to spot this

The default permission policy in print mode appears to allow generic tools (Bash, Read, Write) at the type level, but specific invocations still trigger interactive approval flows. With `stdin=null` the subprocess just gives up. Forge sees the JSONL events for the attempted tool_use plus tool_result with `is_error: true`, increments a counter, marks the stage as `partial_success` (which forge treats as advancing), and moves on — so the pipeline progresses without producing artifacts.

Verified against a local bootstrap run

Stage	Status before	Errors before	Status after	Errors after
install_sentrux	partial_success	17	success	0
ingest_origin_docs	partial_success	6	success	0
fill_briefing	partial_success	8	success	0
build_mock	partial_success	6	success	0 (artifacts now written)

Before: `mock/` directory was never created. After: `mock/index.html`, `app.js`, `fixtures.json`, `style.css` all written.

Test plan

• Local bootstrap run shipped through briefing_review and walkthrough_gate with zero tool errors per stage.
• CI builds the workspace cleanly.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request adds the --dangerously-skip-permissions flag to the Claude Code CLI adapter to prevent tool calls from being silently denied in non-interactive sessions where stdin is null. A security concern was raised regarding the potential for destructive actions without human oversight, and it is recommended to make this behavior an opt-in configuration via AgentRunOptions.

[gemini-code-assist]

Bypassing all permission prompts with --dangerously-skip-permissions is a significant security risk, as it allows the LLM to execute potentially destructive tools (such as shell commands or file writes) without human oversight. While this is necessary for non-interactive execution when stdin is null, it should ideally be an opt-in configuration. Consider adding a field to AgentRunOptions to allow users to explicitly enable this behavior, or at least ensure this security trade-off is prominently documented for users of this provider.

[gabehamilton]

Fixed in 0cd4fa3. Made it opt-in: added auto_approve_tools: bool to AgentRunOptions (defaults to false). ClaudeCodeAgentProvider only passes --dangerously-skip-permissions when that flag is true. The forge-attractor AgentProviderSubmitter (used by pipeline runs where stdin=null is the design) sets it to true; library consumers wiring up AgentProvider directly now have to make an explicit choice. Doc comment on the field explains the trade-off.