Repository navigation
[FEATURE]: LLM command-approval classifier ("auto mode") for permission gating #33585
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
(Closest prior issues, and how this differs, are listed at the bottom — this proposal is distinct in mechanism.)
Describe the enhancement you want to request
Problem. opencode's permission model is per-rule binary: allow (auto-approve), ask (prompt every time), or deny. In agentic sessions there's no middle ground — nothing inspects an actual bash command / webfetch / MCP call and decides "this specific one is safe, don't prompt." Users end up approving constantly, or allow-listing broadly and losing the guardrail.
Proposal. An opt-in classifier (after Claude Code's "auto mode") that gates only the would-auto-approve path: when a rule resolves to allow, consult a model first.
- allow → proceed silently (as today)
- block → deny-and-continue: a tool error the agent reacts to (no halt)
- classifier error / escalation → fail closed (human prompt)
It never overrides an explicit user deny/ask.
Design points (implemented in the reference branch):
- Pluggable backend. Default uses the user's own configured model via the AI SDK (single-pass
<block>yes/no</block>). Pluggable so a local/self-hosted or hosted guardrails model can be slotted in. - Reasoning-blind transcript — the classifier sees only user messages + the bare tool-call payload, never assistant prose or prior tool output (prompt-injection + anti-rationalization defense).
- Full interception path via
Permission.ask— covers edits, webfetch, MCP, task/subagent, external-dir; read-only tools short-circuit before any model call. - Escalation backstop — per-session denial counters (3 consecutive / 20 total), reset each user turn, so a false positive can't loop forever.
classifierconfig block (sibling ofpermission); off by default.
Reference implementation: openguardrails/opencode@feat/auto-mode-classifier (draft PR #33586). bun run typecheck clean; unit tests cover reasoning-blindness, fail-closed parsing, the allowlist, and the policy slots.
Closest prior issues (and how this differs):
- [FEATURE]: Auto-approve safe bash commands using tree-sitter classification #20298 (open) — auto-approve safe bash via tree-sitter classification. Same goal, different mechanism: a deterministic parser vs an LLM classifier covering all tools. Complementary — tree-sitter could be a fast pre-filter ahead of the model.
- [FEATURE]: Add "soft deny" permission action for self-correcting AI behavior #9651 (closed) — a "soft deny" permission action. This reuses the concept as a
soft_denypolicy slot fed to the classifier, not a new action. - [FEATURE]: Dynamic permission scoping via plugin state (permission.ask + structured DeniedError reason) #22558 (open) — dynamic permission scoping via plugin state + structured
DeniedErrorreason. Same hook point (permission.ask); this is a model-driven gate rather than plugin-state scoping, and could share the structured-deny-reason mechanism.
Happy to align with any of these and to the team's preferred shape (naming, config location, experimental-flag gating).
Activity
github-actions commentedon Jun 24, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
[FEATURE]:as required by the Feature Request template (e.g.,[FEATURE]: LLM command-approval classifier ("auto mode") for permission gating)Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
soft_denypolicy slot that overlaps with this closed issuepermission.askfor dynamic gating decisionsIf you believe this was flagged incorrectly, please let a maintainer know.
[-]Proposal: LLM command-approval classifier ("auto mode") for permission gating[/-][+][FEATURE]: LLM command-approval classifier ("auto mode") for permission gating[/+]github-actions commentedon Jun 24, 2026
Thanks for updating the issue! It now follows our contributing guidelines and the needs:compliance label has been removed.
thomaslwang commentedon Jun 28, 2026
Closing — reworked as an external OGR plugin (no core changes) instead of an in-core classifier. See the closed PR #33586 for details and links. A focused follow-up issue for the
permission-hook enhancement (to enable the interactive 'ask the human' path for plugins) will be opened separately.harvzor commentedon Aug 25, 2026
@thomaslwang appears to be mostly an agent talking
This is the original proposal which is a good idea
But them the actual implementation is integrating it with openguardrails, which appears to be SaaS that does the guarding and logging of tool calls
The very idea that this random third party would be integrated into OpenCode is crazy, at least the author changed it into a plugin instead