How to Use Claude Code's /fewer Permission Prompt to Build a Custom Allow List
The /fewer permission prompt scans your session history and generates a tailored allow list for commands you always approve—without enabling full auto mode.
Stop Clicking “Approve” for the Same Commands Every Day
If you use Claude Code regularly, you know the rhythm: you ask it to run a build command, it asks for permission. You ask it to edit a config file, it asks again. You approve the same bash commands and file operations dozens of times per session, and after a while it starts to feel like clicking through the same dialog box over and over.
Claude Code’s permission model exists for good reason — you don’t want an AI agent running arbitrary shell commands without oversight. But there’s a middle ground between approving every single action and flipping on full auto mode with --dangerously-skip-permissions. The /fewer permission prompt is that middle ground.
The /fewer command scans your session history, identifies the commands and tools you’ve been consistently approving, and generates a tailored allow list you can add to your project settings. It’s targeted, reviewable, and doesn’t require handing over blanket permission to everything.
This guide walks through exactly how to use it, what to watch out for, and how to build an allow list that actually fits your workflow.
How Claude Code’s Permission System Works
Before getting into /fewer, it helps to understand what Claude Code is actually doing when it asks for permission.
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
Claude Code acts as an autonomous agent that can read and write files, run shell commands, search the web, and interact with your development environment. Every time it wants to take an action in one of these categories, it checks against a permission model to decide whether to proceed automatically or pause and ask you.
The Four Permission Levels
Claude Code’s permission behavior falls into roughly four modes:
- Default (ask every time) — Claude Code requests approval before any potentially impactful action. This is the safest mode and the default for new sessions.
- Per-session approvals — When you approve an action, you can tell Claude Code to allow it for the rest of the current session without storing that preference anywhere.
- Allow list (persistent approvals) — Specific tools, commands, or patterns are written to your settings file and automatically allowed in every future session.
- Full auto mode — The
--dangerously-skip-permissionsflag bypasses all checks. Useful for trusted CI environments, risky everywhere else.
The allow list lives in settings.json (either globally at ~/.claude/settings.json or per-project in .claude/settings.json). The allowedTools field in that file is where your persistent permissions are stored.
What Triggers a Permission Prompt
Claude Code prompts you when it wants to:
- Execute a bash command (
Bash) - Read from or write to a file (
Read,Write,Edit) - Fetch content from a URL (
WebFetch) - Use a connected MCP tool that isn’t already approved
- Run any tool categorized as potentially impactful by Anthropic’s permission model
Lower-risk operations — like analyzing existing file content it’s already read or generating a code diff for review — don’t require permission because they’re read-only or purely generative.
Why the Default Approval Flow Gets Frustrating
For exploratory sessions or unfamiliar codebases, the default approval flow is genuinely useful. You want to see every action before it happens.
But once you’ve worked with a project for a while, the permission prompts stop being informative and start being friction. You’re approving npm run test every time. You’re approving cat package.json every time. You’re approving git status every time. None of these are surprises anymore — you’d approve them without reading.
The problem with full auto mode is that it removes all oversight at once. You might be comfortable auto-approving git status and npm run lint, but you probably don’t want to auto-approve destructive file operations or arbitrary network requests.
That’s the gap /fewer addresses.
What the /fewer Command Actually Does
The /fewer command is a slash command you run inside a Claude Code session. When invoked, it:
- Scans the current session’s action history
- Identifies which tools and commands you approved (including how many times)
- Generates a specific allow list based on patterns in those approvals
- Presents the proposed additions to your
settings.jsonbefore writing anything
The word “fewer” refers to fewer permission prompts in future sessions — not fewer overall permissions. The command is designed to reduce interruptions for actions you’ve demonstrated you’ll always allow, while leaving everything else subject to the normal approval flow.
It’s a bottom-up approach. Rather than deciding upfront what to allow, you work normally, approve things as they come up, and then use /fewer to codify those real-world choices into persistent settings.
Step-by-Step: Using /fewer to Build Your Allow List
Step 1: Work Normally for a Full Session
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Don’t try to run /fewer five minutes into your first session on a project. The value of the command depends on the quality of the history it’s analyzing.
Work through a representative task — something that involves the typical mix of commands and file operations you’d do on that project. Let Claude Code ask for permission each time. Approve the things you’d always approve. Decline or modify the ones you’d want to review.
A good session for this purpose is one that touches your real workflow: running tests, reading config files, editing source code, checking git state, installing dependencies. If you only do one narrow task, your allow list will only reflect that slice of work.
Step 2: Run /fewer
At any point after you’ve accumulated some session history, type:
/fewerClaude Code will analyze the session and respond with a summary. You’ll see something like:
- A count of how many distinct tool invocations happened
- Which ones you approved every time they appeared
- Which ones you declined or modified at least once
- A proposed addition to your
allowedToolsconfiguration
Commands or tools you declined even once are excluded from the proposal. The assumption is that inconsistent approvals mean the action is context-dependent and shouldn’t be auto-approved.
Step 3: Review the Proposed Allow List
This is the part most people skip, and it matters.
Before accepting the proposal, read through every entry. Claude Code is inferring patterns from your approvals, but it can’t read your mind. A few things to watch for:
Overly broad patterns — If Claude Code approved several file edits and proposes Edit(*) as the pattern, that’s much broader than you probably intend. You might want Edit(src/**, *.ts) instead of blanket edit access.
One-off commands — Sometimes you approve something once during a session that you wouldn’t want auto-approved going forward. A database migration command, for example, or a destructive cleanup script. If you see it in the proposal, remove it.
Shell command patterns — Bash is the tricky one. Bash(npm run test) is specific and safe. Bash(npm run *) is broader. Bash(*) is essentially auto mode for the terminal. Be precise.
Step 4: Accept, Edit, or Reject
Claude Code gives you three options at this stage:
- Accept — Write the proposed entries directly to your
settings.json - Edit — Open the proposal for modification before writing
- Reject — Discard the proposal without changing any settings
Choose Edit unless you’re confident the proposal is exactly right. Take five minutes to tighten up the patterns before committing them.
Step 5: Verify the Settings File
After accepting, check your settings.json directly:
{
"allowedTools": [
"Bash(npm run test)",
"Bash(npm run lint)",
"Bash(git status)",
"Bash(git diff)",
"Read(**)",
"Edit(src/**)"
]
}Confirm the entries match your intentions. If something looks off, edit the file directly — it’s plain JSON and easy to modify by hand.
Managing Your Allow List Over Time
Project-Level vs. Global Settings
Claude Code supports two settings scopes:
- Global (
~/.claude/settings.json) — Applies to every Claude Code session on your machine - Project-level (
.claude/settings.jsonin your project root) — Applies only when working in that project
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
Use project-level settings for project-specific tools and commands. Use global settings for things that are genuinely universal — like Read(**) if you’re always comfortable with file reads across any project.
Be careful about putting too much in your global settings. An allow list that made sense for one project might be too permissive when applied to another.
Re-running /fewer After Workflow Changes
Your allow list isn’t a one-time setup. As your project evolves, so do your workflows. New dependencies, new test commands, new CI scripts — these will generate new permission prompts.
Run /fewer periodically after significant workflow changes. It’s also useful when onboarding to a new project: spend a couple of sessions working with full approval prompts, then use /fewer to lock in what you’ve learned.
Removing Entries You No Longer Need
You can remove entries from settings.json manually at any time. There’s no in-Claude-Code command for deletion — just open the file, remove the line, and save. Claude Code reads the settings at session start, so changes take effect on your next session.
Common Mistakes to Avoid
Allowing Too Much Too Early
Running /fewer after a single short session can produce a proposal that’s either too narrow (missing important commands) or too broad (based on approvals you made without thinking). Work through at least one full, representative session before using the command.
Accepting Bash(*) Patterns
If /fewer ever proposes Bash(*) or any unrestricted bash pattern, reject it. That’s effectively the same as --dangerously-skip-permissions for shell access. Always specify the exact commands or at minimum constrain to a safe prefix.
Committing .claude/settings.json Without Review
If your project-level settings are committed to version control, every team member who works with Claude Code will inherit your allow list. That can be useful for sharing team-wide conventions, but it means your personal approval habits might apply to the whole team. Review carefully before committing, and consider whether .claude/settings.json should be in .gitignore.
Forgetting About MCP Tool Permissions
If you’re using Claude Code with connected MCP servers, those tools also appear in the permission flow. The /fewer command will capture MCP tool approvals in its analysis. Make sure you understand what each MCP tool does before adding it to your allow list — a broad approval for a powerful MCP tool can have significant consequences.
Where MindStudio Fits for Teams Building with Claude Code
Claude Code is excellent for individual developers, but teams working with AI agents at scale often need something more structured — especially when it comes to exposing reliable, reusable capabilities that multiple agents can call.
MindStudio’s Agent Skills Plugin is worth knowing about here. It’s an npm SDK (@mindstudio-ai/agent) that lets Claude Code — or any AI agent — call over 120 typed capabilities as simple method calls. Think agent.sendEmail(), agent.searchGoogle(), agent.runWorkflow(), or agent.generateImage(). MindStudio handles the infrastructure layer: rate limiting, retries, and auth are all abstracted away.
Remy doesn't build the plumbing. It inherits it.
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
For teams that have built complex internal workflows — approval processes, data enrichment pipelines, reporting tasks — MindStudio lets you expose those as callable agent skills. Claude Code can then invoke them through the SDK instead of trying to replicate that logic through raw bash commands or ad hoc API calls.
This is relevant to the permission topic because structured tool calls through a typed SDK are much easier to reason about from a permission standpoint than raw bash access. Instead of allowing Bash(curl -X POST https://internal-api/process), you’re allowing a named, typed method that has documented behavior. That’s easier to put in an allow list with confidence.
You can try MindStudio free at mindstudio.ai.
Frequently Asked Questions
What is the /fewer command in Claude Code?
/fewer is a slash command that analyzes your current session’s approval history and proposes additions to your allowedTools configuration. It identifies commands and tools you’ve approved consistently and generates a targeted allow list, reducing future permission prompts without disabling the permission system entirely.
How is /fewer different from —dangerously-skip-permissions?
--dangerously-skip-permissions bypasses all permission checks for an entire session — every tool invocation proceeds without approval. /fewer builds a specific, reviewable allow list of only the commands you’ve actually approved before. Everything not on the list still requires manual approval. It’s a targeted reduction, not a blanket bypass.
Where does Claude Code store allowed permissions?
Permissions are stored in settings.json. This file can exist globally at ~/.claude/settings.json (applies to all sessions) or at the project level in .claude/settings.json (applies only to that project). The allowedTools array in that file contains the approved tool patterns.
Can I manually edit my Claude Code allow list?
Yes. The settings.json file is plain JSON. You can open it in any text editor, add or remove entries from allowedTools, and save. Changes take effect the next time you start a Claude Code session. You don’t need to use /fewer to manage the list — the command just automates the initial generation.
What happens if I approve something once but decline it later?
If you’ve approved an action at some point but declined it in the same session at least once, /fewer will exclude it from the proposal. The command treats inconsistent approvals as a signal that the action is context-dependent and shouldn’t be auto-approved. This is intentional behavior — it’s biased toward caution.
Is it safe to commit .claude/settings.json to version control?
It depends on what’s in it. Committing project-level settings can be useful for sharing conventions across a team. But your personal approval history might not translate to appropriate permissions for every team member. Review the file carefully before committing, and consider whether the allow list reflects team consensus or just your individual workflow habits.
Key Takeaways
- Claude Code’s permission system has four levels — default, per-session, allow list, and full auto. The allow list is the sweet spot between constant interruptions and unconstrained access.
/feweranalyzes your session history and proposes specific allow list additions based on commands you’ve actually approved — not just anything Claude Code might ever want to run.- Always review the proposal before accepting. Edit overly broad patterns, remove one-off commands you wouldn’t want auto-approved, and never accept an unrestricted
Bash(*)pattern. - Use project-level settings for project-specific permissions and global settings sparingly. Think carefully before committing
.claude/settings.jsonto version control. - Re-run
/fewerafter significant workflow changes to keep your allow list current without accumulating unnecessary permissions.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
If you’re building more complex agent workflows on top of Claude Code — or want a structured way to expose reusable tools to AI agents across your team — MindStudio’s Agent Skills Plugin is worth exploring as a complement to what Claude Code does natively.
