Thanks for the detailed report. Short answer: yes, this is feasible, and there is also a workaround today.

Current behavior

Open Code workspace templates already configure task automation as:

opencode run --dangerously-skip-permissions "$TASK_PROMPT"

Workspace specs also already support Environment Variables. So you can add:

OPENCODE_DANGEROUSLY_SKIP_PERMISSIONS=true

on the workspace spec now, which should apply to the whole process tree (including sub-agents), without needing a new UI control.

About a dedicated checkbox

A checkbox that injects that env var (with hint text about sub-agents) is feasible. Showing it only when the run command contains opencode is also doable, but needs a few product decisions first.

Please answer the clarifying questions below:

1. Where should the checkbox live? a. On Task Automation only (next to "Command to Run Task")

   • Pros: Closest to the headless opencode run ... command; clear intent for AI task runs
   • Cons: Does not help interactive Open Code shortcuts / TUI sessions in the same workspace b. On the workspace spec (top-level, near Environment Variables)
   • Pros: Applies to all Open Code processes in the workspace (task automation + shortcuts)
   • Cons: Slightly less contextual; shown even when task automation is unused c. Both places, linked to the same underlying setting
   • Pros: Most flexible UX
   • Cons: More UI complexity and state syncing
   • Recommendation: (b) — env var is workspace-scoped anyway, and one setting covers task automation and interactive use.

2. How should "only show if the run command includes the open code command" be detected? a. Match opencode only in Task Automation → Command to Run Task

   • Pros: Simple and predictable
   • Cons: Misses specs that run Open Code only via shortcuts b. Match opencode in the task command or any shortcut command
   • Pros: Covers both automation and interactive shortcuts
   • Cons: Heuristic can false-positive on unrelated commands containing the word c. Always show for Open Code templates / never auto-hide; document instead
   • Pros: No brittle string matching
   • Cons: Extra UI for non-Open-Code specs if placed at workspace level
   • Recommendation: (b) if we add the checkbox; keep matching case-sensitive token opencode (not substring of other words if practical).

3. What should checking the box do? a. Set env var OPENCODE_DANGEROUSLY_SKIP_PERMISSIONS=true only

   • Pros: Fixes sub-agent inheritance; simplest; keeps command editable
   • Cons: Command may still also contain --dangerously-skip-permissions (redundant but harmless) b. Set the env var and ensure/remove the CLI flag in the run command
   • Pros: Single source of truth in the UI
   • Cons: Mutating user-edited commands is surprising and error-prone c. Only rewrite the command to prefix OPENCODE_DANGEROUSLY_SKIP_PERMISSIONS=true ...
   • Pros: No separate env-var entry
   • Cons: Easy to lose when users edit the command; worse discoverability
   • Recommendation: (a) — inject/manage the env var; leave the command text alone (templates can keep the flag for clarity).

4. Should built-in Open Code templates enable this by default? a. Yes — add the env var in Open Code shell/container templates (in addition to the existing flag)

   • Pros: Sub-agents work out of the box for AI task automation
   • Cons: Broader "dangerously skip" surface by default b. No — leave templates as-is; checkbox/env var is opt-in
   • Pros: Safer default; no behavior change for existing users
   • Cons: Users still hit the sub-agent issue until they enable it c. Yes for container templates only; no for shell templates
   • Pros: Container isolation makes YOLO mode less risky
   • Cons: Inconsistent behavior between template types
   • Recommendation: (a) for new templates / new specs created from templates, since templates already pass --dangerously-skip-permissions and the env var is needed for sub-agents to match that intent.

5. Should this be Open Code-specific only? a. Open Code only (OPENCODE_DANGEROUSLY_SKIP_PERMISSIONS)

   • Pros: Matches the request; smallest change
   • Cons: Similar sub-agent issues may exist for other agents later b. Open Code now, with a generic pattern later for Claude/Codex/etc.
   • Pros: Solves the reported case without over-scoping
   • Cons: Temporary asymmetry in the UI c. Design a generic "skip permissions for agent" control for all supported agents up front
   • Pros: Consistent UX across agents
   • Cons: Larger design/implementation scope; agent-specific semantics differ
   • Recommendation: (a) for this issue; revisit (b)/(c) only if similar reports appear for other agents.

Once you answer, we can turn this into an implementation issue (or close it if the existing Environment Variables workaround is enough for your case).

1. A
2. A
3. A
4. A
5. A

If there are no more questions then create this as a separate issue and close this one.

Answered: tracking issue #2935 created with the agreed Task Automation checkbox / template defaults.

Thanks @zaakiy — recorded your choices and created issue #2935 for implementation:

1. Checkbox on Task Automation only (next to "Command to Run Task")
2. Show when Command to Run Task contains opencode
3. Checking sets OPENCODE_DANGEROUSLY_SKIP_PERMISSIONS=true only (leave command text alone)
4. Enable the env var by default in Open Code shell/container templates
5. Open Code-specific for now

Closing this question. Please continue any further discussion on issue #2935.