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

[afonsoft]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

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.

[github-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.

[afonsoft]

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.

[github-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.

[afonsoft]

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.

[github-actions]

Thanks for updating the issue with the completed verification checkbox and the required feature-request format.