fix(permission): trigger permission.ask plugin hook in PermissionNext

[ananas-viber]

Summary

Implements the permission.ask plugin hook that was defined but never triggered in PermissionNext.ask().

Problem

Issue #7006: Plugins cannot intercept permission requests because Plugin.trigger("permission.ask", ...) is never called in the permission system.

This prevents plugins like oh-my-opencode from implementing PreToolUse hooks for:

• Auto-approving safe operations
• Auto-denying restricted file patterns
• Delegation enforcement for orchestrator agents

Solution

Add Plugin.trigger("permission.ask", info, { status: "ask" }) call in PermissionNext.ask() before showing the UI prompt:

• If plugin returns "allow" → auto-approve (continue)
• If plugin returns "deny" → throw DeniedError
• If plugin returns "ask" or unchanged → proceed with existing UI prompt flow

Testing

This change follows the exact same pattern used in permission/index.ts which already has working Plugin.trigger("permission.ask", ...) integration.

Impact

• Enables oh-my-opencode and other plugins to implement PreToolUse hooks
• Backward compatible - no behavior change if no plugin handles the hook
• Unblocks delegation enforcement patterns for orchestrator agents

Fixes #7006

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

Related PR:

• feat(plugin): add optional askPermission to ToolContext

This PR may be related as it also deals with plugin interactions around permission asking in the tool context. However, it appears to be a different approach (adding askPermission to ToolContext) compared to PR #7077 which focuses on triggering the permission.ask hook in PermissionNext.

The other search results only returned PR #7077 itself (the current PR), which is expected.

[ananas-viber]

Clarification: Relationship to PR #6042

After deeper investigation, I want to clarify how this PR relates to #6042:

This PR (#7077) and PR #6042 are complementary, not duplicates:

PR	Purpose	Direction
#6042	Adds askPermission to ToolContext	Plugin requests permission
#7077 (this)	Triggers permission.ask hook	Plugin intercepts permission

Different Use Cases:

• feat(plugin): add optional askPermission to ToolContext #6042: When a plugin tool needs to ask user for permission during execution
• fix(permission): trigger permission.ask plugin hook in PermissionNext #7077: When the system is about to ask permission, and a plugin wants to auto-approve/deny

Note on oh-my-opencode:

The original description mentioned oh-my-opencode PreToolUse hooks. To clarify:

• oh-my-opencode's PreToolUse hooks use the tool.execute.before plugin hook (which already works)
• This PR enables a different hook (permission.ask) for intercepting permission dialogs

Both approaches are valid and serve different purposes in the plugin ecosystem.

[ananas-viber]

Closing this PR after further investigation.

Findings

The original issue (oh-my-opencode PreToolUse hooks not firing) was caused by a different problem: oh-my-opencode's executeHookCommand uses forceZsh: true on Linux but doesn't verify zsh exists before using it. On systems without zsh, hook commands fail silently with exit code 127.

The Fix

The actual fix is in oh-my-opencode, not opencode:

• PR: fix: verify zsh exists before using it for hook execution code-yeongyu/oh-my-opencode#544
• Change: Always verify zsh exists via findZshPath() before using it

Why This PR Isn't Needed

• permission.ask hook (what this PR adds) is only triggered when prompting the user for permission
• tool.execute.before hook (what oh-my-opencode uses for PreToolUse) is already triggered on every tool execution
• These are different hook pathways - the oh-my-opencode fix addresses the actual issue

Testing

Verified with stock opencode v1.1.3 + patched oh-my-opencode:

• PreToolUse hooks now fire correctly for Edit, Read, Glob, etc.
• No changes to opencode required

Apologies for the noise - the root cause investigation led us down the wrong path initially.