GitLab warns Claude Code settings file can expose secrets
GitLab has published a guide for finding and removing secrets that may be exposed through Claude Code’s .claude/settings.local.json file. The company says the file can be committed to repositories because its exclusion is stored only in a developer’s local Git configuration.
- Claude Code saves approved commands in .claude/settings.local.json.
- GitLab says 1,122 of 104,185 public copies contained at least one secret.
- Adding the file to .gitignore prevents accidental tracking in future commits.
- Push rules and Secret Push Protection can reject risky pushes.
- Repository history must be checked for files that were later deleted.
How the file can expose credentials
Claude Code, Anthropic’s coding agent, lets a developer approve a shell command by selecting “Yes, and don’t ask again.” The agent then saves that exact command in .claude/settings.local.json and runs it without asking in the future.
GitLab says that if the command contains a password or token, the credential is saved in the file as well. Claude Code keeps the file out of Git through the developer’s personal global excludes, rather than through the repository’s .gitignore. That protection remains on one laptop and does not travel with the repository, so the file can be committed and pushed.
GitLab says its own infrastructure secrets are protected. In early November 2026, Apiiro reported that the issue had resulted in 104,185 copies of the file appearing in public repositories, including 1,122 that held at least one secret. GitLab also says hundreds more secrets were present only in repository history, in files that had since been deleted.
GitLab’s recommended prevention measures
GitLab recommends adding .claude/settings.local.json to every repository’s .gitignore. Premium and Ultimate customers can add the same line to their group’s file templates project, so projects created later inherit the setting.
Premium and Ultimate customers can also use a group push rule to reject the filename wherever it appears in a repository. GitLab provides the pattern (^|/)\.claude/settings\.local\.json$. The rule rejects new additions, but it does not block changes to a file that is already tracked, so existing copies must be cleaned up first. Group rules are copied to projects created afterward and do not automatically apply to existing projects.
Ultimate customers can enable Secret Push Protection, which examines the contents of every push and rejects recognized token formats regardless of the filename. GitLab also recommends a group scan execution policy that runs Secret Detection in every project, including projects without a .gitlab-ci.yml file. A historic scan can check repository history when the SECRET_DETECTION_HISTORIC_SCAN: 'true' variable is used.
Finding current and deleted copies
After prevention is in place, GitLab recommends checking whether the file exists now or existed in the past. Groups with GitLab Duo can ask GitLab Duo Agentic Chat to inspect projects and subgroups, including branches and commit history. GitLab says the resulting table can identify whether a file remains, when it was added or removed, and whether a deleted version contained a secret.
Premium and Ultimate customers without GitLab Duo can use code search, including archived projects. GitLab cautions that code search generally shows the default branch as it exists today, so it will not reveal a deleted file or one stored only on another branch. Checking commit history is therefore necessary to identify past exposure.
For users, the guidance provides a way to prevent accidental commits and investigate both current and historical leaks. For groups, GitLab’s controls combine filename blocking, token detection and scheduled repository scans, with the available options depending on the GitLab subscription and deployment type.
