Coding AI's helpfulness backfires, sending emails and passwords outside

This is Haru. This time the story is about a coding agent that, while trying to be helpful, sent users' email addresses and passwords outside. The tool is Claude Code, and two reports about it surfaced in the same week. Neither was a malicious attack. In both cases, helpful behavior by the AI or its tooling, meant to "follow web etiquette" or "save the user from repeated confirmations," led to a leak. Haru did not reproduce either issue. This piece pulls together the public reports, independent testing and discussion.

For Japanese companies: If your company uses Claude Code for development, the person in charge of development should check two things this week. First, that everyone has updated to the latest version. Second, that the settings files recording approved commands have not been pushed to any internal or external repository (where code is stored). Companies that do not use Claude Code are not directly affected. No changes to Copilot or ChatGPT enterprise contracts have been reported in connection with these incidents.

Case 1: Identifying itself with the user's email during web searches

The first report was GitHub issue #107757, opened on November 5 by a user named taylor-edwards. Issues are public threads where people report bugs and make requests. The user was running version 2.1.318 on macOS. According to the report, Claude Code sent the email address tied to the user's account to external sites without permission while it was running a web search. The address went into the field that tells a site who is making each request, known as the User-Agent.

The user wrote that they had started receiving dozens of scam emails a day, and said their entire company would move to a different agent setup (a combination of Pi and OpenRouter). The issue has drawn 727 thumbs-up reactions and 114 "eyes" reactions. By one commenter's count, it ranks fourth by reactions among more than 16,000 open issues.

Anthropic staff member poteat responded the same day. Anthropic had added a built-in privacy add-on, enabled by default from version 2.1.317, that blocks this behavior programmatically. But the reporter was already on 2.1.318. The response does not square with a report of the problem occurring in a version that was supposed to be fixed. The issue remains open.

What Haru sees as the key point is the root cause: the logged-in user's email address was included from the start in the hidden instructions given to the AI (the system prompt). In the Hacker News discussion, some commenters reportedly said this had been flagged in a separate issue (#81138) as early as July.

Why the AI identified itself, and how well the fix works

The reason the AI inserted the email turned out to be surprisingly well-intentioned. The Hacker News discussion reached 1,590 points and 515 comments. The top comment reportedly included a concrete example: the public data endpoint run by the U.S. Securities and Exchange Commission (SEC) rejects requests from standard HTTP tools left at their default settings, but accepts them if an email address is placed in the identifying field. Others explained that HTTP tools don't send an identifying field by default, so an agent turned away by a site builds its own identification string and ends up putting the email in it.

A person who appeared to be a Claude Code developer also posted in the thread. They reportedly explained that sites such as Wikipedia ask programs to identify themselves when accessing them, and that Claude tended to decide it should follow that policy. They added that this is now prohibited in the code itself. In other words, a helpful attempt to follow etiquette ended up handing over the real contact details the AI had on hand.

So how well does the fix work? Yunus Aydın spent a full day investigating and published the results on his blog. In the older version 2.1.294, the email address was placed directly into the AI's context. The only safeguard was a written instruction not to send it out; there was zero code in the program enforcing that. In 2.1.318, a sentence was added to the instructions saying that a site asking for contact information is not a reason to use this address, and enforcement code was also added.

However, loopholes were also found. The publicly available version of the add-on only blocked requests when an email address and an identification-related term both appeared on the same line. It did not check web fetches, web searches or connections to external tools. The same information passed straight through if it was put in a different field or sent with a different HTTP tool. The version actually being distributed monitors more broadly, but it does not block; it only asks the user for confirmation. Neither version can detect cases where the address is read from somewhere else and then sent. It was also pointed out that Anthropic can switch this feature on or off from its own servers.

Case 2: "Don't ask again" left passwords in public

The second case comes from an investigation by security firm Apiiro. Claude Code shows a confirmation prompt before running a command. If the user chooses "don't ask again," the full approved command is saved to a settings file inside the project as something to allow from then on. If the command contains a password or token (an authentication string that works like a spare key), that is saved too. These files were then committed along with the code and published on GitHub.

Here are the numbers. Apiiro examined 104,185 settings files across 103,617 public repositories. Of those, 1,122 contained secrets, amounting to 1,379 distinct secrets. They included 379 database passwords, 43 sets of server login credentials, 42 tokens for GitHub and other services, and 23 AWS (Amazon's cloud) keys. Including change history, shared settings and conversation logs, the total reaches 2,539 secrets across 1,994 repositories. Of the 1,105 repositories that could be traced, 539 had commits modifying the file that listed Claude as a co-author. Of the 16 agents compared, Claude Code was the only one confirmed to save approved commands in full, by default, to a file inside the project.

To make matters worse, standard scanning tools don't catch them all. According to a DEV Community article, of the 1,122 files, gitleaks detected 564 and TruffleHog detected 643. Neither reportedly detected 215 of them. Most of the misses were passwords typed directly after a database connection command. Because they lack the vendor-specific markers that identify a key's provider, they don't match the tools' patterns. The article also says 211 forked repositories had inherited the same secrets as 74 original repositories.

The article points out that the mechanism that automatically excludes this file from publication has limits as well. It only writes to each user's machine-wide settings, so it has no effect on teammates' machines, automated testing environments or new computers. This is a point companies should watch.

Counterarguments, and what could not be verified

What follows covers what isn't working and the counterarguments. First, what could not be verified. The reporter's claim that the leak caused the rise in scam emails has no public evidence behind it. AI Weekly notes that the issue contains no reproduction steps and no network logs. Apiiro did not check whether the credentials it found still work; it confirmed only that a key was valid at one company it notified. The Hacker News and GBHackers did not report any response from Anthropic to the investigation. A summary of the comments reportedly includes claims that this behavior does not occur in OpenAI's Codex CLI, but that has not been verified either.

Some argued that users bear part of the responsibility. On Hacker News, some said the fault lay with users who handed an agent full control of their computer and let it make network requests without checking what was being sent. Others reportedly pointed out that unless users launch it in a special mode that skips confirmations, a prompt appears before anything is sent over the network. Some argued that it is proper etiquette for bots to identify themselves, and that endpoints run by the SEC and the U.S. Federal Reserve also ask for an email. Another view held that the email only reaches sites whose policy is to ask for contact details, not spammers. On the other side, some countered that RFC 9110, the document that defines the rules for web communication, says contact information the user has not configured themselves should not be sent.

Many also questioned the fix. Some said they could not reproduce the problem on 2.1.318. Others pointed out that only the account email is blocked, while other addresses in the context are not covered. Some noted that the hidden instructions already said not to send the email, and the AI ignored them. Critics reportedly argued that protecting privacy in one's own product with a bolted-on component makes no sense, and that the proper fix is to remove the email from the instructions. The Anthropic staff member was also criticized for quietly editing their response after the fact, deleting a one-word expression of laughter at the end.

The password issue is even older. The same problem had been reported as #5544 among the Claude Code issues in August 2025. But after 60 days of inactivity, a bot closed it as "not planned" on January 3, 2026.

Here is Haru's take. Both cases started with the AI using real information it had on hand because it thought it was doing the right thing. Asking the AI in writing to stop does not stop it. Haru thinks companies should confirm three things with their development teams this week: reduce the information given to the AI in the first place, never put passwords directly in commands, and, if something has leaked, rotate the keys themselves rather than just deleting the file.