Organizing Claude Code settings keeps the team aligned. Separate project rules from personal tweaks so the repo stays clean and flexible.
Add to .gitignore:
.claude/settings.local.json
Use the local file for machine-specific tweaks (paths, extra directories):
{
"permissions": { "allow": [], "deny": [], "ask": [] },
"additionalDirectories": ["/Users/you/dev/docs"]
}
Commit .claude/settings.json for org-wide policies (e.g., deny reading .env):
{
"permissions": {
"allow": [],
"deny": ["Read(.env)"],
"ask": []
}
}
Settings combine; they don’t override. A project-level deny cannot be undone by a local allow.
[00:00] Now your settings.local.json should be added to your gitignore. I'll go ahead and create one with the gitignore command. We'll say this is a node project and this just generates one. I'll open it up, gitignore. So just make sure that clod settings.local.json is added in there so that it's removed from git.
[00:21] The reason being that it's quite possible when you're configuring your own settings that maybe you have some documentation you want to add. So let's say an add dir. I want my clod to also be able to look into my dev, kit container, docs directory. And I wanted to remember it for this directory so that now in my settings local json my instance of clod is able to access the docs. So if I clear out the session and I just ask it to please ls the docster, you'll see it has access to that directory and is able to, if I hit ctrl-o, run commands and do things in that directory.
[01:02] Now obviously in other people's machines they won't have this directory set up. They'd want to customize that for themselves and for this specific project. But if you want to hoist something like DENY up into the project level, we can essentially copy and paste this. We'll rename this to settings.json, and this is a file that you would check in. And we're going to remove additional directories.
[01:23] We'll keep readenv, and we'll remove readenv from here. This way this file is checked in and everyone on your project will have the same deny list, and you can have your own custom configuration with your custom paths. If you have custom scripts or custom tools you want to run that are only on your machine you could add those here. And don't necessarily treat your local settings as something that overrides these settings, it's more thinking about it as customizing it for your system. Because if the project level denies this, then adding allow here is not going to override the project level settings.
[02:00] Thanks.