Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [FEATURE] Named permission preset tiers (UAC-style trust levels) [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48097•Fetched 2026-04-15 06:33:18
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
yiliangs-somyiliangs-som
Participants
yiliangs-somyiliangs-som
Timeline (top)
labeled ×2
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

Claude Code's default permission mode prompts for confirmation on nearly every tool call — file edits, bash commands, reads. For trust-established workflows (e.g., working in a personal repo on a sandboxed machine), this produces a high volume of low-value interruptions. The alternative — manually authoring allow rules in settings.json — requires knowledge of the permission DSL and is not discoverable. Permission modes do exist (normal, auto-accept edits, plan, bypassPermissions) and are accessible via Shift+Tab or --permission-mode, but they are:

Not surfaced as a named, selectable option at session start Not documented with clear semantics about what each mode permits Not configurable as a persistent default without manual JSON editing

Proposed Solution

<html> <body> <!--StartFragment--><p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Introduce a small set of named permission presets that users can select at session start or set as a persistent default, analogous to Windows UAC trust levels:</p> <div class="overflow-x-auto w-full px-2 mb-6"> Preset | Description -- | -- Strict | Prompt on every tool call. Current default. Best for untrusted repos or onboarding. Standard | Auto-allow reads and non-destructive edits; prompt on bash and writes outside the working directory. Permissive | Auto-allow all file operations within the working directory; prompt only on network access and destructive commands. Autonomous | Equivalent to current bypassPermissions. No prompts. Explicit opt-in required. </div> <p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Selection UX options (in order of preference):</p> <ol class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3"> <li class="whitespace-normal break-words pl-2">First-run wizard prompt: <em>"How much should Claude Code autonomously do?"</em></li> <li class="whitespace-normal break-words pl-2">A <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">/trust</code> slash command that switches and persists the active preset</li> <li class="whitespace-normal break-words pl-2">A <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">defaultPermissionPreset</code> key in <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">settings.json</code> that maps to one of the named tiers</li></ol><!--EndFragment--> </body> </html>

Alternative Solutions

No response

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Working on a C# desktop software with no external contributors. The working directory is fully trusted. A typical agentic session involves Claude Code:

  • Reading multiple .cs files across several subsystems to understand state
  • Editing 3–5 files per task (method rewrites, bug fixes, refactors)
  • Running dotnet build to verify compilation
  • Running test scripts via bash

In default (Strict) mode, every one of these operations — including reads — triggers a confirmation prompt. A single task touching 6 files and running 2 build commands produces 8–12 interruptions, none of which carry meaningful security value in a trusted personal repo. The desired mode is Permissive: auto-allow reads and edits within the working directory, auto-allow dotnet build and known dev commands, prompt only if Claude attempts to access paths outside the repo or run network-touching commands. This is a clearly expressible intent that currently requires manually crafting allow rules for every tool pattern — Bash(dotnet *), Edit(src/**), etc. — with no guided path to get there. A named Permissive preset would cover this in one selection at session start, with no JSON authoring required.

Additional Context

No response

extent analysis

TL;DR

Implementing named permission presets, such as Strict, Standard, Permissive, and Autonomous, can simplify the permission management process for users.

Guidance

  • Introduce a set of named permission presets that users can select at session start or set as a persistent default to reduce interruptions and improve productivity.
  • Consider implementing a first-run wizard prompt or a /trust slash command to allow users to easily switch and persist their active preset.
  • Adding a defaultPermissionPreset key in settings.json can provide an alternative way for users to configure their preferred permission preset.
  • Documenting the semantics of each permission mode and preset can help users make informed decisions about their security settings.

Example

No specific code example is provided, but the proposed solution suggests introducing a set of named permission presets, such as:

Preset | Description
-- | --
Strict | Prompt on every tool call.
Standard | Auto-allow reads and non-destructive edits; prompt on bash and writes outside the working directory.
Permissive | Auto-allow all file operations within the working directory; prompt only on network access and destructive commands.
Autonomous | Equivalent to current bypassPermissions. No prompts. Explicit opt-in required.

Notes

The implementation of named permission presets should consider the trade-offs between security and productivity, and the presets should be designed to meet the needs of different user scenarios.

Recommendation

Apply the proposed solution of introducing named permission presets to simplify the permission management process and improve user productivity. This approach can provide a more user-friendly and efficient way to manage permissions, while also reducing the number of interruptions and improving overall user experience.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#installation#tensor shape#autograd error#model save/load#optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [FEATURE] Named permission preset tiers (UAC-style trust levels) [1 participants]