Keep Your Claude Code Overrides Out of a Shared Research Repo
A research repo shared by four people needs the same permissions and hooks for all of them. It does not need your model override, the path to your scratch disk or the approval you gave a one-off command. The same holds in a dark software factory: the shared settings are each station's contract, and a run that only works with one person's local overrides is not a station anyone else can rerun.
Claude Code's settings documentation separates the two. Commit .claude/settings.json so everyone who clones the repository gets the same permissions, hooks and plugins. Put your own overrides for this project in .claude/settings.local.json; Claude Code applies it over the shared file, so only your sessions change.
The docs add a detail worth checking rather than assuming. The first time Claude Code writes settings.local.json in a git repository, it adds the file to your global git excludes. If you created the file by hand, you have to add it to .gitignore yourself. The docs also note that choosing "Yes, and don't ask again" on a permission prompt saves the approval to the local file, so your standing approvals stay yours.
The check. Run three things.
git check-ignore -v .claude/settings.local.jsonThis should print the ignore rule and the file it came from. No output means the file can be committed by accident.
Inside Claude Code, run /status and read the Setting sources line. It lists each settings file loaded for the session, such as User settings or Project local settings. It confirms which files were read; it does not say which file supplied each key.
Finally, clone the repo into a temporary directory and run the setup a new collaborator would. If a hook or a permitted command fails there, the shared file was depending on something only your checkout has. Fix the shared contract, and keep credentials in the secret store they already live in.
A new collaborator's first hour is often the first real test a research repo gets. Make it pass before they arrive.
