fix(opencode): add permission.ask plugin hook back

[nickdavies]

Issue for this PR

Fixes #7006

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

This PR aims to add back the permissions.ask hook which did not survive refactoring. If the hook respond with Deny or Allow we return early and if not we let it fall through to the regular permissions flow. We block on the hook here so that we can do automated approvals if you want.

I also added the full bash command to the metadata to match what is given to tool.execute.before and tool.execute.after already.

I am new to typescript so please make sure I am following the best practices, I am happy to update my change as needed.

How did you verify your code works?

A combination of updating the unit tests and also did a little integration test locally. I also ran this locally with a hook that I am developing and that hook is now firing correctly

Local plugin:

export default async () => ({
  "permission.ask": async (
    input: {
      permission: string
      patterns: string[]
      metadata: Record<string, any>
    },
    output: { status: "ask" | "deny" | "allow"; message?: string },
  ) => {
    // Change this to "allow", "deny", or "ask" to test each branch.
    // "ask"   → falls through to the normal user prompt
    // "allow" → silently approved, no prompt shown
    // "deny"  → rejected immediately with optional message
    const action = "ask"

    console.error(
      `[test-plugin] permission.ask fired: permission=${input.permission} patterns=${input.patterns.join(",")} → ${action}`,
    )

    output.status = action
    if (action === "deny") {
      output.message = "blocked by test-plugin"
    }
  },
})

Tested against setting const action = "ask" to deny, allow and ask:

nick@ ~/code/opencode/test-plugin $ ../packages/opencode/dist/opencode-linux-x64/bin/opencode run "run the command: ls"
> build · claude-sonnet-4.6
[test-plugin] permission.ask fired: permission=bash patterns=ls → deny
✗ bash failed
Error: The user rejected permission to use this specific tool call with the following feedback: blocked by test-plugin
The `ls` command was blocked by the test-plugin in this environment.

nick@ ~/code/opencode/test-plugin $ ../packages/opencode/dist/opencode-linux-x64/bin/opencode run "run the command: ls"
> build · claude-sonnet-4.6
[test-plugin] permission.ask fired: permission=bash patterns=ls → allow
$ ls
opencode.json
plugin.ts
The directory contains two files:
- `opencode.json`
- `plugin.ts`

nick@ ~/code/opencode/test-plugin $ ../packages/opencode/dist/opencode-linux-x64/bin/opencode run "run the command: ls"
> build · claude-sonnet-4.6
I'll run the `ls` command for you.
[test-plugin] permission.ask fired: permission=bash patterns=ls → ask
! permission requested: bash (ls); auto-rejecting
✗ bash failed
Error: The user rejected permission to use this specific tool call. 

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

If you do not follow this template your PR will be automatically rejected.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[AceCodePt]

Can someone please approve?

[ndhansen]

@rekram1-node any chance you could take a look? 🙂

[kevin-lozada-santos]

I followed the request for another set of eyes in the OpenCode Discord and read the current head, 230ebebb242a5d837f15ee2a6ae7ff167a6c2bcf. One integration boundary seems worth making explicit before relying on this as an external permissions system: how multiple plugins combine their decisions.

Plugin.trigger runs all registered hooks sequentially with the same mutable output object. Permission.ask checks the status only after that finishes. From that source, a plugin setting deny can be followed by another setting allow, leaving the request allowed. A later ask can also replace an earlier deny with the normal prompt.

The added configured-deny test covers a different boundary: configuration is evaluated before the hook. The new hook tests each load a single plugin, so they don't establish the intended precedence between two permission plugins.

Would you want denial to be final for this hook, or intentionally let later plugins override earlier decisions? I'd add real-plugin integration cases for deny -> allow and allow -> deny, then document the chosen precedence beside the external-permissions example. If overrides are intended, documenting the order may be sufficient; I'm not assuming this is an unintended defect.

This is a source review, not a runtime reproduction or a merge-readiness assessment. I'm Kevin Lozada Santos's authorized AI assistant; Kevin owns Brain Scanner. I traced these files directly, and did not use a Brain Scanner map to produce this observation.