Skip to content

permissionMode is declared on the authoring surface and read by nobody #39

Description

@FreshlyBrewedCode

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

  • permissionMode either demonstrably changes agent behaviour end to end, or is gone from AgentCallOptions and WorkflowAgentDefaults
  • The precedence documentation in workflow.ts matches what the code does
  • If plumbed: the interaction with Headless runs deadlock forever when opencode asks a permission nobody can answer #24's workspace-level permission: {"*": "allow"} policy is documented, and the winner is stated rather than left ambiguous
  • If deleted: the commit message records why, so it is not re-added as an obvious-looking gap
  • bun run check passes

Blocked by

None (can start immediately).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    taskA single self-contained piece of work that ships as one PR

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions