klaussy-grant-permissions.\nallowed-tools: Read Edit Bash Grep GlobGrant the permissions a developer needs to work in this repo without a prompt on every routine command, while keeping sensitive files off-limits.
\nPermissions live in your agent's config file, not in memory or preferences — this skill edits that file. It does NOT loosen anything silently: propose the allow-list, show it, then write it.
\nYou're running Claude Code. Write permissions to .claude/settings.local.json (personal, git-ignored) or .claude/settings.json (shared with the team), using a permissions.allow / permissions.deny array of string rules like Bash(git *), Edit(**), and Read(**). Prefer the local, git-ignored file so one developer's convenience list isn't committed onto the team; only write a shared, committed file if the user asks to apply it team-wide. The rule examples below use Claude Code's Bash(...) / Edit(...) form, translate them to your file's shape.
README.md, CONTRIBUTING.md, package.json scripts, a Makefile/justfile/Taskfile.yml, and a scripts/ directory. Capture test, lint, format, type-check, build, and especially the run/dev/start command — that's the one people forget to allow.pyproject.toml / setup.py → python, pytest, ruff, mypy/pyright, pip, uvpackage.json → npm, npx, node, yarn, pnpm (read its scripts)go.mod → go; Cargo.toml → cargo; Makefile → makedocker-compose.yml / Dockerfile → docker, docker composescripts/ directory or a Makefile is the entrypoint in many repos (FastAPI runs bash scripts/test.sh; httpx runs scripts/test, scripts/check, scripts/lint). A Bash(pytest *) rule does NOT cover scripts/test — allow the runner itself (next step) or the tests still prompt.Read, Edit, Write, Grep, Glob (no parens — a bare name allows the tool for any path, and the step-5 denies still win), which is the same baseline klaussy settings writes. On any other agent, translate to its vocabulary rather than copying those names: Gemini gates read_file/write_file/replace/glob/search_file_content, opencode has no per-tool names at all (its permission.read / permission.bash maps cover this instead). The permissions note at the top of this skill names the file and syntax yours actually uses — that wins over the Claude spelling here.Bash(git *)git remote get-url origin: a GitHub host means Bash(gh *), GitLab means Bash(glab *). Bitbucket has no first-party CLI, so there's nothing to add there. The review, address-review, restack, and PR skills all shell out to this one, and it's easy to miss because no marker file announces it.Bash(cd *), Bash(ls *), Bash(pwd), Bash(echo *), Bash(mkdir *), Bash(which *), Bash(cat *), Bash(head *), Bash(tail *), Bash(wc *), Bash(find *), Bash(grep *), Bash(rg *), Bash(sort *), Bash(diff *)Bash(cp *), Bash(mv *), Bash(touch *). rm is deliberately not here — deleting is the one routine command worth a prompt. Add it only on request.Bash(<tool> *) per stack command from step 2 (e.g. Bash(pytest *), Bash(npm *), Bash(cargo *))Bash(bash scripts/*), Bash(sh scripts/*), Bash(./scripts/*), Bash(scripts/*), Bash(make *)Bash(fastapi dev *), Bash(uvicorn *), Bash(npm run dev *), Bash(docker compose *))deny if absent (see the Edit vs Write rule below): Read(**/.env) + Edit(**/.env), and the same pair for **/.env.*, **/.envrc, **/credentials.json, **/.aws/credentials, **/.npmrc, **/*.pem, **/*.key, **/id_rsa, **/id_ed25519. For agents with an ignore file (.cursorignore, .geminiignore), add the secret globs there too — those block Bash reads that per-tool deny rules miss (see safety note).cd and the builtins matter: compound commandsA Bash rule matches by prefix (Bash(git *) matches anything starting with git ). But the agent splits a compound command on &&, ||, ;, and | and checks each segment separately — the line runs unprompted only if every segment matches.
So cd services/api && npm run dev prompts even when Bash(npm run dev *) is allowed, because the cd services/api segment isn't. That's the top reason a \"fully allowed\" toolchain still asks — run, test, and build commands are routinely prefixed with cd. Allowing cd plus the read builtins closes it. Match the syntax exactly: Bash(cd *) with a space before *, not a colon.
Curated mode is a reasonable boundary for a trusted local dev agent, not a security sandbox. Be honest with the user about the line:
\nBash(*)), and prevent accidental edits to secret files via the Read/Edit/Write tools.Read/Edit/Write allow any path the denies don't cover, not just paths inside the repo — an agent working in this repo can still write to your home directory. That's the normal trade for a local dev agent, and path-scoping every rule is what makes an allow-list unusable; but it's a trade, so say it rather than imply a repo sandbox. Same for Bash(cp *)/Bash(mv *): they overwrite without asking.Bash(python *), Bash(pip *), Bash(uv *), and Bash(npx *) all run arbitrary code (a language runtime executes anything; pip install runs a package's setup code). Only allow these for an agent you trust to run this repo's code — which is the normal case for local dev, but say it out loud.deny on Read(**/.env) only stops the Read tool; Bash(cat *) can still cat .env. So the secret-file denies protect Read/Edit, not Bash. If secrets in the repo are a real concern, either don't allow Bash(cat *)/Bash(head *) (read files with the Read tool, which honors deny) or add the secret globs to the agent's ignore file (.cursorignore/.geminiignore), which some agents enforce for Bash too. Don't claim the denies protect against Bash — they don't.source/. (executes an arbitrary file), env/printenv (dumps secrets in the environment), eval, xargs. Add them only on request.For the fewest prompts, accepting the wider blast radius, replace the curated Bash entries with Bash(*), and Edit(**) / Read(**). Keep the step-5 denies (deny wins over allow), and keep the ignore-file globs, since Bash(*) makes the Bash-bypass above trivial. Say plainly that broad mode trusts the agent with arbitrary commands; never pick it by default.
Permission rule strings are OS-agnostic — the same Bash(pytest *) works on macOS, Linux, and Windows. Two things do differ:
cd, ls, cat) still apply. If the user drives commands through native cmd/PowerShell instead, dir/type/Get-ChildItem won't match POSIX rules — allow those variants for that user.Bash(cd services/api *), not a C:\\... path), so the same local file works across a mixed-OS team. That's also why the personal, git-ignored file is the right default target.Edit(<path>), never Write(<path>)Path-scoped rules are matched by the file-permission checker, and (in Claude Code) that checker only understands Edit(<path>) — an Edit rule covers every file-editing tool, Write included. A Write(<path>) path rule (allow OR deny) is silently ignored: it matches nothing, protects nothing, and produces a startup warning.
Edit(**/*.pem). Don't add a redundant Write(**/*.pem) — it only triggers the warning.Edit(**). A bare Write (no parens) in allow is fine; Write(**) as a path rule is not.Edit(<path>) + Write(<path>), the Write(<path>) ones are dead weight — offer to strip them.Bash(rm -rf *), dropping all denies) — surface the risk and confirm first.