[Bug]: V2 adapter does not wire a permission authorizer — pty tools bypass permission.bash (deny/ask) rules #80

Summary

In v0.4.0's V2 entrypoint, the PTY tools (pty_spawn, pty_write, ...) execute without consulting OpenCode V2's permission configuration. In V1 host mode the plugin honored permission.bash via its V1PermissionAuthorizer; the V2 wiring omits an equivalent authorizer entirely, so deny / ask rules are bypassable on the pty path.

Evidence (source inspection of the published 0.4.0 package)

• createV2Adapter({ notifier }) constructs the V2 adapter without V2AdapterOptions.permissions.
• installHostAdapter only installs a permission authorizer when one is provided (truthy); the default is none.
• checkCommandPermission / checkWorkdirPermission default to ALLOW when no authorizer is wired.
• By contrast, the V1 path implements exactly this enforcement (V1PermissionAuthorizer honors permission.bash, and ask gates are treated as denied in agent-driven use) — so this looks like an omission in the V2 wiring rather than an intentional design change.

Impact

With a config such as:

"permission": {
  "bash": { "*": "ask", "sudo *": "deny", "rm -rf *": "deny", "*curl*|*sh*": "deny" }
}

commands spawned via pty_spawn / pty_write are not checked against these rules, silently weakening the security posture for users who rely on deny rules for destructive commands.

Suggested fix

Wire OpenCode's V2 permission API into the V2 adapter with the same semantics as the V1 authorizer (consult permission.bash for spawned commands; treat ask as denied in agent-driven use or surface an approval flow).

Environment

opencode-pty 0.4.0 · OpenCode v2.0.26 (V2 plugin runtime). Found during a dependency audit via source inspection of the published package — not a live exploit test. (Related but distinct from #67, which covers the separate V1-default-entrypoint load failure.)