[feat] opencode_cli: `cao launch --yolo` is a no-op (upstream TUI lacks a skip-permissions flag)

[haofeif]

Summary

cao launch --yolo is silently ignored on opencode_cli. Unlike other providers (claude_code → --dangerously-skip-permissions, codex/gemini_cli/kimi_cli → --yolo, copilot_cli → --allow-all, kiro_cli → --trust-all-tools --legacy-ui), the opencode_cli provider has no runtime flag to translate allowed_tools=['*'] into.

Permission enforcement on opencode_cli is install-time only — cao_tools_to_opencode_permission writes the permission: block into the agent's frontmatter at cao install time. cao launch --yolo cannot loosen an already-installed profile.

Root cause — upstream limitation

OpenCode's CLI splits permission handling by command:

opencode command	--dangerously-skip-permissions?
opencode (TUI — what CAO drives)	❌ not supported
opencode run (headless one-shot)	✅ supported (undocumented easter egg)

CAO drives opencode in TUI mode (opencode --agent <name> inside tmux) because that's what provides the interactive lifecycle + status detection CAO needs. The TUI does not accept the flag.

Tracked upstream:

• [FEATURE]: Add --dangerously-skip-permissions (aka YOLO mode) anomalyco/opencode#8463 — Add --dangerously-skip-permissions (YOLO mode) — open
• feat: YOLO Mode — Auto-Approve All Permission Prompts anomalyco/opencode#11831 — YOLO Mode — Auto-Approve All Permission Prompts — open
• feat: YOLO Mode - Skip Permission Prompts anomalyco/opencode#9070 — YOLO Mode - Skip Permission Prompts — open
• [FEATURE] Add --yolo unrestricted execution mode for OpenCode anomalyco/opencode#18482 — Add --yolo unrestricted execution mode for OpenCode — open
• The --dangerously-skip-permissions flag ought be documented. anomalyco/opencode#23370 — The --dangerously-skip-permissions flag ought be documented — open (even the existing run-only flag is undocumented)

Current CAO behaviour

src/cli_agent_orchestrator/providers/opencode_cli.py stores allowed_tools via super().__init__(...) but _build_launch_command() never consults it. From the docstring at opencode_cli.py:92:

allowed_tools: Optional CAO tool list (informational; enforcement is via frontmatter)

So:

• cao install ... --provider opencode_cli → writes permission: block from allowedTools (or * if profile has allowedTools: ['*'])
• cao launch --yolo on opencode_cli → no change to runtime behaviour; permissions from the installed frontmatter still apply

User impact

A user running cao launch --agents my_agent --provider opencode_cli --yolo expecting unrestricted tool access will instead get whatever permissions were baked in at install time. Silent no-op — no warning, no error. Inconsistent with every other provider.

Proposed options

Option 1 — Document + warn (low-risk, ship now)

• Note in docs/opencode-cli.md that --yolo does not apply at runtime on opencode_cli; users must install the profile with allowedTools: ['*'] to get yolo behaviour.
• In src/cli_agent_orchestrator/cli/commands/launch.py, when yolo and provider == "opencode_cli", print a warning: "--yolo is a no-op on opencode_cli. Permissions are set at install time. Re-run cao install with a profile containing allowedTools: ['*'] for unrestricted access."

Option 2 — Temp agent workaround (medium-risk)

• When yolo is set, write a temp opencode agent .md to $OPENCODE_CONFIG_DIR/agent/<base>-yolo.md with permission: { "*": "allow" } and tools: { ... all true }, then launch with --agent <base>-yolo.
• Clean up on terminal close.
• Adds file churn in the user's opencode config dir and diverges from the installed profile identity.

Option 3 — Wait for upstream

• Track [FEATURE]: Add --dangerously-skip-permissions (aka YOLO mode) anomalyco/opencode#8463. When a --dangerously-skip-permissions or --yolo flag lands for the TUI and ships in a stable opencode release, add it to _build_launch_command() behind a "*" in self._allowed_tools check. ~5 lines.

Recommendation

Ship Option 1 now (matches the experimental — single-agent only scoping), then adopt Option 3 once upstream ships a TUI-compatible flag. Avoid Option 2 unless a concrete customer needs runtime-toggleable yolo on opencode before upstream resolves it.

Related

• PR feat: Add OpenCode CLI provider support #193 (opencode_cli provider integration)
• PR fix(kiro_cli): honor --yolo and profile.model at launch #201 / __permission probe — please ignore__ #202 (kiro_cli --yolo + --model fix — same shape of problem, resolved at the provider level because kiro-cli exposes the flag)

[haofeif]

@patricka3125 for your information, i will include the option in #201 for now.

[bergstar]

Why no YOLO ?