AI Coding Assistants Leak Sensitive Credentials Through Local Configuration: Causes and Prevention

Where the Problem Comes From

AI coding assistants usually ask for user approval before executing shell commands. To reduce repeated confirmations, many tools offer an “approve and remember this rule” option. When the user clicks it, the rule is saved to a local settings file, generally in JSON format, similar to the following:

{
  "permissions": {
    "allow": [
      "Bash(mysql -u admin -p'<REDACTED>' -h db.internal ...)"
    ]
  }
}

The example above is a fictional placeholder. Do not use real credentials.

The problem is that the tool saves the original command text. If the command contains a database password, API token, private key passphrase, or root credential, that content is written verbatim into the settings file. Once the file enters a public code repository, the sensitive information becomes public with it.

This is not an isolated mistake by individual developers. Public security discussions and scan results show that such settings files have indeed been uploaded to public code repositories, and some contain credentials that can be used directly. The default behavior of the tools and the team’s submission workflow together produce this result, so protection needs to start at the process level.

How the Leak Chain Forms

1. Rule Files Store Plaintext Credentials

The purpose of rule storage is to reproduce execution intent, so commands are usually not redacted. Passwords and tokens that appear on the command line enter the settings file. This is the starting point of the entire chain.

2. A Global gitignore Is Not a Substitute for Repository-Level Ignores

Many tools recommend adding the settings file to the developer’s global gitignore in their installation documentation. Global rules apply only to the current user on that machine and have the following blind spots:

• Global rules are not written into the repository’s .gitignore. When the repository is cloned to another machine, or when a collaborator does not have the same global configuration, the protection fails.
• The directory may be initialized with git init later. After a folder that was not originally a repository is initialized as one, the individual’s global rules may still take effect, but other team members’ environments may not have the same configuration.
• Forced additions bypass ignore rules. git add -f can bypass ignore rules.

3. Automated Commits Amplify the Risk

Under certain versions and configurations, some tools may include changes to the settings file in a commit. If users do not inspect the staging area item by item, they may commit sensitive content without knowing it. The specific behavior depends on the tool version and settings, so it is advisable to test and verify it in your own environment.

In addition, deleting a file does not end the risk. If others have already cloned or forked the repository, old commits still contain the original file, and sensitive content can also be found in the history.

4. Slow Response from Feedback Channels

In public issue feedback for some tools, people reported cases such as “the settings file is not added to the ignore list” and “sensitive commands are written to a file that is not protected by git” long ago. Some reports were closed after long periods without progress. The priority and response time for security issues need to be designed separately and should not be placed in the same queue as ordinary feature requests.

Impact Assessment

• Credentials are permissions. Once a database password or cloud API token leaks, an attacker may be able to access internal network resources directly. Many long-lived credentials do not expire, so the risk lasts for a long time.
• Deleting a file does not close the risk. Forks of public repositories, cloned copies, hosting platform caches, and archives may all retain the original content. The correct approach is to rotate credentials first, then handle repository files and history.
• Organization-level exposure. Once connection strings, internal domain names, and service topology are leaked, they provide intelligence for targeted attacks.

Protection Practices

1. Explicitly Declare Ignore Rules in the Repository

Do not rely only on a global gitignore. In each repository’s .gitignore, specify the exact file name; refer to the documentation of the tool you use for the file name:

# AI tool local settings; refer to the tool documentation for the file name
.claude/settings.local.json
# Sensitive configuration and keys
.env
.env.*
secrets/

After writing the rules, verify that the ignore rule takes effect with the following command:

git check-ignore -v .claude/settings.local.json

If the file is already tracked, the ignore rule no longer applies to it. You need to remove it from the index first while keeping the local file:

git rm --cached .claude/settings.local.json
git commit -m "Stop tracking local tool settings file"

Teams can add a check step in CI to confirm that critical paths are not included in version control.

2. Pre-Commit Interception and Server-Side Fallback

Client-side pre-commit hooks can intercept changes before a commit is created.