{"slug": "show-hn-opencode-auto-permissions-automatic-review-of-permission-prompts", "title": "Show HN: OpenCode Auto Permissions – automatic review of permission prompts", "summary": "OpenCode released opencode-auto-permissions, a plugin that automatically reviews permission prompts for coding agents, allowing routine actions to proceed while sending riskier operations to a reviewer model. The plugin supports stable and V2 OpenCode permission protocols, never grants permanent 'always' permission, and can be installed via 'opencode plugin -g opencode-auto-permissions'. It combines deterministic safety rules with an isolated reviewer model to judge contextual risks like sudo, scoped deletion, and force push.", "body_md": "Automatic, context-aware permission review for OpenCode. Let routine work run normally, send riskier actions to a reviewer model, and keep coding agents moving while you are away.\n\nThe plugin supports stable and V2 OpenCode permission protocols automatically. It never grants permanent `always`\n\npermission.\n\nInstall the published npm package globally with OpenCode's built-in plugin installer:\n\n```\nopencode plugin -g opencode-auto-permissions\n```\n\nThat is the complete plugin installation. You do not need to clone this repository, install Bun, run `npm install`\n\n, choose a reviewer model, or edit plugin entries manually.\n\nOpenCode downloads the package, detects its separate server and TUI targets, and adds `opencode-auto-permissions`\n\nto:\n\n`~/.config/opencode/opencode.json`\n\nfor the server integration.`~/.config/opencode/tui.json`\n\nfor the V2 TUI integration.\n\nQuit and restart OpenCode after installation because configuration is loaded at startup. Auto Permissions automatically uses the model and variant selected by the session that requested the action. It also detects whether the server or TUI integration owns permission review, so only one reviewer handles each request.\n\nThe recommended setup is not to set every permission to `ask`\n\n. Allow routine work in OpenCode, then use `ask`\n\nfor operations where context matters. Only `ask`\n\nrequests reach Auto Permissions. For example, add risk-based rules to `~/.config/opencode/opencode.json`\n\n:\n\n```\n{\n  \"permission\": {\n    \"bash\": {\n      \"*\": \"allow\",\n      \"rm *\": \"ask\",\n      \"sudo *\": \"ask\",\n      \"git push *\": \"ask\",\n      \"git reset --hard*\": \"ask\",\n      \"git clean -f*\": \"ask\",\n      \"curl * | *sh*\": \"ask\",\n      \"wget * | *sh*\": \"ask\"\n    },\n    \"external_directory\": \"ask\",\n    \"webfetch\": \"allow\",\n    \"websearch\": \"allow\"\n  }\n}\n```\n\nOpenCode uses the last matching permission rule, so keep the broad `\"*\": \"allow\"`\n\nrule first and the narrower `ask`\n\nrules after it. Adapt the list to your environment: deployments, infrastructure commands, package publication, and production database tools are good candidates for contextual review.\n\nTo confirm installation, restart OpenCode and inspect both global files for the package entry. Actions resolved by `allow`\n\nor `deny`\n\nrules will not invoke the plugin; use an `ask`\n\nrule to exercise automatic review.\n\nInstall the latest published version over the existing global entry:\n\n```\nopencode plugin -g --force opencode-auto-permissions@latest\n```\n\nRestart OpenCode after updating. If you use an advanced options tuple, confirm that the server and TUI entries still contain the same options after the update.\n\nThe current OpenCode CLI does not provide a plugin removal subcommand. Remove the `opencode-auto-permissions`\n\nstring or tuple from the `plugin`\n\narrays in both files, then restart OpenCode:\n\n`~/.config/opencode/opencode.json`\n\n`~/.config/opencode/tui.json`\n\nRemove only this package's entries; leave other plugins and configuration unchanged.\n\nFor each supported permission request, Auto Permissions combines deterministic safety rules with an isolated, one-step reviewer model:\n\n- OpenCode handles\n`allow`\n\nand`deny`\n\nrules before the plugin; Auto Permissions reviews requests configured as`ask`\n\n. - Explicit user prohibitions and clearly catastrophic root/home deletion are rejected without model review.\n- Contextual risks such as\n`sudo`\n\n, scoped deletion, force push, deployment, credential access, and external-directory access are judged against the user's request and target scope. - External-directory boundaries are not treated as sensitive by default: ordinary project, tool, cache, log, state, temporary, and worktree paths are approved unless the target or operation presents a concrete hazard.\n- Broad boundary globs such as\n`/tmp/*`\n\nare not treated as the requested scope when the tool input identifies a precise target; the reviewer evaluates the actual operation and latest user request. - The reviewer is tuned for unattended agents: it defaults to approval when an action reasonably serves the task and uses\n`ask`\n\nonly as a last resort. - Reviewer failures and timeouts fail closed: the request is rejected automatically and the main agent receives guidance to continue with a narrower or lower-risk step.\n- Reviewer sessions are hidden, have no tools, and deny all permissions.\n- Only a small, recent window of relevant user context is sent for review.\n- Plugin-authored denial continuations are excluded from that context so an earlier verdict cannot become a self-reinforcing human instruction.\n\nThe reviewer never receives authority to execute the requested action. It always resolves the request by approving once, approving narrow matching requests for the current session, or rejecting with an actionable reason. Session approvals are held in memory by OpenCode and do not persist to later sessions.\n\nReviewer sessions are standalone and deleted after each decision or failure. Startup never deletes reviewer sessions because multiple OpenCode processes may be reviewing permissions concurrently; one process must not delete another process's active review.\n\nAuto Permissions never asks the user to resolve a permission prompt. When the reviewer cannot safely approve, it denies and tells the coding agent why, what safer alternative to try, and to continue autonomously where possible.\n\nDenial and failure continuations preserve the main session's selected agent, model, and variant. A permission decision does not reset the primary agent's reasoning effort.\n\nFor repeatable low-risk operations, the reviewer may choose `allow_session`\n\n. The plugin then uses OpenCode's own tool-provided `always`\n\npatterns, so future matching requests in that session bypass another model call. It never invents or broadens a permission pattern.\n\nCode-side guardrails downgrade `allow_session`\n\nto a one-time approval when patterns are missing or broad, or when the action involves edits, external-directory boundaries, `sudo`\n\n, deletion, push, publish, deploy, credentials, destructive Git, or other non-repeatable effects. Eligible examples include narrow reads/searches and commands such as a specific `git fetch`\n\nor test invocation. Set `sessionApprovals: false`\n\nto force all model approvals to remain one-time.\n\nWhen an action is rejected, Auto Permissions returns the reason to the main agent and asks it to continue with a safer alternative when possible. For example, it can target a generated subdirectory instead of a broad recursive delete, use `--force-with-lease`\n\ninstead of an unrestricted force push, or inspect a deployment plan before applying it. A denial should redirect useful work rather than end the session.\n\nUse OpenCode's three permission outcomes deliberately:\n\n| Rule | Use it for | Plugin behavior |\n|---|---|---|\n`allow` |\nRoutine, expected work that should never wait | OpenCode runs it immediately; the reviewer is not called. |\n`ask` |\nRisk depends on user intent, target, or scope | Auto Permissions reviews context and replies once. |\n`deny` |\nActions that must never run in your environment | OpenCode blocks it immediately; the reviewer cannot override it. |\n\nFor unattended multi-agent work, prefer `allow`\n\nfor ordinary reads, edits, tests, builds, and source-control inspection. Prefer `ask`\n\nover `deny`\n\nfor commands that can be legitimate in the right context. Reserve `deny`\n\nfor firm organizational or personal boundaries.\n\nAvoid an all-`ask`\n\nconfiguration unless you are evaluating the plugin in `shadow`\n\nmode. It adds model latency to every tool call and makes reviewer outages affect routine work.\n\nThe plugin tuple accepts these options:\n\n| Option | Default | Description |\n|---|---|---|\n`model` |\nRequesting session model | Optional dedicated reviewer model in `provider/model` form. |\n`variant` |\nSelected model's default | Optional reviewer-only model variant. Use `\"low\"` when supported for faster decisions. |\n`sessionApprovals` |\n`true` |\nAllow guarded, pattern-specific approvals for the current OpenCode session. Set `false` for one-time approvals only. |\n`timeoutMs` |\n`30000` |\nReview timeout from 100 to 30,000 milliseconds. The default accommodates a cold reviewer startup. |\n`userMessageCount` |\n`8` |\nRecent user messages included in review context, from 1 to 20. |\n`shadow` |\n`false` |\nEvaluate and record decisions without replying to permission requests. |\n`runtime` |\n`\"auto\"` |\nDiagnostics override: `\"auto\"` , `\"stable\"` , or `\"v2\"` . Leave this on `\"auto\"` in normal use. |\n`debug` |\n`false` |\nWrite the latest 100 privacy-minimized outcomes to a JSONL file. Use `true` for the default path or provide a file path. |\n\nStart with `shadow: true`\n\nif you want to observe behavior before enabling automatic replies. Because options are an advanced manual configuration, edit both generated entries so the server and TUI receive identical settings.\n\nNo configuration tuple is required. To override the automatic session-model selection with a dedicated reviewer model, or to use other advanced options, replace the package string in both generated plugin entries with the same options tuple:\n\n```\n[\n  \"opencode-auto-permissions\",\n  { \"model\": \"openai/gpt-5.6-luna\", \"variant\": \"low\" }\n]\n```\n\nKeep the entries in `~/.config/opencode/opencode.json`\n\nand `~/.config/opencode/tui.json`\n\nsynchronized. A fast, reliable model that follows JSON instructions works best; deep reasoning adds unnecessary latency for permission review. Restart OpenCode after changing either file.\n\nWith `debug: true`\n\n, diagnostics are written to `$XDG_STATE_HOME/opencode/auto-permissions/decisions.jsonl`\n\n(normally `~/.local/state/opencode/auto-permissions/decisions.jsonl`\n\n). Records include action type, timing, verdict, reason, reply result, and failure category. Commands, paths, tool inputs, and conversation text are not logged.\n\nAccess to this bounded diagnostics file is deterministically allowed by the plugin so troubleshooting cannot be blocked by speculative sensitivity concerns. This exception applies only to Auto Permissions' own `decisions.jsonl`\n\npath.\n\nReviewer sessions are standalone rather than children of the active coding session. This keeps reviewer model and variant state isolated from the main agent and its displayed reasoning level.\n\nThe plugin does not force a universal reasoning level because variant names differ by provider. Omitting `variant`\n\nuses the selected model's variant. Avoid high or maximum reasoning for permission review unless your policy requires unusually complex analysis.\n\nThe compatibility baseline was acceptance-tested in the real TUI with:\n\n- OpenCode stable\n`1.18.12`\n\n- OpenCode V2\n`0.0.0-beta-202608040144`\n\nThe runtime protocol is detected automatically; stable permission events are handled by the server adapter and V2 events by the TUI adapter. See the [compatibility notes](/hueyexe/opencode-auto-permissions/blob/main/docs/COMPATIBILITY_SPIKE.md) for implementation evidence and known protocol differences.\n\nThis section is only for contributors. Users installing through `opencode plugin`\n\ndo not need Bun or a repository checkout.\n\nDevelopment requires [Bun](https://bun.sh/) and Node.js 22 or later:\n\n```\nbun install\nbun run verify\n```\n\n`verify`\n\nruns strict TypeScript checks, the test suite, a production build, and package export smoke tests. Isolated runtime launchers are also available:\n\n```\nbun run test:stable\nbun run test:v2\n```\n\nThe launchers leave normal OpenCode configuration and session data untouched. See [Testing](/hueyexe/opencode-auto-permissions/blob/main/docs/TESTING.md) for setup and acceptance scenarios.", "url": "https://wpnews.pro/news/show-hn-opencode-auto-permissions-automatic-review-of-permission-prompts", "canonical_source": "https://github.com/hueyexe/opencode-auto-permissions", "published_at": "2026-08-14 06:48:59+00:00", "updated_at": "2026-08-14 07:10:22.972030+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "developer-tools"], "entities": ["OpenCode", "opencode-auto-permissions"], "alternates": {"html": "https://wpnews.pro/news/show-hn-opencode-auto-permissions-automatic-review-of-permission-prompts", "markdown": "https://wpnews.pro/news/show-hn-opencode-auto-permissions-automatic-review-of-permission-prompts.md", "text": "https://wpnews.pro/news/show-hn-opencode-auto-permissions-automatic-review-of-permission-prompts.txt", "jsonld": "https://wpnews.pro/news/show-hn-opencode-auto-permissions-automatic-review-of-permission-prompts.jsonld"}}