Configure a Claude Code permissions allowlist that matches how the team actually works

Produce a Claude Code settings.json permissions block for this team's actual workflow, scoped as narrowly as the workflow allows rather than defaulting to broad approval out of convenience.

HOW THIS TEAM ACTUALLY WORKS
A small team using Claude Code for day-to-day feature work on a Next.js app; changes go through a human-reviewed pull request before merging to main, so read, edit, and test cycles are frequent but nothing reaches production without a human looking at the diff first.

ACTIONS THAT SHOULD NEVER REQUIRE A PROMPT (safe, repetitive, no side effect outside version control already reviewed by a human before merge)
Running the existing test and lint commands, reading and editing files inside the repo, running git status, git diff, and git log.

ACTIONS THAT SHOULD ALWAYS ASK, EVEN IF THAT MEANS INTERRUPTING A LONG AGENTIC RUN
Any git commit, git push, or npm install of a new dependency, even on a feature branch.

ACTIONS THAT SHOULD NEVER BE ALLOWED FROM THIS TOOL AT ALL
Any git push --force to main, any rm -rf, any command that reaches a production database connection string, any npm publish.

PRODUCE
1. An allow list of exact tool patterns, not broad categories — a scoped pattern like Bash(npm run test:*) rather than a bare Bash entry that would silently also approve every other shell command the agent might ever construct.
2. An ask list for the always-confirm actions, using patterns specific enough that a close-but-different command is not accidentally caught by the same rule and skipped past confirmation.
3. A deny list for the never-allowed actions, and confirm each entry there could not be satisfied by some other tool or a slightly different phrasing of the same command that the deny pattern does not cover — a deny list with a gap is not a safety measure, it is the appearance of one.
4. For every pattern proposed, one line stating what a slightly broader version of that same pattern would additionally permit, so the actual scope of each rule is visible rather than assumed from its name alone.

CONSTRAINTS
- Do not propose a wildcard pattern anywhere it can be avoided. If a genuinely wide allowance is unavoidable for the workflow to function at all, say so explicitly and name the specific risk being accepted, rather than adding the wildcard silently.
- Cross-check the three lists against each other: flag any pattern that could match under both allow and ask, or under both ask and deny, since an overlapping rule's actual behavior depends on evaluation order the person reading this file will not necessarily know to check.
- If Local developer machines only, not CI — a human is always present to answer an ask prompt. indicates this configuration runs unattended, such as in CI, treat every ask entry as if it will silently block the run rather than pause it, since there is no human present to answer, and flag which entries that would affect.
- Where a pattern could plausibly be satisfied by more than one tool, such as a file deletion reachable through both Bash and a dedicated file-editing tool, cover every route to the same outcome rather than closing only the one that happens to come to mind first.

OUTPUT
The complete permissions JSON block, followed by the scope-visibility notes and any overlap or wildcard warnings.