Claude Code Permission Flaw Exposes Sensitive Data: The Risk of Public GitHub Files

A Chain Reaction Triggered by a Single "Don't Ask Again" Option

As AI coding assistants rapidly gain adoption, Claude Code's "Don't Ask Again" permission memory feature has been reported to potentially cause sensitive information leaks. According to a discussion on Hacker News, this option allows users to permanently approve a certain type of operation, thereby bypassing subsequent permission confirmations. The problem is that when users habitually check this option, Claude Code may read and process files containing sensitive content such as passwords and keys without prompting again—and these files are then pushed to public GitHub repositories. The discussion claims that 1,122 public GitHub files have already exposed password information as a result. Although this figure comes from a single source, it is enough to show that the problem is not an isolated case.

Root Cause: The Conflict Between Convenience and Security Boundaries

As an AI coding tool, Claude Code's core interaction depends on access permissions to the file system and command line. To reduce operational interruptions caused by repeated confirmations, it offers a "Don't Ask Again" option that lets users "approve once and for all" for a certain type of operation. From a product experience perspective, this does improve efficiency; but from a security perspective, it turns permission decisions from "confirm every time" into "confirm once, valid long-term." When developers work in a project containing .env files, configuration files, or scripts, a single mistaken choice can give the tool the ability to continuously read sensitive files in subsequent sessions. More critically, if these files are committed to a public repository, passwords and keys will be directly exposed on the internet.

Exposure Path: From Local Files to Public Repositories

According to the description in the discussion, the leak path is roughly as follows: a developer uses Claude Code locally to work on a project and checks "Don't Ask Again," after which the tool gains continuous access to a specific directory or file type; subsequently, files containing passwords are placed under version control and pushed to a public GitHub repository. Since public GitHub repositories are accessible to anyone by default, this sensitive information is in fact fully exposed. The number 1,122 indicates that similar usage patterns are somewhat common among developers. As a side note, this figure comes from a single source and has not yet been cross-verified by other independent channels, so it should be regarded as a warning signal rather than a precise, comprehensive statistic.

A .env file is a plain-text configuration file that stores environment variables. In projects such as Node.js, Python, and Ruby, it is widely used to hold sensitive information that should not be hard-coded into source code, such as database connection strings, API keys, and third-party service credentials. It is usually placed in the same directory as the code, and many frameworks automatically load it at startup. For this reason, AI coding assistants can easily scan it when reading project context. If .env is not listed in .gitignore, a single git add . will bring all its keys into the repository as-is; even if the file is deleted later, records will remain in Git history, and the commit history of a public repository can be cloned and searched by anyone—which is also why this type of leak is difficult to completely eliminate.

Practical Impact on Developers

For developers using Claude Code, this incident reminds us to re-examine the boundary between AI tools and sensitive data. AI coding assistants usually need to read project files to understand context, which means they naturally come into contact with configuration files, environment variables, and scripts. If permission controls are too loose, the tool may inadvertently bring sensitive content into its processing scope. The more hidden risk is that developers often do not check file by file which files the tool has actually read, especially in "Don't Ask Again" mode. Once these files are committed to a public repository, password leaks may go undetected for a long time until they are exploited by malicious scanning.

Recommendations: Take Permission Control Back into Your Own Hands

In response to this risk, developers can take several practical measures. First, use the "Don't Ask Again" option with caution, especially in projects containing sensitive configurations, and try to maintain the habit of confirming each time. Second, add .env, key files, and similar items to .gitignore, and use tools to scan for sensitive information before committing. Third, regularly review the contents of public repositories to confirm that no passwords or tokens have been committed accidentally. Fourth, keep an eye on subsequent permission management updates to Claude Code to see whether more fine-grained control options are provided. For teams, establishing a security check process before code commits is more reliable than relying on the default behavior of a single tool.

.gitignore is Git's ignore rules file. Paths listed in it are not included in version control by default, thereby preventing local configurations, dependency directories, and key files from being committed by mistake. Commonly used sensitive patterns include .env, .env.*, *.pem, *.key, credentials.json, and so on. Note that .gitignore only takes effect for files that have not yet been tracked; if a file has already been committed, you must first remove it from the index with git rm --cached and then commit again, otherwise the ignore rules will not work. In addition, pre-commit scanning can use tools such as gitleaks and trufflehog, which can identify high-risk key strings based on regular expressions and entropy and are suitable for integration into local hooks or CI processes as a last line of defense.

Broader Lesson: Secure Defaults for AI Tools

This incident reflects a common problem in the security design of AI coding tools: convenience features often land before security considerations. "Don't Ask Again" is not a malicious design in itself, but it shifts security responsibility to users, and users find it difficult to remain vigilant at all times in actual operation. For AI tool developers, how to set safer defaults while improving efficiency is an issue that requires constant trade-offs. For developers, understanding a tool's permission model and actively managing sensitive data remain the most effective lines of defense at present. The 1,122 public files are a concrete reminder: in the era of AI-assisted programming, every "approval" of permission deserves an extra moment of thought.

Secure by default means that a product is in a relatively safe initial state when users do not perform any additional configuration—for example, denying high-risk operations by default, applying least privilege by default, and hiding sensitive paths by default. The opposite is "allow by default, let users tighten it themselves," a design that shifts the cost of risk judgment to users, while users in high-frequency operations often tend to choose the path of least resistance. For tools such as AI coding assistants that require broad file access, more reasonable approaches include setting non-bypassable read restrictions on .env and key directories, refining the granularity of "permanent approval" by directory or file type, and providing permission usage logs so developers can audit afterward what the tool actually accessed.

One-line Summary

Claude Code's "Don't Ask Again" option led to password leaks in over a thousand public files, highlighting the risk of AI tool permission defaults.

Paragraph Summary

The article focuses on Claude Code's "Don't Ask Again" permission memory feature, pointing out that this option lets users permanently approve a certain type of operation in one go. Although it improves efficiency, it turns permission decisions from confirmation each time into long-term validity. When developers check this option in projects containing sensitive files such as .env and keys, the tool may continuously read this content, and once these files are committed and pushed to public GitHub repositories, passwords and keys are fully exposed. According to a single-source statistic, 1,122 public GitHub files have already leaked password information as a result. The article outlines the leak path from local approval to public repositories, emphasizes that leaks may go undetected for a long time, and offers practical recommendations such as using the option cautiously, configuring .gitignore, scanning before committing, and regularly reviewing repositories. Finally, it points out that this reflects a common problem in AI coding tools: convenience taking precedence over secure defaults.