Repository navigation
code mode: execute dispatcher bypasses ask permission for nested plugin tools #47177
Closed as duplicate
Description
Summary
In a Code Mode session, plugin tools invoked through the execute dispatcher do not surface the configured ask permission. A mutation tool declared with options.permission mapped to an ask rule executes silently, with no permission prompt in the client.
Environment
- opencode version: 0.0.0-beta-18999 (opencode2, beta channel)
- OS: Linux Cyber-Nekokoya 7.2.2-zen1-1-zen x86_64 (Arch)
- Terminal: TERM=xterm-256color, COLORTERM=truecolor
- Shell: /usr/bin/zsh
- Install/channel: beta (local @opencode-ai/cli)
- Active plugins:
- server (auto-discovered local):
session-tools.ts,systemd-user-tools.ts - cli.json TUI plugins:
./plugins/sandbox-toggle,./plugins/git-write-toggle
- server (auto-discovered local):
Reproduction
- Global
opencode.jsonchas rules such as{ "action": "systemd_user_start", "resource": "*", "effect": "ask" }. - A server plugin exposes a tool with
options: { permission: "systemd_user_start" }viacontext.tool.transform((e) => e.add(...)). - In a Code Mode session, invoke that tool through the dispatcher, e.g. an
executeblock callingtools["systemd_user_start"]({ unit: "wivrn.service" }). - Observe: the unit starts/stops successfully, and the client never shows an
askprompt (nopermission.askedevent; compare with early-session direct tool calls, which did produceasking id=per_...log lines).
Expected Behavior
The docs for the execute action state each nested tool still enforces its own permission. An ask rule should prompt the user (or be rejected when no interactive channel is available).
Actual Behavior
The ask rule is bypassed: mutation tools execute silently through the execute dispatcher. In our session systemd_user_start/stop for wivrn.service ran with no confirmation. Risk: any ask-class plugin tool is unenforced in Code Mode.
Additional Context
- Reproducible consistently via
execute. - Direct (non-dispatcher) tool calls in the same environment do prompt, so the bypass appears specific to the Code Mode dispatcher path.
- No saved "allow always" approval exists for these actions; config rules are intact
ask.
Reacted by Damian Stasik
Activity
github-actions commentedon Sep 4, 2026
This issue might be a duplicate of or closely related to existing issues. Please check:
permission.askplugin hook is defined but not triggered #7006:permission.askplugin hook is defined but never triggered — shares the same root area (plugin tool permissions not being enforced), thoughpermission.askplugin hook is defined but not triggered #7006 covers the hook not firing at all while this issue focuses specifically on theexecutedispatcher path in Code Mode silently bypassingaskrules.CyberNekokoya commentedon Sep 4, 2026
Update: this is broader than the Code Mode dispatcher path. Local server plugin tools bypass the permissions engine entirely — not just the
askprompt, butdenyrules too.Additional evidence (native tool path, not
execute)With a local server plugin exposing tools that declare
options.permission/codemode: false, and global permissions inopencode.jsonc:systemd_user_startwith rule{ action: "systemd_user_start", resource: "*", effect: "ask" }→ executes silently, nopermission.askedevent (client pollingGET /api/session/<id>/permissionreturns 404 the whole time).effect: "deny"→ still executes successfully.effect: "deny"→ also still executes (confirms the engine is not being consulted at all for plugin tools).edit+external_directory=ask) → prompts correctly in the same client/session.Conclusion
Plugin-registered tools are invoked without permission evaluation regardless of
executevs native listing, and regardless ofcodemode.ask,deny, andallowrules have no effect on them. Built-in tools are unaffected. This makes permission enforcement for plugin tools unreliable end-to-end.neriousy commentedon Oct 20, 2026
Thanks for the report and for checking that both ask and deny rules are bypassed on direct plugin calls too. This is the same problem as #50652, where we're tracking plugin-tool permission enforcement; please subscribe there or add your deny-rule findings, which are useful extra details.