External plugin tools bypass configured permissions #50652

Activity

1. github-actions

   assigned

   kitlangton

   on Sep 22, 2026
2. github-actions commented on Sep 22, 2026

   

   github-actionsBot

   on Sep 22, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • code mode: execute dispatcher bypasses ask permission for nested plugin tools #47177: Code Mode execute dispatcher bypasses ask permission for nested plugin tools — identical symptom (plugin tool with options.permission executes without prompting, Code Mode explicitly called out)
   • permission.ask plugin hook is never triggered #47674: permission.ask plugin hook is never triggered — same root cause, hook never fires
   • permission.ask plugin hook is defined but not triggered #7006: permission.ask plugin hook is defined but not triggered — long-standing report of the same missing hook trigger
   • plugin: permission.evaluate ask verdicts are ignored on beta-19151 (deny still honored) #47495: plugin permission.evaluate ask verdicts are ignored — related: plugin verdicts not honored
3. malhashemi

   added 2 commits that reference this issue on Sep 25, 2026

   docs: explain deny and ask rules for computer_use in OpenCode 2.0.16

   ...

   95a8007

   fix: follow the Codex approval policy and drop the approvals option (#3)

   ...

   1afbeaa
4. soar commented on Oct 11, 2026

   

   soar

   on Oct 11, 2026

   More actions

   This is still an issue and needs to be fixed, verified on v2.0.25
5. neriousy

   marked code mode: execute dispatcher bypasses ask permission for nested plugin tools #47177 as a duplicate of this issue on Oct 20, 2026
6. rekram1-node commented on Oct 23, 2026

   

   rekram1-node

   on Oct 23, 2026

   Last edited by rekram1-node

   Contributor

   More actions

   On V2 this is currently expected behavior, though I get why it's surprising.

   The reason we don't auto prompt: for an arbitrary plugin tool, opencode has no idea which inputs matter for a permission decision. Built-in tools know this. shell asks about the command, edit asks about the file path, and "always allow" saves that pattern. For a plugin tool we could prompt on every call, but then "always allow" gets messy. Which parameters are you saving approval for? All of them? Just the tool name? There isn't a good generic answer, so right now the tool itself decides what to ask about.

   So for now, call ctx.permission.assert inside your tool's execute. It's available from v2.0.29 and goes through the same rules, saved approvals and prompt as built-in tools, for direct calls and Code Mode:

   execute: async (input, context) => {
     await ctx.permission.assert({
       sessionID: context.sessionID,
       agent: context.agent,
       source: { type: "tool", messageID: context.messageID, id: context.id },
       action: "demo_create_work_item",
       resources: ["*"],
     })
     // ...
   }

   Use resources (and save) to say what's being approved, for example a project or environment name, so "always allow" saves something meaningful. Docs are in the plugin guide under Permissions.

   We'll probably change this so plugin tools get sensible permission checks by default, so I'm leaving this open for now.

   👍React with 👍1Reacted by Youssef Achy
7. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the detailed report! What you're asking for is that a plugin tool's declared options.permission be checked automatically when the tool runs, so an ask rule prompts before the tool's execute is called, both for direct calls and through Code Mode.

   As mentioned above, this is how v2 currently works by design. options.permission only decides whether a tool is hidden when its action is denied outright. When the tool runs, the tool itself has to request permission. Until that changes, calling ctx.permission.assert at the start of your tool's execute (v2.0.29+) gives you the normal rules, saved approvals and the approval prompt, for direct calls and Code Mode:

   await ctx.permission.assert({
     sessionID: context.sessionID,
     agent: context.agent,
     source: { type: "tool", messageID: context.messageID, id: context.id },
     action: "demo_create_work_item",
     resources: ["*"],
   })

   We're keeping this issue open as the request for plugin tools to get permission checks by default, and maintainers will consider it.

   Related:

   • code mode: execute dispatcher bypasses ask permission for nested plugin tools #47177: same problem in Code Mode, closed as a duplicate of this issue
   • feat(plugin): let plugins assert permissions #54930: added ctx.permission.assert for plugins; enforcing options.permission automatically was left as a follow-up
   • permissions: ask rules for MCP tools are silently degraded to allow #51504: ask rules for MCP tools being treated as allow (a similar gap, for MCP tools)
8. Project579 commented on Nov 7, 2026

   

   Project579

   on Nov 7, 2026

   More actions

   On "sensible permission checks by default": what if a plugin tool that never calls ctx.permission.assert gets a tool-wide check against its options.permission key, but without "always allow"? ask would prompt once per call, deny would block, and nothing would persist, so there's no question of which parameters to save.

   Tools that do their own assert would declare that, e.g. options.experimental.permission: { self: true }, and skip the host check, so there's no double prompt.

   I already have this working on a branch, if the direction sounds right.