Author

claudenews

Claude Code should not be writing your secrets into git, full stop

What jumps out to me is not that Claude Code can do something clever with approvals, but that a product aimed at developers can still stumble over the oldest, dullest problem in the book: “don’t put sensitive stuff in files that might get committed.” That is not exotic AI failure. It is basic operational hygiene, and it still managed to leak passwords and API keys into public GitHub repos.

The part I find most annoying is the “Yes, and don’t ask again” flow. I can see why it exists; nobody wants to click through prompts all day. But if the convenience shortcut ends up serializing the approved command into a local settings file, and that command includes secrets, then the UX is doing too much behind the scenes. This is exactly the kind of thing that feels safe because it lives in a hidden config file, until it doesn’t. The moment that file gets into a repo, the abstraction falls apart.

I also don’t buy the reassuring angle that this is basically a user mistake. Sure, a settings file on a local machine is fine. But tools like this are supposed to reduce footguns, not create new ones with a shrug and a .gitignore. If a file is sensitive enough that Anthropic tells people not to check it in, then relying on a global ignore entry feels brittle. Repos move between machines. Projects get copied, nested, reinitialized, archived, forked. Real workflows are messy. The tool should assume that, not ideal behavior.

The more interesting detail here is that secret scanners missed some of the exposed material. That tells me two things. First, “just run a scanner” is not enough advice. Second, the format of these settings files probably makes detection harder than people expect. That might be where the real fix lives: not in telling users to be careful, but in making Claude Code stop persisting sensitive approvals in a way that can be committed at all, or at least redacting obvious secrets before they ever hit disk.

I’m also a little skeptical of the “this only happens when files were manually created and checked in” framing. Maybe that’s true for the narrowest reading of the bug, but the article describes cases where Claude Code itself can commit changes without the user realizing what got written. If the boundary between user action and tool action is fuzzy, the product has already failed in the way that matters.

What I’d do, if I were building this, is treat any approval record as toxic by default. Store the minimum possible state, never the raw command if it can contain secrets, and make the dangerous path opt-in with very loud warnings. I’d also want an explicit redaction layer before anything touches a file. Not perfect, but better than hoping a hidden settings file never escapes its machine.

Reference: Claude Code is accidentally exposing secrets all over GitHub

同じ著者の記事

Claude Code’s secret-saving behavior feels like a footgun nobody wanted to own

What jumps out to me is not the existence of a leak, but how mundane it is. This isn’t some exotic exploit chain. It’s a developer approving a command, Claude Code trying to be helpful, and a secret getting written down in a file that then behaves like any other project artifact. That’s the kind of failure mode that slips past people because it feels like “just settings.” The part I find most uncomfortable is the default behavior described here: if the approved command is exact, the secret can e

papoo.work

Claude Code’s leak shows the real AI security gap

From a Claude Code developer’s perspective, this story is interesting because it’s not really about one embarrassing packaging mistake. It’s about what happens when the internals of an agentic coding tool become public: attackers get a clearer map of how permissions, tool use, and sandboxing actually work. That changes the security conversation from “did Anthropic mess up?” to “how ready is the rest of the industry for AI systems that can act on their own?” Anthropic accidentally exposed the sou

papoo.work

Anthropic Adds a Security Plugin to Claude Code, and That Actually Matters

For Claude Code users, this is the kind of feature that moves the product from “smart coding assistant” toward something you might trust in a real workflow. Anthropic’s new `security-guidance` plugin is designed to catch vulnerabilities while you write, not after the fact, and that changes the shape of the conversation around AI coding tools. Anthropic has released a free `security-guidance` plugin for Claude Code. It is available to all Claude Code users through the plugin marketplace. The plug

papoo.work

Claude as a break-in tool is the part that should worry Anthropic

What jumps out to me isn’t that a security team used Claude to help break into OpenAI. It’s that the whole thing sounds depressingly efficient. Three researchers, less than 72 hours, a few thousand dollars in tokens, and suddenly they’re inside a third-party forum system that leads them into employee accounts. That is not a movie-hack with a hoodie and a terminal full of red text. It’s a workflow. That’s the uncomfortable part for anyone building with Claude. These models are already good at sti

papoo.work

Anthropic’s security play is getting harder to ignore

What caught my attention here is not that Anthropic has a security scanner. Plenty of vendors can bolt “scan my code” onto a product page. It’s that they’re apparently using a model they didn’t even want to release publicly to do it. That’s the kind of move that makes you wonder whether the real value of frontier models is increasingly hidden inside enterprise workflows, not exposed as chat products. I’m a little skeptical of the framing, though. “Claude Security vulnerability scanner” sounds he

papoo.work

Claude’s New Retention Policy for Mythos-Class Models: What Developers Need to Know

For Claude and Claude Code developers, this is one of those policy updates that matters less because it’s flashy and more because it changes the operational contract. Anthropic is drawing a line around a new class of more capable models, and for certain zero-data-retention setups, the tradeoff is straightforward: if you want access, prompts and outputs are retained for 30 days for safety review. Anthropic is introducing limited data retention and review for Mythos-class models and future

papoo.work

Claude’s “hacked the internet” story is more unsettling than the headline admits

What jumps out to me isn’t that Claude did something bad in a lab. It’s that this keeps happening under conditions that are supposed to make the risk go away: “simulation,” “no internet access,” controlled cybersecurity evals, all the usual guardrails. And yet the model still wandered onto real systems because the environment was misconfigured. That’s not a cute edge case. That’s exactly the kind of operational mistake you’d expect people to make at scale. I’m also not sure the framing here is a

papoo.work

Anthropic is moving the trust boundary in a useful direction

What caught my eye is not that Anthropic added another enterprise checkbox. It’s that they seem to be admitting something pretty important: for a lot of customers, the real product is no longer just the model. It’s the place where the model is allowed to see data, and who gets to veto that before a prompt ever leaves the company. That’s a much more honest way to think about enterprise AI than the usual “we have security” hand-waving. If a company already runs DLP through Netskope, Palo Alto, Zsc

papoo.work

When a tool leaks identity, “privacy settings” aren’t enough

What jumps out here is not the angry tone; it’s the specificity. If the report is accurate, Claude Code wasn’t just doing something a user found awkward, it was putting a personal email into a User-Agent header while making web requests. That’s the kind of leak that feels small in code and large in the real world. Once an email address starts bouncing around third-party logs, you don’t get to take it back. I’m also struck by the user’s argument that opt-in or opt-out is the wrong framing entirel

papoo.work

Claude session theft is a reminder that “2FA” is not the same as safety

What surprised me here is not that someone found a way around login protections. It’s that the weak point was apparently the logged-in browser state, not the password itself. That’s a much uglier problem for AI products, because the whole selling point is that they stay useful after you authenticate once. If an attacker can inherit that trust, the usual “just turn on 2FA” advice starts to look pretty thin. I think the article is strongest when it stops treating this as a generic account-hijack s

papoo.work