Audit Claude Code Permissions
Audits a repo's tech stack and generates an evidence-based, read-only allow list for Claude Code's settings.json permissions.
Why it matters
Secure your codebase by automatically auditing and generating safe, read-only Claude Code `settings.json` permissions based on your project's tech stack and tooling.
Outcomes
What it gets done
Detect repository tech stack and tooling.
Identify service integrations like Sentry and Linear.
Generate evidence-based Claude Code permission recommendations.
Provide a baseline of essential read-only commands.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-claude-settings-audit | bash Overview
Claude Settings Audit
Analyzes a repository's tech stack, package managers, build tools, and service integrations (Sentry, Linear), then generates a recommended read-only permission allow list for Claude Code's settings.json - combining a safe baseline with stack-specific commands only for what's actually detected. Use it when setting up or auditing Claude Code settings.json permissions for a repository, or replacing an existing permissions baseline with an evidence-based one derived from the actual tech stack rather than a generic template.
What it does
Claude Settings Audit analyzes a repository and generates a recommended read-only permission allow list for Claude Code's settings.json, built from what's actually detected in the repo rather than a generic template. It detects the tech stack (Python, Node.js, Go, Rust, Ruby, Java, build tools, infra, monorepo structure) from indicator files, detects service integrations (Sentry, Linear) from dependency files, checks any existing .claude/settings.json, and combines a baseline set of safe commands with stack-specific ones actually warranted by what's present.
When to use - and when NOT to
Use it when setting up or auditing Claude Code settings.json permissions for a repository, when a safe read-only allow list needs to be inferred from the repo's actual tech stack and tooling rather than guessed at, or when reviewing or replacing an existing permissions baseline with something evidence-based. It's specifically for read-only command permissions - not a general security audit or a way to grant write/destructive access.
Inputs and outputs
Phase 1 detects the stack by listing top-level files and checking for indicators (pyproject.toml/requirements.txt for Python, package.json/lockfiles for Node, go.mod, Cargo.toml, Gemfile, pom.xml/build.gradle, Makefile/Dockerfile, *.tf, and monorepo markers like nx.json/turbo.json/pnpm-workspace.yaml). Phase 2 checks dependency files for service integrations like Sentry (sentry-sdk, @sentry/*, .sentryclirc) or Linear. Phase 3 reads any existing .claude/settings.json. Phase 4 builds the recommendation: a baseline always included regardless of stack (ls, pwd, find, cat, git status/log/diff/show/branch, gh pr/issue/run view and similar read-only git/GitHub CLI commands), plus stack-specific additions only for what was actually detected - e.g. poetry show/uv pip list/pip list depending on which Python lockfile exists, pnpm list/yarn list/npm list depending on the Node lockfile, go list/cargo tree/bundle show/mvn dependency:tree for their respective ecosystems, and docker ps/terraform providers/make -n for detected build/infra tools. For Sentry projects, it also recommends a specific set of Sentry-skills entries, relevant WebFetch domains, and MCP server suggestions (Sentry MCP, Linear MCP) where those integrations are detected.
Integrations
Output is a complete recommended .claude/settings.json (and .mcp.json if applicable) alongside a summary of the detected tech stack, following explicit rules about what to include (read-only, version-check, and inspection commands) versus what to never include (write, destructive, or credential-exposing commands), plus package-manager-specific rules to avoid recommending a tool's commands when a different package manager's lockfile is actually present.
Who it's for
Teams setting up or tightening Claude Code permissions for a repository who want a safe, stack-appropriate read-only allow list derived from what's actually in the codebase, rather than a copy-pasted generic settings.json.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.