How to Set Up Claude Code Permissions for Junior Developers

To set up Claude Code permissions for junior developers, create a .claude/settings.json file in your project root with a permissions object containing allow and deny arrays. List safe commands like test runners in the allow array, and list anything that must never execute — secrets files, package installs, deploy scripts — in the deny array. Because deny rules fire first and block unconditionally, this gives you a reliable safety net even when a junior developer is pairing with Claude in an unfamiliar codebase.

What Problem Do Claude Code Permissions Solve for Junior Developers?

Without a permissions configuration, every file write and shell command Claude attempts requires a manual approval click. That friction is manageable for an experienced developer who knows what to expect, but it creates two opposite problems for junior developers: either they approve everything reflexively (defeating the safety check) or they get overwhelmed and stop using Claude at all.

The permissions system solves this by letting a team lead define safe corridors in advance. Claude can move quickly inside those corridors — running linters, executing tests, reading source files — while genuinely dangerous operations like reading .env files or calling external APIs are caught automatically before execution, with no decision required from the junior developer in the moment.

As the Claude Code security documentation describes it, the system evaluates rules in a strict hierarchy: deny rules fire first and block unconditionally, then allow rules grant silent auto-approval, and anything not matched either prompts the user or is blocked depending on the active permission mode.

How Do You Create the Permissions File?

The configuration lives in a JSON file. There are two locations:

• Project-level: .claude/settings.json in your repository root — checked into version control so every team member gets the same rules automatically.
• Global-level: ~/.claude/settings.json on the developer's machine — useful for personal defaults like always blocking reads of SSH or cloud credential files regardless of project.

Project-level rules take precedence over global ones. For a junior developer onboarding scenario, the project-level file is the right place to start because it travels with the repo and requires no per-machine setup.

Inside the file, add a permissions object with allow and deny arrays. Each entry is a tool-name string, optionally with a parenthesized argument pattern. For example, Bash(npm run test) allows that exact command, while Read(./.env) denies reads of the environment file.

What Does a Real Junior-Developer Config Look Like?

Here is a practical starting configuration for a JavaScript project where you want Claude to run tests and linting but block access to secrets and prevent dependency changes:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(npm run build)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(npm install)",
      "Bash(npm install *)",
      "Bash(npm uninstall *)"
    ]
  }
}

With this config in place, Claude will run npm run test button.test.js automatically without prompting, report the failing tests, fix the code, and re-run — all without interruption. If Claude ever attempts npm install lodash, it is blocked and informs the developer that package installation requires manual approval. If it tries to read .env, it is blocked silently.

How Do Permission Modes Change the Overall Behavior?

Beyond individual allow/deny rules, Claude Code has session-wide permission modes that set the overall posture:

For most junior developer scenarios, the combination of default mode plus explicit allow/deny rules in settings.json is the right starting point. The mode can be set via the CLI or toggled interactively during a session.

How Do You Audit What Rules Are Actually Active?

Because global and project settings merge together, it is easy to end up with a combined rule set that surprises you. Run /permissions in the Claude Code terminal to view the active merged rule set and audit what is currently allowed or blocked. This is especially useful when onboarding a new developer — have them run it at the start of a session to confirm the project rules loaded correctly.

The Claude Code settings documentation explains that URL allowlists and environment variable allowlists merge additively across global and project settings, while permission allow/deny rules follow a precedence hierarchy where project-level rules take priority.

What Are the Most Common Mistakes When Setting Up Permissions?

Wildcard patterns don't match the way you expect

The asterisk in a rule like Bash(npm *) matches a single argument segment — it does not capture all npm subcommands universally. For maximum reliability, list each permitted command explicitly: Bash(npm run lint), Bash(npm run test *), Bash(npm run build) rather than relying on a single wildcard rule. Also note that spacing matters: Bash(ls *) requires a space before an argument, so a command like lsof would not match it.

Assuming deny rules don't apply in bypassPermissions mode

Deny rules are enforced even in bypassPermissions mode — if a deny rule matches, the tool is blocked. This is actually good news for junior developer setups: even if someone accidentally enables a more permissive mode, your deny rules for secrets files remain in effect.

Symlink bypass assumptions

The permission system evaluates both the symlink path and the physical target path. For a deny rule, either path matching is sufficient to trigger a block — so secrets files are protected even through symlinks. For an allow rule, both paths must match. This means you cannot grant access to a symlink and assume the real file is also covered.

Using the wrong flag in headless pipelines

If your team uses CI pipelines, be aware that one common flag triggers an interactive consent dialog on first run — a headless pipeline without a terminal will freeze indefinitely waiting for that confirmation. Use --permission-mode dontAsk or --permission-mode bypassPermissions in CI pipelines instead, as these suppress the consent dialog entirely.

When Should You Use Project-Level vs. Global Settings?

Use project-level .claude/settings.json rules when permissions should be specific to one repository and checked into version control for team consistency. This is the right choice for junior developer onboarding because the rules travel with the repo — no per-machine configuration required, and a team lead can update the rules in a single commit that applies to everyone.

Use global ~/.claude/settings.json for personal defaults that apply across all projects — for example, always blocking reads of SSH keys or cloud credential directories regardless of which project is open. Encourage junior developers to set a global deny rule for their credentials directories as a baseline habit.

Is There an Enterprise Option for Organization-Wide Rules?

For larger teams, Claude Code supports organization-wide permission ceilings configured in Organization Settings. Individual role grants cannot exceed those ceilings, which means a security team can enforce hard limits — for example, blocking SSH-based deploy commands across the entire organization — while still allowing product engineers to freely use tools like the GitHub CLI for pull requests. This is described in the enterprise deployment documentation.

Step-by-Step: Setting Up Permissions for a New Junior Developer

1. Create .claude/settings.json in your project root if it does not already exist.
2. Add a permissions object containing allow and deny arrays. Each entry is a tool-name string, optionally with a parenthesized argument pattern — for example, Bash(npm run test *).
3. Put anything that must never execute in the deny array first. Deny rules take precedence over allow rules unconditionally.
4. Add allow rules for the specific commands Claude should run without prompting — test runners, linters, build scripts.
5. Commit the file to version control so every developer who clones the repo gets the same rules automatically.
6. Have the junior developer run /permissions in the Claude Code terminal at the start of their first session to verify the merged rule set looks correct.
7. For read-only code review sessions, start Claude Code with --permission-mode dontAsk to make it impossible for Claude to modify any files.

This setup gives junior developers the productivity benefits of Claude Code automation immediately, while the team lead retains control over which operations are permitted — without requiring the junior developer to make security judgment calls in the moment.