permission.ask workaround: event + reply-call pattern (works today, related to #7006)

[fede-kamel]

Summary

Related to #7006 (permission.ask plugin hook defined but never triggered) — traced that report to the actual source rather than taking it on faith: packages/core/src/permission.ts's assert/ask/reply functions (the real enforcement path, called from bash.ts, edit.ts, write.ts, read.ts, and 7 more tools) have zero references to the plugin system. The hook type in packages/plugin/src/index.ts is real; nothing calls it.

This issue isn't about that bug specifically — it's a proposal for a documented pattern that works today, without waiting on a fix, plus a request to confirm it's the intended way to do this.

The working pattern

Every permission request that needs a decision publishes permission.v2.asked (packages/schema/src/permission.ts), and every plugin gets a full SDK client in PluginInput that can call the same reply endpoint the TUI uses:

POST /api/session/{sessionID}/permission/{requestID}/reply
{ "reply": "once" | "always" | "reject" }

So a plugin can implement automated permission decisions today via the generic event hook (confirmed working) + this reply call, without permission.ask ever needing to fire. A no-op (no reply) leaves the request pending for a human exactly as intended.

What I built and verified

A reference plugin gating tool-call permissions through a three-way admission decision (allow/ask/reject), backed by a locally-served model — gist with the plugin, the full source trace, and what was/wasn't verified:

• Every API shape (Plugin type, PluginInput.client, event hook, permission.v2.asked schema, reply endpoint body) checked against the actual generated SDK/schema code in this repo, not guessed.
• Built the monorepo, ran a real headless opencode serve, confirmed via server logs that a test project's opencode.json (declaring the plugin) loaded correctly.
• Stopped short of a full live agent-turn round-trip in my environment for reasons unrelated to opencode itself (documented honestly in the gist) — the event-subscription + reply-call wiring itself is verified against your real source, not assumed.

Ask

1. Is event + reply-call the intended workaround until permission.ask is wired up, or is there a more direct path I'm missing?
2. Would a PR adding a documented example of this pattern (e.g. under an examples/plugins directory) be welcome, independent of permission.ask plugin hook is defined but not triggered #7006 getting fixed?

Happy to open that PR if useful.

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• No issue template was used. Please resubmit using one of the three required templates: Bug Report, Feature Request, or Question. Based on the two explicit questions at the end, the Question template would be most appropriate here.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of or closely related to existing issues. Please check:

• permission.ask plugin hook is defined but not triggered #7006: permission.ask plugin hook is defined but not triggered — the bug this issue is working around
• [FEATURE]: let plugins gate the auto-approve path via a permission hook in PermissionV2 #34327: [FEATURE]: let plugins gate the auto-approve path via a permission hook in PermissionV2 — directly requests the same underlying capability

If you believe this was flagged incorrectly, please let a maintainer know.

[fede-kamel]

Closing this — decided not to pursue an OpenCode integration/PR after all. Thanks for the project either way; the source-level trace of the permission system was useful groundwork on my end regardless.