What to build
permissionMode is advertised on the workflow authoring surface and read by nobody. It is declared
on AgentCallOptions and on WorkflowAgentDefaults, and workflow.ts documents a precedence rule
for it ("per-call option > workflow's agent default > runtime fallback") — but nothing anywhere
reads either field. The opencode adapter hardcodes permissionMode: "acceptEdits".
A workflow author can set it today, read the doc comment explaining how it resolves, and get
silence. That is worse than not offering it.
Decide and ship one of two outcomes:
- Plumb it — carry it through the same precedence chain
model already uses (per-call →
schedule → workflow → default) down to the adapter, and let it actually change the agent's
permission mode.
- Delete it — remove both declarations and the precedence sentence, so the surface stops
promising something it does not do.
Worth weighing against #24: every run tree now gets an opencode.json with permission: {"*": "allow"} written into it, because a headless permission ask is a permanent deadlock. If the
workspace-level policy is what actually governs permissions, a per-call permissionMode may be
offering control that the workspace config immediately overrides — which would argue for deleting
it, or for making the two consistent rather than independently settable. Establish which of the two
actually wins before choosing.
Acceptance criteria
Blocked by
None (can start immediately).
What to build
permissionModeis advertised on the workflow authoring surface and read by nobody. It is declaredon
AgentCallOptionsand onWorkflowAgentDefaults, andworkflow.tsdocuments a precedence rulefor it ("per-call option > workflow's
agentdefault > runtime fallback") — but nothing anywherereads either field. The opencode adapter hardcodes
permissionMode: "acceptEdits".A workflow author can set it today, read the doc comment explaining how it resolves, and get
silence. That is worse than not offering it.
Decide and ship one of two outcomes:
modelalready uses (per-call →schedule → workflow → default) down to the adapter, and let it actually change the agent's
permission mode.
promising something it does not do.
Worth weighing against #24: every run tree now gets an
opencode.jsonwithpermission: {"*": "allow"}written into it, because a headless permission ask is a permanent deadlock. If theworkspace-level policy is what actually governs permissions, a per-call
permissionModemay beoffering control that the workspace config immediately overrides — which would argue for deleting
it, or for making the two consistent rather than independently settable. Establish which of the two
actually wins before choosing.
Acceptance criteria
permissionModeeither demonstrably changes agent behaviour end to end, or is gone fromAgentCallOptionsandWorkflowAgentDefaultsworkflow.tsmatches what the code doespermission: {"*": "allow"}policy is documented, and the winner is stated rather than left ambiguousbun run checkpassesBlocked by
None (can start immediately).