Choosing a Permission Mode for a New Contributor

1. Mode recommendations:

For task (a) — exploring an unfamiliar, business-critical billing service — Plan mode is the right choice. Plan mode lets Claude read files and explore freely (so the engineer benefits from Claude's ability to quickly map out how the service works) but makes zero edits until a plan is explicitly reviewed and approved. Given that neither the engineer nor Claude has established trust in this codebase yet, and a mistake in a billing service is expensive, the priority is understanding before any change happens at all.

For task (b) — writing tests for a small, well-understood tool — Accept Edits mode is reasonable. The engineer already understands the codebase, the blast radius of a bad edit is small (it's a local CLI tool, changes are easy to review with git diff afterward, and file edits are already checkpointed/reversible), and the friction of approving every single edit would slow down what should be fast, iterative test-writing.

2. What goes wrong with Bypass Permissions for onboarding:

Bypass Permissions disables all prompts and safety checks, including for actions that are hard or impossible to reverse — not just file edits. The entire design of the permission-mode system rests on distinguishing reversible actions (local file edits, which are checkpointed and can be undone) from irreversible or externally-visible ones (a destructive shell command, a push to a shared branch, a migration against a real database). A brand-new engineer, still learning both the codebase and how to prompt Claude Code effectively, is precisely the person most likely to give an ambiguous or under-specified instruction that gets misinterpreted — and Bypass Permissions removes every checkpoint that would normally catch that before it causes real, unrecoverable damage. It's explicitly meant for isolated containers/VMs with nothing to lose, not for a live environment during someone's first week. "Saving time" here is trading a few permission prompts for the possibility of an unreviewable, irreversible mistake — a bad trade for a business-critical service.

3. Fixing the repeated npm run test prompt:

This is exactly the situation permission rules are for, independent of mode. The engineer (or a team lead) should add a narrow allow rule for that specific command — something like "Bash(npm run test *)" — to a settings.json file. The right scope depends on who should benefit: if this should apply to anyone working on this repo, it belongs in the project-level .claude/settings.json (committed to git, shared with the team); if it's just this engineer's personal preference for their own machine, it belongs in .claude/settings.local.json (gitignored, personal to them). The important part is that the rule is scoped to the specific test command rather than widened to Bash(*) — narrowly pre-approving a known-safe, repeated command is the intended way to reduce prompt fatigue without giving up the safety property that a genuinely new or risky command still prompts.