Early on I gave Claude Code broad permissions because asking me about every action was slowing us both down. It felt efficient right up until it proposed a command that would have wiped a directory I cared about. I caught it, barely, and the lesson landed hard: I had removed the fence to go faster, and a fence is exactly the thing that lets you go faster safely.
Settings, and permissions in particular, are that fence. They decide what Claude Code can do on its own, what it must ask about, and what it must never do. Set them well and you get an agent that moves fast on the safe stuff and stops at the edge of the cliff. Set them badly and you get either a nag or a hazard.
Settings tune Claude Code once
Settings.json is a small config file that changes how Claude Code behaves so you do not have to say it every session. Which model to default to. Which tools are available. What hooks run. And the big one, what the agent is permitted to do without asking. You edit it once and the behavior sticks.
Most of the file is quality-of-life. Permissions are the part worth real thought, because they are where speed and safety trade off, so the rest of this guide spends most of its time there.
Where settings live and which wins
Settings exist at three levels, and they resolve in a clear order. Your personal settings apply to just you on this machine. The project's shared settings live in the repo and apply to everyone who works there. Org policy, managed centrally, sits on top and overrides both. Higher up the stack wins.
This order is what makes governance possible without micromanaging. An org can set a hard deny on truly dangerous actions that no project or person can override, while still letting each team and each operator tune the rest to how they work. The fence has a part everyone shares and a part you adjust.
Permissions: allow, ask, deny
Permissions come in three postures. Allow means the agent can do this on its own. Ask means it must check with you first. Deny means it cannot do it at all. Every kind of action, running a command, editing a file, calling a tool, sits in one of these buckets, and the defaults lean toward asking.
The craft is sorting actions into the right bucket for how much you trust them. Reading files and drafting text can be allow. Editing your account list can be ask. Anything that deletes, sends to a person, or writes to production can be deny until you have a specific reason to loosen it. The buckets are how you turn a vague sense of caution into a rule the tool enforces.
- Allow: safe, reversible work the agent should just do, like reading files and drafting.
- Ask: actions that change something you care about, so you see them first.
- Deny: actions that should never happen unattended, like destructive commands or sends.
Build an allowlist that fits your trust
The move that made Claude Code both fast and safe for me was an explicit allowlist: name the specific actions I was happy for it to take alone, and leave everything else to ask. Now it flies through the mechanical work I have blessed and stops to check on anything I have not, which is exactly the behavior you want from a capable colleague.
Grow the allowlist by observation, not optimism. Watch a category of work go well a dozen times, then move it from ask to allow. That way the fence loosens as your trust is earned, rather than starting wide open and tightening only after something goes wrong.
A useful habit is to review the allowlist the way you would review who has admin on a system: occasionally, and with a skeptical eye. An action you allowed during a busy week might be one you would not grant fresh today. Pruning it back to what you actually trust keeps the fence honest, and it takes a minute against the cost of an action you forgot you had blessed.
TipStart narrow and widen by evidence. Promote an action from ask to allow only after you have watched it behave on real work, not because asking is annoying today.
Org policy: guardrails for a team
When more than one person runs Claude Code, org policy is how you set the floor everyone shares. Managed settings can hard-deny the actions that should never happen anywhere, no matter what a project or an individual configures. This is the layer that lets a security team say yes to Claude Code at all, because the truly dangerous doors are locked centrally.
The point of the layering is that it is not all-or-nothing. The org locks the few things that must be locked; teams and people keep the freedom to tune the rest. Good governance here feels like a floor, not a straitjacket.
Settings are config, not a vault
One hard rule cuts across all of this: never put secrets in settings that get committed. Tokens, API keys, and credentials do not belong in a settings.json that lives in the repo, because committing it hands your keys to everyone with access to the code, and to anywhere the repo is mirrored. Keep secrets in environment variables or a secrets manager, and reference them.
This is the mistake that is quiet until it is a disaster. A committed token is not a bug you notice; it is a credential leaked to history, and rotating it after the fact is the cleanup, not the fix. Treat settings as behavior, and keep the keys somewhere built to hold them.
TipIf a value would be dangerous in the wrong hands, it does not go in committed settings. Environment variables and a secrets manager exist for exactly this.
The settings you'll actually change
Beyond permissions, a handful of settings are worth knowing because you will actually touch them. The default model, so a workspace that does heavy analysis starts on a stronger engine and a high-volume one starts cheap. Environment variables, so Claude Code can reach a service without a secret ever living in the file. Hooks, the commands that run on events. And which tools and MCP servers are available in this project.
None of these needs constant fiddling. Set the model default to match the work, point env vars at your services, wire the hooks that protect your data, and leave the rest alone. The best settings.json is one you configured deliberately and then mostly forgot, because it is doing its job without asking for attention.
- model: the default engine for this workspace, matched to the kind of work it does.
- env: environment variables Claude Code can use, so secrets stay out of the committed file.
- hooks: your own commands that run on events, for validation and alerts.
- the tools and MCP servers available in this project.
A GTM permission profile, annotated
Here is a permission setup that fits how most GTM operators actually work, and why each line sits where it does. Reading files and drafting go in allow, because they are reversible and you want speed there, the research and the first drafts should just happen. Writes to the CRM go in ask, because a change to your pipeline should always pass your eyes first, even when you trust the agent, since the cost of a wrong write to the record is high and the cost of a glance is nothing.
The destructive commands and anything that sends to a person go in deny, full stop, until you have a specific, deliberate reason to loosen one. A deleted file or an email that reached a prospect is not something an undo fixes, so those doors stay locked by default. The shape to aim for is fast where it is safe, a checkpoint where it matters, a locked door where a mistake would be expensive, and that maps almost one to one onto read, write, and send.
The GTM version
For a GTM workspace, the settings that matter map straight onto trust. Allow the reads and the drafting, so Claude Code moves fast on research and first drafts. Ask on writes to the CRM and the account list, so a change to your pipeline always passes your eyes. Deny the sends and the destructive commands outright, so nothing reaches a prospect or wipes a file without an explicit, deliberate loosening.
That is the fence that lets you actually delegate. Fast where it is safe, a checkpoint where it matters, a locked door where it must be. Where is the one action in your workflow that should move from ask to deny before you let the agent run unattended?
How to set it up
Open the settings file
Settings live in settings.json. Edit the project's shared file to set team behavior, or your personal one for just you. You can also open it with /config inside Claude Code.
Set permissions to match your trust
Sort actions into allow, ask, and deny. Let it read and draft, check with you on CRM writes, and refuse the destructive and the send outright:
TipStart with a narrow allow list and widen it only after you have watched a category of work behave. Trust is earned action by action.
Keep secrets out of committed settings
Reference credentials from the environment; never paste a token into a settings.json that gets committed. Config describes behavior; secrets live in environment variables or a secrets manager.
Set the org floor if you run a team
If more than one person uses Claude Code, use managed org policy to hard-deny the actions that must never happen anywhere. Everyone inherits that floor, and teams tune the rest above it.
Frequently asked questions
Where are Claude Code settings stored?
In settings.json. There is a personal file for you, a project file in the repo shared with your team, and centrally managed org policy on top. You can edit them directly or via /config.
Which settings win when they conflict?
Org policy overrides the project's shared settings, which override your personal ones. Higher up the stack wins, which is what lets an org set guardrails nobody can quietly override.
What are the three permission postures?
Allow, ask, and deny. Allow lets the agent act on its own, ask makes it check with you first, and deny blocks the action entirely.
How should I set permissions for GTM work?
Allow reads and drafting, ask on CRM and account-list writes, and deny sends and destructive commands. That gives you speed where it is safe and a checkpoint where it matters.
How do I let the agent move faster without opening everything?
Build an allowlist of specific safe actions and leave the rest to ask. Widen it as you watch categories of work behave, so the fence loosens as trust is earned.
Can I put API tokens in settings.json?
No. Never put secrets in committed settings. Committing a token leaks it to everyone with repo access and to history. Keep credentials in environment variables or a secrets manager and reference them.
How does org policy help a security team say yes to Claude Code?
Managed settings can hard-deny the truly dangerous actions everywhere, no matter what a project or person configures. That locked floor is often what makes broad adoption approvable.
What is the single most important setting?
Permissions. They decide the agent's blast radius. Everything else is quality of life; permissions are where speed and safety actually trade off.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 22, 2026; verify time-sensitive details against the official docs above before relying on them.