GitLab has released a practical guide aimed at teams that host repositories on its platform and use Anthropic's Claude Code, addressing a credential-leak pattern that stems from how the agent remembers approved commands. The company also states that its own infrastructure secrets are protected.

The underlying problem

When a developer approves a shell command in Claude Code and chooses the option to stop being asked again, the agent writes that exact command into .claude/settings.local.json inside the project directory. If the approved command included a password or API token, such as a curl call with a private-token header, the secret is stored in plain text in that file. Claude Code tries to keep the file out of version control, but it does so through the developer's personal global git excludes rather than the project's .gitignore. That safeguard exists only on one machine, so the file is easily committed and pushed once it reaches a shared repository.

According to GitLab, citing research from Apiiro, this behavior led to 104,185 copies of the file appearing in public repositories, with 1,122 holding at least one secret. Hundreds more secrets survive only in repository history, in files that were later deleted but remain retrievable from past commits.

Prevention layers

GitLab proposes four escalating controls, all configured once by a group owner. First, add the file path to .gitignore, and on Premium or Ultimate also add it to the group's file template project so new projects inherit it. Second, use a push rule with a prohibited-filename regular expression so any push adding the file, in any directory or branch, is rejected. GitLab notes two caveats: push rules only check newly added files, not changes to already tracked ones, so existing copies must be cleaned first; and group-level rules apply only to projects created afterward, so existing projects need the rule set individually, either in the UI or via the push rule API (POST for new rules, PUT where one already exists).

Third, Ultimate customers can enable Secret Push Protection, which inspects the content of pushes regardless of file name and blocks known token formats. Self-Managed and Dedicated instances must first allow it at the instance level. Fourth, a scan execution policy on the top-level group can run Secret Detection in every project, even those without a CI configuration, with pipeline-triggered and weekly scheduled scans. Enabling a historic scan variable extends coverage to full commit history.

Assessing existing exposure

The guide then covers discovering where the file exists now or existed before. The fastest option for groups with GitLab Duo is to use Agentic Chat, part of the GitLab Duo Agent Platform, with a prompt asking for every project that ever contained the file, including deleted copies and non-default branches. Duo examines commit history project by project, covers forks, reports the adding and removing commits, flags deleted versions that still contained secrets, and states what it could not check. Because it reads history rather than a search index, it takes several minutes for around a hundred projects but can find deleted copies that search misses. Groups with GitLab Orbit, a knowledge graph, may see the current-copy portion return in about a minute.

Without Duo, Premium and Ultimate users can use code search with archived projects included. Exact code search (GitLab.com paid tiers and Zoekt-enabled Self-Managed) uses a regex file query, while advanced search (Dedicated and Elasticsearch-based installs) uses filename and path filters. Search runs per top-level group, and the groups API can automate iteration across several groups.

Analysis and implications

The incident illustrates a broader risk of agentic coding tools: convenience features that persist user approvals can quietly turn transient secrets into durable artifacts. Responsibility for the safe default arguably lies with the tool vendor, since a project-level ignore entry would have prevented most leaks. Meanwhile, platform vendors like GitLab are positioning their security tooling, push rules, secret detection and AI assistants as the remediation layer for third-party AI agents. The guide also underscores that any leaked token should be treated as compromised and rotated, since deleting a file does not remove it from history. For enterprises adopting AI coding agents, the lesson is to audit agent-generated config files, enforce repository-level guardrails, and scan history, not just current code.