[FEATURE]: scoped auto-approval mode with expiry, persistent risk indicator and audit trail #51859

Activity

1. github-actions

   assigned

   kitlangton

   on Sep 28, 2026
2. github-actions

   added

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Sep 28, 2026
3. github-actions commented on Sep 28, 2026

   

   github-actionsBot

   on Sep 28, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue doesn't fully meet our contributing guidelines.

   What needs to be fixed:

   • The Feature Request template requires a verification checkbox. Please add and complete the required checkbox; the description itself has substantive content.

   Please edit this issue to address the above within 2 hours, or it will be automatically closed.

   ---

   This issue might overlap with existing requests. Please check:

   • #51399: proposes a user-facing full-auto permission mode, including a confirmation and UI option.
   • #38289: requests a persistent auto-accept indicator.
   • #41909: requests a runtime, per-session permission-mode toggle.

   For keybind-related issues, please also check our pinned keybinds documentation: #4997

   If you believe this was flagged incorrectly, please let a maintainer know.
4. afonsoft commented on Sep 28, 2026

   

   afonsoft

   on Sep 28, 2026

   Author

   More actions

   cc @thdxr @adamdotdevin — requesting triage on this one alongside the broken-toggle bugs it subsumes.

   Priority rationale: auto-approve is requested often (#51399, #41909) and the current web controls are partially broken (#31137 button disabled under new layout, #49721 settings toggle inert — fix already open as PR #49843). Meanwhile the permissive path has real safety regressions open: #47817 (auto-approve leaks across clients on a shared server) and #51504 (ask rules degrading to allow for MCP tools).

   Landing a scoped/expiring/audited grant model would let those five toggle-shaped fixes collapse into one correct mechanism. If the direction looks right, I can draft the design doc/ADR and implementation plan.
5. github-actions commented on Sep 28, 2026

   

   github-actionsBot

   on Sep 28, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for updating the feature description. The issue still needs the completed verification checkbox required by the Feature Request template. Please add and check that box; the title and description otherwise meet the requirements.
6. afonsoft commented on Sep 28, 2026

   

   afonsoft

   on Sep 28, 2026

   Author

   More actions

   Original issue description (preserved before reformatting to the feature-request template)

   Describe the enhancement you want to request

   Scoped auto-approval mode with expiry, a persistent risk indicator, and an audit trail — a user-facing "full-auto" that is explicit about what it does and what it does not do.

   Related prior art (this request is a superset, not a duplicate): #51399 (documented full-auto mode), #38289 (persistent indicator), #41909 (/approve runtime toggle), #31137 / #49721 (the existing web auto-accept control is disabled under the new layout / does not respond), #47817 and #51504 (current auto-approve has cross-client and silent ask→allow degradation problems this design must avoid).

   Today the web UI has auto-accept (permissions.autoaccept, mod+shift+a), but it is client-side only, session/directory-scoped, invisible while active, and has no expiry. What is missing is a deliberate, auditable escalation mode:

   Requirements

   • Opt-in only, with a first-use confirmation explaining that auto-approval is a UX convenience, not a sandbox or isolation boundary (per SECURITY.md, the agent is not sandboxed — the UI copy must never claim otherwise).
   • Explicit scope: per-session (default), per-workspace/directory, or a named allowlist of tools/permission domains (e.g. edit, bash with pattern rules). Never a hidden global.
   • Expiry: TTL in minutes or "until session ends"; auto-revoke at expiry and on server restart.
   • Persistent visual indicator while active (header/badge with countdown), plus one-click kill switch. See [FEATURE][Desktop]: Show a persistent indicator when auto-accept permissions is active, and make the setting a real default for new sessions #38289.
   • Audit trail: every auto-approved request recorded with timestamp, session, action, patterns, and the scope that approved it — queryable, not only in the log file.
   • Guardrails independent of the mode: secrets reads, destructive commands, and external-network tools keep separate rules; ask rules must never silently degrade to allow (see permissions: ask rules for MCP tools are silently degraded to allow #51504).
   • Isolation between clients: a mode enabled in the web UI must not auto-approve requests originating from other clients attached to the same server (see TUI auto-approve mode approves permission requests from other clients attached to the same server #47817). Approval scope should live server-side so all clients agree on it.

   API sketch

   // consent record persisted server-side
   type AutoApprovalGrant = {
     id: string
     scope: { session?: string; workspace?: string; tools?: string[] }
     createdAt: number
     expiresAt: number          // mandatory; no infinite grants
     createdBy: "web" | "tui"   // surface that granted it
   }
   // events: permission.grant.created / .expired / .revoked
   // reply path: permission.reply gains an optional grantID for audit

   Out of scope

   Isolation. Users who need real containment still need a container/VM — the docs for this mode should say so explicitly.

   Benefits

   Repetitive approvals are the top friction point for supervised long-running sessions; doing this deliberately (scope + expiry + audit) instead of a silent "yolo" keeps the security posture honest and fixes the discoverability problem reported in #31137/#49721.

   ---

   Related work — the auto-accept/auto-approve cluster

   Existing surface the mode should build on: permissions.autoaccept command (mod+shift+a), per-session/directory autoAccept store (packages/app/src/context/permission.tsx, permission-auto-respond.ts), and server-side permission config / OPENCODE_PERMISSION env.

   Ref	State	What it reports / fixes
   #51399	open issue	Documented, user-facing "full-auto" mode (Claude Code parity) — the headline request this one refines with scope/expiry/audit.
   #38289	open issue	Persistent indicator while auto-accept is active — adopted here as a hard requirement.
   #41909	open issue	/approve runtime toggle per session — the TUI-side equivalent.
   #31137	open issue	Web "Auto-accept permissions" button disabled when new layout is enabled — discoverability bug.
   #45159	open issue	New layout forcibly disables auto-accept.
   #49721	open issue	Web Settings auto-approve toggle silently does nothing on click/tap.
   #49843	open PR	Fix for #49721 — scopes the web toggle from the route directory.
   #47320	open PR	Auto-accept as an app-level saved setting (closes #37617).
   #23586	open PR	Restores the auto-accept button in the prompt input.
   #46226	open PR	Reflects global permission: allow in the Settings toggle.
   #44608 / #48545	merged PRs	App-level auto-accept setting; TUI session permission handling.
   #51398	open issue	Auto-approve not sticky across long runs — agent stalls unnoticed (TTL + indicator would surface this).
   #47817	open issue	TUI auto-approve approves permission requests from other clients on the same server — the grant model here explicitly prevents this.
   #51504	open issue	ask rules for MCP tools silently degrade to allow — this mode must not mask it.
   #47177 / #50652	open issues	Code-mode and plugin tools bypassing ask — same guardrail family.
   #44007 / #48237 / #48579 / #48142	open issues	Edge cases: --auto stalls background tabs; toggle disabled without session; sound spam; attach lacking --auto.

   Triage note for maintainers

   This is a frequently re-requested capability (#51399, #41909, #38289, plus the broken-toggle bug cluster above) and the current web surface is partially broken (#31137, #49721). A deliberate design (scope + expiry + audit + per-client isolation) would resolve the feature requests and the security-adjacent regressions (#47817, #51504) in one shape instead of five separate toggles.
7. github-actions

   removed

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Sep 28, 2026
8. github-actions commented on Sep 28, 2026

   

   github-actionsBot

   on Sep 28, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for updating the issue with the completed verification checkbox and the required feature-request format.
9. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the detailed proposal, @afonsoft!

   To restate it: you're asking for an auto-approval mode that you turn on deliberately. It would be scoped (to a session, a workspace or an allowlist of tools), always expire, show a visible indicator with a kill switch while it's on, and record every auto-approved request in a queryable audit trail. Grants would live on the server so they don't leak across clients, and ask rules would never quietly become allow.

   This builds on several existing issues rather than repeating one of them, so I've kept it open as a feature request for the maintainers to consider. Closely related:

   • [FEATURE]: Documented, user-facing "full-auto" mode for unattended agents (Claude Code parity) #51399: documented, user-facing "full-auto" mode
   • [FEATURE][Desktop]: Show a persistent indicator when auto-accept permissions is active, and make the setting a real default for new sessions #38289: persistent indicator while auto-accept is active
   • [FEATURE]: /approve — toggle permission approval mode at runtime (on/off, per-session) #41909: /approve toggle at runtime, per session
   • TUI auto-approve mode approves permission requests from other clients attached to the same server #47817: auto-approve in one TUI approving requests from other clients on the same server
   • permissions: ask rules for MCP tools are silently degraded to allow #51504: ask rules for MCP tools silently degrading to allow

   Part of this could be prototyped with the v2 plugin permission hook, which lets a plugin decide on permission requests itself. A plugin could auto-allow requests while a time-limited grant is active and keep its own log. The indicator in the web app and TUI, grants shared by all clients and the audit fields on replies would still need changes in OpenCode itself.