code mode: execute dispatcher bypasses ask permission for nested plugin tools

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

Reproduction

1. Global opencode.jsonc has rules such as { "action": "systemd_user_start", "resource": "*", "effect": "ask" }.
2. A server plugin exposes a tool with options: { permission: "systemd_user_start" } via context.tool.transform((e) => e.add(...)).
3. In a Code Mode session, invoke that tool through the dispatcher, e.g. an execute block calling tools["systemd_user_start"]({ unit: "wivrn.service" }).
4. Observe: the unit starts/stops successfully, and the client never shows an ask prompt (no permission.asked event; compare with early-session direct tool calls, which did produce asking 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.