hidekazu-konishi.com

Claude Code Settings and Permissions Builder and Linter Tool - settings.json allow, deny, and ask Rule Generator and Validator

First Published: 2026-06-24
Last Updated: 2026-06-24

About This Tool

The Claude Code Settings and Permissions Builder and Linter Tool helps you write a safe, least-privilege settings.json for Claude Code. It focuses on the permissions block - the allow, deny, and ask rule arrays, plus additionalDirectories, defaultMode, environment variables, and disableBypassPermissionsMode. Everything runs in your browser; nothing is uploaded, applied, or executed.

Claude Code reads settings from several scopes, in this precedence (highest first): managed / enterprise policy, then command-line arguments, then local project (.claude/settings.local.json), then project (.claude/settings.json), then user (~/.claude/settings.json). Most settings override by precedence, but permission rules merge across scopes: if a tool is denied at any level, no other level can allow it.

When a tool request is evaluated, rules are checked in the order deny, then ask, then allow - the first match wins, and rule specificity does not change that order. If no rule matches, the active permission mode decides.

The schema, rule syntax, and precedence used here were verified against the official Claude Code documentation as of 2026-06-23: Settings, Configure permissions, and Permission modes.

Features

• Builder: Compose allow / deny / ask rules per tool, plus additionalDirectories, defaultMode, environment variables, and disableBypassPermissionsMode, then copy or download a formatted settings.json.
• Validator / Linter: Paste or drop a settings.json to catch JSON syntax errors (with line numbers), schema and type violations, and common pitfalls - over-broad allows, deny rules that shadow allows, ineffective allow globs, non-anchored absolute paths, and ignored Bash forms. Findings are graded Error / Warning / Info and labelled as specification-derived or recommendation.
• Permission Simulator: Enter a request and a permission mode to see whether it is allowed, prompted, or denied, with the deny → ask → allow evaluation trace and the matching rule.
• Presets and samples for least-privilege, project-shared, and intentionally over-permissive configurations.
• Fully client-side: no network calls, no data transmission, works offline once loaded.

How to Use

1. In the Builder tab, add rules: pick allow / deny / ask, a tool, and a specifier (for example Bash(npm run test:*) or Read(./src/**)). Watch the inline lint for warnings.
2. Copy or download the generated settings.json, and place it in the correct scope (project, local, or user).
3. To review an existing file, open the Validator / Linter tab, paste or drop your settings.json, and read the graded findings. Use "Load into Builder" to edit it.
4. In the Permission Simulator tab, choose a permission mode and tool, enter a request, and confirm it is evaluated the way you expect.

Frequently Asked Questions

What is the precedence between allow, deny, and ask?

Rules are evaluated in the order deny, then ask, then allow. The first match in that order decides the outcome, and rule specificity does not change the order. A broad deny therefore blocks even a narrower allow - deny rules cannot carry allowlist exceptions. A matching ask prompts even when a more specific allow also matches.

What is the difference between user, project, and local settings?

~/.claude/settings.json is your personal user-level baseline. .claude/settings.json is committed and shared with the project. .claude/settings.local.json is your personal, gitignored project override. Precedence (high to low) is managed > command line > local > project > user. Permission rules merge across all scopes, and a deny at any scope cannot be overridden elsewhere.

Why isn't my permission rule matching?

Common causes: Bash matching is prefix/exact and not path-aware, and :* is only recognized at the end of a pattern; Read/Edit use gitignore-style globs where a single leading / means project root (use // for an absolute path); WebFetch rules need the domain: prefix; and in allow, unanchored tool-name globs such as * or mcp__* are skipped and approve nothing. The Validator flags these, and the Simulator shows which rule actually matches.

What does a bare tool name in deny do?

Denying a bare tool name with no specifier (for example deny: ["Bash"]) removes that tool from Claude's context entirely. A scoped deny such as Bash(rm *) leaves the tool available and blocks only the matching calls. Use the scoped form when you still want the tool, just not certain commands.

Does this tool apply my settings or send them anywhere?

No. It is entirely client-side: it generates and lints text, runs an approximate simulation, and never applies settings, connects to anything, or executes commands. Nothing you enter is transmitted. The linter and simulator are best-effort aids - always confirm against the official documentation before applying settings.

Related Tools

• MCP Server Config Builder and Validator Tool - build and validate MCP server configuration for Claude Code and other clients.
• JSON Schema Generator and Validator Tool - generate and validate JSON Schemas, useful for tool input schemas.
• JSON Formatter Tool - format, minify, and validate JSON such as settings files.
• Claude Code Hooks Configuration Builder Tool - build and validate the hooks block this tool intentionally leaves out.

Related Articles

• Claude Code Extension Layer Decision Guide - Choosing Among Skills, Subagents, Hooks, and Plugins
• Claude Code Hooks Complete Guide - Deterministic Enforcement Across the Tool Lifecycle

Important Notes

• Claude Code settings and permission rule syntax evolve. The schema and rules used here were verified against the official Claude Code documentation as of 2026-06-23. Always confirm against current documentation before applying settings. This tool does not apply settings or execute anything; permission simulation is a best-effort approximation.
• Prefer least privilege. Allow specific command prefixes and paths rather than whole tools. A broad allow such as Bash or Bash(*) grants wide execution; scope it down.
• deny cannot carry exceptions. Because deny is evaluated before allow, you cannot "allow X but deny everything else like X" with a single broad deny plus a narrow allow - the deny wins. Model exceptions by narrowing the deny instead.
• Argument-constraining Bash patterns are fragile. Rules like Bash(curl https://example.com/ *) are bypassable through option reordering, redirects, or variables. Prefer denying curl/wget and using WebFetch(domain:...) for allowed hosts.
• Never paste real secrets. Keep API keys and tokens out of settings.json examples; use placeholders. Consider deny rules for secret files such as Read(./**/.env) and Read(~/.ssh/**).
• Hooks are intentionally out of scope for this tool. The hooks block has its own structure and lifecycle; the linter recognizes the key but does not build or validate it.