Anthropic is working to contain the fallout after accidentally exposing internal source code for its Claude AI coding agent, following a human error during a software update that made proprietary files publicly accessible, which was quickly discovered by a security researcher named Chaofan Shou and posted to X.
The new version of its Claude Code software package unintentionally included a file that exposed nearly 2,000 source code files and more than 512,000 lines of code including tools, techniques, and internal instructions used to guide the behavior of its AI agent. This included operational components of the system and internal frameworks used to control how the AI performs tasks.
Anthropic issued thousands of takedown requests to remove the code from public repositories.
Anthropic said it is implementing changes to prevent similar issues while continuing efforts to remove the leaked materials from circulation.
Michael Bell, Founder & CEO, Suzu Labs had this comment:
“Anthropic shipped a 60MB source map inside their npm package. Every line of Claude Code’s source, all 512,000 of them, publicly available. For the second time. The first leak was February 2025 and the root cause was never fixed.
“We pulled the codebase apart. The headline findings are real but the details are worse. Undercover Mode instructs Claude to disguise itself as a human developer when contributing to open source: “Do not blow your cover.” There is no force-off option. Frustration tracking runs a regex on every user input and silently sends your emotional state to Anthropic’s analytics pipeline without notification or consent. That emotional classification also feeds a system that can prompt users to share their full session transcript with Anthropic, controlled by remote feature flags that Anthropic can activate at any time.
“The finding that matters most for government and defense: the default telemetry collects device IDs, session data, email, org UUID, and process tree information on startup before the user types anything. Environment flags can escalate collection to include full prompts, file contents, bash command output, system prompts, and entire conversation transcripts sent to commercial endpoints. The code confirms FedRAMP OAuth paths to claude.fedstart.com, meaning government deployments share the same codebase. Whether hardening was applied before those deployments is unknown, but the telemetry infrastructure is baked into the foundation. The Pentagon designated Anthropic a “supply chain risk” in March. This is what that risk looks like in code.
“The engineers documented their own attack surfaces in comments. Prompt-injected models can exfiltrate secrets via GitHub CLI URL paths. Leaked GitHub Actions tokens enable “repo takeover” and “supply-chain pivot.” Bash parsing ambiguity allows commands to execute while hidden from security validators. They built mitigations, but the comments confirm the attack surfaces exist.
“The AI safety company with a $380 billion IPO target acquired Bun, whose known source-map-in-production bug was filed publicly and left open while the product shipped to millions of developers. Their operational security posture is a .npmignore file that nobody checked the second time around.”
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs had this to say:
“The model is the engine. What Anthropic accidentally published is the machine built around it.
“Anthropic has been here before. This is the second time Claude Code’s source has leaked through the same vector, a source map file left in the npm package. The first was in February 2025. Thirteen months later, the same packaging mistake exposed a far more complex system, days after the accidental exposure of details about an unreleased model codenamed Mythos.
“The significance of this leak is in what the code reveals about AI agent architecture. The leak exposed approximately 512,000 lines of TypeScript across roughly 1,900 source files. Developers and researchers who have analyzed the source have since documented the scale of what Anthropic built around the model. The code contains what analysts describe as 44 feature flags for unreleased capabilities, approximately 40 permission gated tools, a multi agent coordination system, a persistent autonomous daemon mode, a layered memory architecture, defenses against competitor model distillation, and granular attribution tracking for AI versus human code contributions. The leaked code strongly suggests that the bulk of Claude Code’s production capability comes from orchestration, tooling, memory, and permission layers built around the model.
“The multi agent coordinator mode, as documented in the leaked source, illustrates where the engineering complexity lives. The code describes a system where Claude Code operates not as a single model session but as a supervisor managing a fleet of worker agents executing tasks in parallel. In the leaked architecture, the coordinator does not directly edit files, run commands, or read code. All implementation goes through workers. Verification is handled by what the code describes as a separate adversarial agent that must confirm the output works before the task can be marked complete. In effect, this is zero trust architecture applied to AI agents, with the orchestration system enforcing verification independently of the model.
“The leaked code also references an autonomous daemon mode, internally called KAIROS. The source describes a persistent agent that watches the developer’s project and proactively acts without waiting for user input. It uses a tick based lifecycle with periodic prompts, and the code indicates behavior that adjusts based on whether the developer’s terminal is active. The source also references memory consolidation during idle periods, converting observations into structured facts. These features represent event driven architecture, state management, and context engineering built entirely in the orchestration layer.
“The code also contains what analysts describe as a competitive defense embedded directly in the orchestration layer. The system references injecting artificial tool definitions into certain API responses, apparently designed to degrade the performance of any competitor model trained on Claude’s outputs. That defense lives in the scaffolding. It tells you where Anthropic believes their competitive advantage sits.
“The depth of interlocking systems documented in the leaked code is what stands out. The coordinator depends on the memory system, the memory system depends on the tool layer, the tool layer depends on the permission framework. These systems are deeply interdependent, and building them to work in concert at production quality is the hard engineering problem. The public conversation about AI capabilities focuses almost entirely on which model is smarter. What this leak suggests is that the model generates the next token, and everything around it is what turns that reasoning into reliable, operational capability.
“This leak also serves as a proof of concept for the rest of the industry. The engineering gap between a frontier research lab and a commercial competitor appears narrower than many assumed. The architectural patterns documented in the leaked source are well structured and reproducible in principle. A competent engineering team can study the coordination strategies, memory approaches, and tool integration designs and adapt the approach using any available foundation model. The model layer is swappable. The orchestration patterns are the transferable knowledge. What Anthropic built behind closed doors is now visible, and for anyone questioning whether a smaller team could build a credible AI coding agent, the architectural proof of concept is now public.
“The knowledge transfer effect is significant. Developers who were building AI coding tools through trial and error now have a detailed reference implementation from a team backed by billions in research and development. The architectural decisions, trade-offs, prompt engineering techniques, and multi agent coordination strategies are all visible. The effect extends beyond direct competitors. It raises the floor for every developer building with AI. The gap between what a frontier lab understood about AI agent architecture and what the broader developer community understood has been enormous. That gap collapsed overnight.
“The model is increasingly a commodity. Multiple frontier models are available from multiple providers, and the performance gap between them continues to narrow. The orchestration system built around the model is the competitive frontier, and Anthropic just published the blueprint.”
Vishal Agarwal, CTO, Averlon adds this:
“The deeper risk here isn’t what was exposed, it’s what becomes possible. When AI coding agent internals are public, attackers can study how those agents interpret context, follow instructions, and make decisions.
“That makes it easier to craft inputs or artifacts that appear legitimate to developers but influence how the agent behaves: modifying code, introducing insecure changes, or interacting with downstream systems. This expands the attack surface beyond the model itself into developer workflows, CI/CD pipelines, and the systems those pipelines connect to.”
This is embarrassing for Anthropic. But I honestly am not shocked by this. They clearly need to tighten things up or this will keep happening. Which of course is bad for them.
It Should Not Have Taken 13 Phone Calls And A Month For Bell & Distributel To (Hopefully) Fix My Internet
Posted in Commentary with tags Bell, Distributel on April 2, 2026 by itnerdStarting on March 8th, I’ve been having consistent issues with the Internet service that is provided by Distributel, who is owned by Bell. Basically what would happen is that my connection would disconnect. Then it may reconnect on its own 15 minutes later. Or it may reconnect only if I power cycle the optical networking terminal which in layman’s terms converts fibre to ethernet. And this would happen as much as a dozen times a day. Now fibre should be ultra reliable. So I know something was seriously wrong. But as I found out, getting it fixed would be a nightmare.
First let me address the title. It really did 13 calls and a month of my life for Bell and Distributel to (hopefully) fix this. Each time I would call into Distributel, I was guaranteed to lose at least 45 minutes of my time that I would never get back because after some brief troubleshooting, I would be placed on hold while the tech support person called Bell to look at the line remotely. Then they would rebuild my speed profile each time and declare the problem fixed. But it was never truly fixed. It may stay up for an hour, or it may stay up for a day or two. One time it stayed up for 11 days. The longer that this went on, I figured that it must be me. So since I do IT for a living. Thus I did this troubleshooting:
After doing all of this, I concluded that this was clearly a Bell issue.
What made this worse is that it was also clear that Bell did not want to send out a tech to figure out what was going on. I get that’s expensive and Canadian telcos are loathe to do that. But when you can’t figure the issue out over the phone, you should just go ahead and and do that. On top of that, when I tried to escalate the issue within Bell, I was met with some of the worst possible customer service I have ever experienced. For example, one tier two Bell tech support person said the problem was my fault because I plugged my hardware into an uninterruptible power supply. Well, that’s a #fail on his part for two reasons. One, Bell themselves recommends that you do that as you can see here. Two, an uninterruptible power supply or UPS for short has the following benefits as per this:
So in short, your equipment is better off when plugged into a UPS. So why would someone from Bell say the opposite? My guess is that it is a way for him to get me off the phone and not actually address the problem as that allows him to close a ticket and improve his metrics. As well as avoid sending out a tech as he likely gets evaluated on that too. I will also note that this individual was extremely rude about it and disconnected the call when I dared to point out that what he was saying was factually incorrect.
This brings me to another point. The dynamics of Distributel versus the dynamics of Bell. While Bell was not helpful, and as per the example sometimes rude, the staff at Distributel were friendly and generally pleasant to deal with. Though I will say that a couple of them did not follow through on promises that they made. For example one of them promised to have a manager call me when I wanted to escalate the issue on their end. That never happened. Another promised that he would demand that Bell send out a tech. That never happened and rebuilt my profile again. One of the most important rules of providing customer service is to never say you’re going to do something and not follow through as that never ever ends well for the organization that you work for.
On top of that, Distributel employees openly criticized Bell employees. By openly, I mean while was on the phone with them. A lot of them said the quality of the service they got from Bell has nosedived over the years since Bell started outsourcing everything overseas. Or calling Bell employees “not well trained.” This kind of shocked me because Distributel is owned by Bell and these calls are being recorded. Which means that the potential for someone a few rungs up the ladder finding out should be high. But I am guessing that these Distributel employees either don’t care or nobody is listening to those recordings and they know that. Whatever the reason, this appears to highlight some serious problems within Bell that will affect customers in a negative way.
Let’s fast forward to call number 13. The person that I got finally was able to convince Bell to send a tech to figure out what was going on. His suspicion based on everything that I told him was that the optical networking terminal was the issue, and that Bell needed to swap it. A day and a half later the tech arrived and my wife was there to greet him. This tech tested everything from top to bottom, and he was going to leave because everything was working according to him. But unfortunately for him he was dealing with my wife who is kind of like The Doctor from the British sci-fi series Doctor Who. The Doctor gives you one chance to do the right thing, and if you don’t, The Doctor goes scorched Earth on you. In his case, he failed to grasp that this was an intermittent problem and she went scorched Earth on him and backed him into the position of swapping the optical networking terminal. The fact that according to her, he said that doing that was going to be an inconvenience to him as he would have to go to his truck to get one, and then he might miss out on another repair order (likely because he was a contractor who is paid by the repair order) did not help his cause. But he did do the swap of the optical networking terminal and he did note that the new optical networking terminal that he installed was substantially cooler than its predecessor. Perhaps that one was overheating due to some sort of fault? Who knows. As it stands as I type this, I have not had a single disconnect. Not one. If it continues like this for 30 days, I will declare this issue fixed.
But if the Internet continues to be problematic, then my wife and I will switch back to Rogers on a temporary basis. I say that because cable Internet would be a serious downgrade from fibre Internet in terms of speed (especially upstream where speeds can be a quarter of the downstream speeds at best) and latency (fibre has a latency of 3ms or less while cable can be 5 times as high or more which negatively affects anything from video calls to gaming). But more importantly, it will be temporary because I have begun to champion bringing Beanfield into the building. This is a company that runs fibre internet that they control from end to end into condos like ours. So during the month that this was going on, I had conversations with the condo board who unknown to me wanted a third option for residents. Apparently they have fielded complaints from residents who go back and forth between Bell and Rogers and don’t feel that they are getting quality telco services from either company. Thus to the board, my suggestion of going to Beanfield made sense. They’ve already touched based with the company and a meeting with them is scheduled for next week in order to explore how to execute this and what it will take to get it done. Once they’re in the building, my wife and I will be moving to them. And I suspect that others in the building will as well. That might send chills down the spines of Rogers and Bell execs. Or they may not care. I guess we’re about to find out.
One final thing, in the middle of all this, I attempted to reach out to a contact at Bell to tell her of my issue, the fact that I was having problems getting a resolution to said issue, a request to point me to someone who could help, and I was going to go public with this. I didn’t hear from her so I went public. Now some of you may say that I’m trying to pull rank because I am a public figure. And you’re 100% correct. I do have that option and I have exercised it at times out of desperation. But the general public doesn’t have that option which illustrates the state of customer service in the telco industry where Joe Average who is in a situation like mine has not a lot of options to escalate and issue and get a timely resolution. That needs to change, either through telcos making the choice that they must do better, or forcing it upon them via competition. My condo is doing the latter via Beanfield because we have the ability to do that. You may not as lucky as we are. For those in the latter category, that really needs to change and change now.
Leave a comment »