Claude Code source code leaked. Were our sources even hidden in the first place?

In the early hours of April 1, 2026, the source code of Claude Code (not the backend, but the front-end CLI tool portion) was leaked. This was the second such incident following February 2025, yet Silicon Valley engineers are watching it with measured calm. This may be Anthropic's message that AI systems, including Claude Code, already possess the ability to understand machine language (binary and assembly), that concealing the source code of distributed modules is pointless, and that such code should be treated as something that poses no problem even if reconstructed. Indeed, Gemini has also stated that "even when obfuscation tools are used, the probability that 2026-era AI can see through them is increasing." This article revisits the fundamental question of how "hidden" our source code really is. It comprehensively examines to what extent 2026 AI can reconstruct source code from binaries and obfuscated code — covering the specific steps involved, what can and cannot be recovered, and the limits of such recovery — while drawing on the views of researchers and experts in Silicon Valley and around the world. Building on this, it offers a comprehensive overview of countermeasures companies should adopt from technical, legal, and strategic perspectives, and looks ahead to the future signaled by Anthropic's next model, "Claude Mythos."

Why Silicon Valley Engineers Stayed on the Sidelines

In the early hours of April 1, 2026, the source code of Claude Code (the front-end CLI tool portion, not the backend) was leaked. This was the second such incident following February 2025, though Silicon Valley engineers are watching it with little concern.

This may be Anthropic's message that AI systems, including Claude Code, already possess the ability to understand machine language (binary and assembly), making it pointless to keep the source code of distributed modules secret — and that even if reconstructed, it should be treated as no cause for concern. In fact, Gemini has also stated that "even when obfuscation tools are used, the probability that 2026-era AI can see through them is increasing."

At the time of the first leak in February 2025, Geoffrey Huntley published a clean-room deobfuscation project and remarked:

"These LLMs are remarkably good at deobfuscation, transpilation, and inter-structural conversion."

A year later, those words carry even more weight. AI in 2026 has dramatically improved its ability to reconstruct source code from binaries. In the first place, is the source code we think we are "hiding" truly hidden? The question is no longer "can AI reconstruct source code?" but rather "to what degree of accuracy, and how far can it go?"

AI-Powered Binary-to-Source Code Restoration — The State of the Art in 2026

LLM4Decompile — Binary Decompilation with a Dedicated Model

LLM4Decompile is an open-source LLM designed to recover source code from binary code. It is available in parameter sizes ranging from 1.3B to 33B and supports Linux x86_64 binaries compiled with GCC optimization levels O0 through O3.

Its performance is evolving rapidly. The 6.7B model achieves 45.4% accuracy on the HumanEval benchmark, and the 6B model records a 90% recompilability rate — meaning 90% of the recovered C code passes compilation. This represents a 50% improvement over GPT-4. Furthermore, the latest LLM4Decompile-9Bv2 pushes the re-executability rate to 64.94%. Roughly two-thirds of the recovered code can reproduce the same input/output behavior as the original program.

The Decompile-Bench project provides one million binary-source code function pairs, and LLM4Decompile trained on real-world data achieves an R2I score 21.5% higher than training on synthetic data alone. Training on real code leads to more accurate recovery of real code — an expected outcome, but the magnitude of the effect is worth noting.

Mizuchi — Byte-Perfect Decompilation

Mizuchi, which emerged in 2026, is an automated matching decompilation pipeline leveraging the Claude API. The goal of this tool is to produce output that matches the original binary byte-for-byte when the recovered C code is compiled.

A context-aware retry mechanism feeds compilation errors back to the LLM, which automatically iterates on fixes. The result: 53 out of 60 functions — 88% consistency — achieved identical output. This means the tool does not merely recover code that "looks plausible," but can faithfully reproduce the original implementation including compiler optimization patterns.

ReCopilot and SK2Decompile — The Evolution of Semantic Recovery

ReCopilot, published in 2025, demonstrated performance 13% above existing tools and LLMs in function name recovery and variable type inference. When decompiling a binary, the most commonly lost information is semantic information such as variable names, function names, and type information. ReCopilot specializes in this domain and advances the recovery of code "readability."

SK2Decompile (October 2025) adopts a two-phase approach — Structure Recovery and Identifier Naming — to transform binaries/pseudocode into human-readable source code.

humanify — AI-Assisted Recovery of Obfuscated JavaScript

humanify, specialized in JavaScript/TypeScript deobfuscation, uses LLMs (ChatGPT, llama, etc.) to recover variable and function names while preserving meaning. It performs structural transformation at the Babel AST level, with the LLM providing naming hints — a hybrid approach where syntactic transformation is handled deterministically and semantic recovery is delegated to AI.

For bundled and minified JavaScript packages like Claude Code, this approach is remarkably effective. Even when variable names have been shortened to a, b, and c, the LLM can infer original names such as page, selector, and timeout from context with high accuracy.

Concrete Restoration Procedure——An Actual Workflow for Converting Binaries Back to Source Code with AI

As of 2026, the actual workflow for AI-assisted reverse engineering consists of the following five steps.

Step 1: Disassembly/Decompilation. Feed the binary into Ghidra or IDA Pro to obtain pseudocode (decompiler output). Ghidra 11.2 (released in late 2025) enhances AI-assisted analysis, while IDA Pro 8.5 improved decompiler accuracy by 23%. What you get at this stage is compiler-generated, low-level pseudo-C code — variable names are lost, and control flow is distorted by optimization.

Step 2: Analysis with AI Assistants. DAILA (Decompiler Artificially Intelligent Language Assistant) is a plugin that integrates GPT-4, Claude, and local models into Ghidra/IDA Pro. The NDSS 2026 (Network and Distributed System Security Symposium) paper "Decompiling the Synergy: An Empirical Study of Human-LLM Teaming in Software Reverse Engineering" demonstrated the effectiveness of human-LLM collaboration in reverse engineering. DAILA sends decompiler output to an LLM with a single button press and receives back function semantics, guessed variable names, and flagged vulnerabilities.

Step 3: High-Fidelity Function-Level Recovery. Feed disassembly results into LLM4Decompile or Mizuchi to recover C source code. Mizuchi's context-aware retry mechanism automatically corrects compilation errors, achieving byte-perfect matches for 88% of functions. Claude's "one-shot decompilation" has a track record of recovering over 1,000 functions at high match rates in game analysis (Snowboard Kids 2).

Step 4: Recovery of Semantic Information. Inferring variable names, function names, comments, and type annotations is where LLMs excel most. ReCopilot outperforms existing methods by 13% in function name recovery and variable type inference. humanify recovers variable names from context in minified JavaScript. At this stage, code transforms from "compiler output" to "source code that looks human-written."

Step 5: Verification and Iteration. Compile the recovered code and compare it against the original binary. If there are discrepancies, feed that information back to the LLM and iterate on corrections. Mizuchi has fully automated this process. Without human intervention, the cycle runs from binary to source code, and from source code back to a byte-perfectly matching binary.

Restorable Points and Current Limitations

Organizing what AI in 2026 excels at restoring and what remains difficult.

What can be restored with high accuracy:

Control flow structures (if/else, for/while loops, switch statements)
Function call relationships and parameters
Numerical operations and string manipulation logic
Standard library function call patterns
Semantic inference of variable and function names (from context)
Comment inference (generated in natural language from processing content)

What remains difficult to restore:

Preprocessor definitions before macro expansion
Original structure of template metaprogramming
Highly optimized numerical computations (SIMD instructions, etc.)
Code with three or more layers of obfuscation applied (though 24% with Claude Opus 4.5)
Binaries with proprietary encryption or packing applied

Obfuscation vs AI — A Benchmark of 10 Models

Norwegian app protection company Promon has released a landmark benchmark in their Q1 2026 "App Threat Report," pitting 10 AI models against binaries obfuscated with Obfuscator-LLVM (OLLVM). The models tested were Claude Opus 4.5, Sonnet 4.5, Haiku 4.5, GPT-5, GPT-4o, Gemini 3 Pro, 3 Flash, 2.5 Pro, DeepSeek Chat, and DeepSeek Reasoner.

The average success rate against clean (non-obfuscated) ARM assembly was 63.7%. No model exceeded 86%, meaning AI has yet to achieve complete comprehension of assembly even without obfuscation.

When triple obfuscation (SUB+FLA+BCF) was applied, the average success rate dropped to 20–36% against x86 binaries and 8.5% against ARM binaries. The combination of FLA (control flow flattening) and BCF (bogus control flow) proved to be a 4.18× stronger barrier on x86 and 5.50× stronger on ARM compared to BCF alone.

The standout performer was Claude Opus 4.5. Against triple-obfuscated ARM binaries, it achieved 50% recovery from pseudocode and 24% from raw assembly. GPT-4o scored 10% on pseudocode and 2% on raw assembly, while weaker models remained at 1–2%. Claude Opus 4.5 outpaced all runners-up by a wide margin.

Promon's conclusion is that the arms race has not ended — it has evolved. But the direction is one-sided. From GPT-4o's 2% in 2025 to Claude Opus 4.5's 24% — a 12× improvement in a single year. If this growth trajectory continues, the effective lifespan of multi-layer obfuscation will keep shrinking, measured in years.

The VC Perspective — "Feature Moats Are Dead"

Silicon Valley VCs clearly recognize the end of business models that rely on keeping source code proprietary.

The words of an investor reported by TechCrunch in March 2026 are telling.

"Everything AI agents can do today is 'pretty boring.'"

"All functional moats — UI, backend logic, API integrations — have been compressed to near zero. When LLMs commoditize interfaces, what remains is the pure value of data. If the data isn't proprietary, nothing remains."

In the a16z portfolio, companies with moats built on proprietary data are reaching zero to $100M in revenue at the fastest pace. a16z led the Series B of Story Protocol (PIP Labs), an IP protection platform for the AI era, with $80M, and Marc Andreessen stated, "Open-source AI should spread freely and compete."

Another investor cuts to the heart of it.

"When anyone can build anything overnight, the only moats AI can't replicate are SEO, brand, taste, speed, data, and trust. Defensibility now lies in the depth of relationships, not technical opacity."

Generic vertical SaaS without proprietary data moats is no longer popular with VCs. In a world where code can be reproduced, the code itself is not a competitive advantage.

Measures Companies Should Take——Software IP Protection Strategies for 2026

How should companies respond to the evolution of AI reverse engineering? Here we organize countermeasures along three axes: technical, legal, and strategic.

Technical Countermeasures

1. Full migration to server-side execution. The most reliable countermeasure is to completely eliminate proprietary logic from client devices. With an API-first architecture, the client becomes nothing more than a thin frontend. If there is nothing on the client to reverse engineer, there is nothing to reconstruct. Ironically, Claude Code itself follows this architecture — what leaked was the frontend CLI portion, while the AI model itself resides on Anthropic's servers.

2. Confidential computing. Gartner predicts that by 2029, more than 75% of processing on untrusted infrastructure will use confidential computing. Hardware-based Trusted Execution Environments (TEEs) from AMD and Intel protect data not only at rest and in transit, but also during processing. In March 2026, HPE announced the integration of Confidential Computing into Morpheus Software.

3. Maintaining multi-layered obfuscation (as a delaying tactic). As Promon's report shows, the combination of FLA and BCF remains an effective barrier against AI. The average success rate against triple-obfuscated ARM binaries is 8.5%. However, this is not a fundamental solution — it is a delaying tactic, and its effectiveness shortens every year.

4. Native client authentication and attestation. Authenticate legitimate clients at the hardware level. The leaked Claude Code itself implemented a DRM-like authentication system using Bun's Zig HTTP stack. However, this too can be bypassed if the source code leaks — since the authentication implementation itself becomes a target for reconstruction.

Legal Countermeasures

5. Updating trade secret law strategies. The U.S. Defend Trade Secrets Act (DTSA) and state-level Uniform Trade Secrets Acts (UTSA) are the primary legal protections, but AI is fundamentally shifting the standard of what is "readily ascertainable." Greenberg Traurig law firm warns:

"Companies that developed trade secret protection plans before 2023 may not have considered AI at all."

If the internal logic of software that was once considered "not readily ascertainable" becomes readily ascertainable through AI, there is a risk that it will lose its legal protection as a trade secret.

6. Leveraging legal precedent. The Motorola v. Hytera ruling (2025) rejected the "redesign" defense and ordered $70 million in additional royalties. This precedent may apply to misappropriated code that has been modified by AI. Courts are beginning to distinguish between prompt injection and legitimate reverse engineering as "improper means."

7. Compliance with California's AI Transparency Law (effective January 2026). This law mandates disclosure of training data summaries. Companies will need systems in place to monitor whether their own code is included in AI training data.

Strategic Countermeasures

8. Building data moats. As VCs consistently point out, in a world where code can be reconstructed, proprietary data is the only sustainable competitive advantage. Proprietary datasets, deep customer relationships, and network effects — these are things AI cannot replicate in a single day.

9. Advantage through speed and iteration velocity. Even if code is reconstructed, a team that ships product improvements weekly will always keep followers one lap behind. Claude Code itself is proof of this — even after its source code leaked, its growth to $2.5 billion ARR did not stop. That is because the value lies not in the code, but in the backend AI model.

10. Shifting to "design assuming reconstruction." Paradoxically, the most robust strategy is to design architecture on the assumption that source code will leak. Avoid including proprietary intellectual property in code distributed to clients, and place all differentiating elements on the server side. There is also a path — like Red Hat's or HashiCorp's BSL model — of open-sourcing the code while monetizing through support, hosting, and enterprise features.

Positive Outlook and Negative Outlook

On the positive side, the rendering of source code concealment meaningless could improve transparency and security across the software industry as a whole. The fact that hidden backdoors and vulnerabilities become easier to discover with AI represents positive feedback for cybersecurity. As the open-source movement has demonstrated, transparency accelerates innovation.

On the negative side, the weakening of intellectual property protection could undermine R&D incentives, particularly for startups and small-to-medium enterprises. If software developed at enormous cost can be easily reconstructed, the return-on-investment model for proprietary software becomes unviable. Furthermore, while malware analysis becomes easier, it is a double-edged sword in that protecting legitimate software also becomes more difficult.

Claude Mythos — The Future Indicated by "Myth"

Just five days before the Claude Code source code leak, the existence of Anthropic's next model, Claude Mythos, was revealed through a data breach. Roy Paz of LayerX Security and Alexandre Pauwels of Cambridge University discovered approximately 3,000 files from a database that had been made publicly searchable due to a CMS misconfiguration.

Mythos represents an entirely new class above Opus — not a version upgrade. Internal documents described this model, bearing the name of "myth," as follows:

"Currently vastly surpasses all other AI models in cyber capabilities."

Mythos discovered multiple heap buffer overflow vulnerabilities in the Linux kernel, and internal documents recorded:

"A language model can, autonomously and without sophisticated scaffolding, discover and exploit zero-day vulnerabilities in critically important software."

Anthropic informally warned government officials that Mythos "would significantly increase the likelihood of large-scale cyberattacks in 2026."

Pause and consider this. For a model that can autonomously discover zero-day vulnerabilities in the Linux kernel, how "difficult" would it be to analyze an obfuscated JavaScript bundle — or decompile an O3-optimized binary?

In Promon benchmarks, Claude Opus 4.5 achieved 24% against triple-obfuscated ARM binaries. Mythos sits in a class above that. If LLM4Decompile's 9B model achieves a re-executability rate of 64.94%, what percentage would a Mythos-class model reach when tackling the same task? 80%? 90%? Or even higher?

Conclusion — Are Our Sources Hidden in the First Place?

Claude Code's 512,000 lines of TypeScript source code leaked due to a misconfigured .npmignore. But even if it hadn't leaked, the answer to the question would be the same.

LLM4Decompile has reached a re-executability rate of 64.94%. Mizuchi achieves byte-perfect decompilation for 88% of functions. Claude Opus 4.5 demonstrated a 24% recovery success rate against triple-obfuscated ARM binaries — 12 times that of GPT-4o. And Claude Mythos is coming: an entirely new class surpassing Opus, bearing the name of "myth."

The source code of modules distributed locally is no longer hidden.

The code we compile, obfuscate, minify, and pack is like thin fog before AI. That fog grows thinner every year, and will eventually disappear.

The path forward for companies is clear: move proprietary logic to the server side, and design whatever is distributed to clients on the assumption that it will be recovered. Competitive advantage should rest not on secrecy of code, but on the uniqueness of data, the depth of customer relationships, and the speed of iteration.

Whether the "message" Anthropic sent was intentional no longer matters. What matters is that we ask ourselves — was our source code ever truly hidden in the first place?

Impact on the Industry

First, the economics of software IP protection are changing irreversibly. The era has arrived where it makes more rational sense to invest resources in building server-side execution and data moats rather than spending on obfuscation and code concealment. As Promon's report shows, multi-layered obfuscation still serves as an effective delaying tactic, but given the pace of AI advancement, its effective lifespan continues to shrink on a year-by-year basis.

Second, the implications of Anthropic's financial success in this context are significant. Claude Code alone achieved $2.5 billion in ARR within 9 months, and even after a source code leak, growth did not stop. This is a demonstration of a survival strategy for "a world where source code cannot be hidden." Value lies not in front-end code, but in back-end AI models and data.

Third, VC investment decisions are clearly shifting. Generic SaaS without proprietary data moats is becoming an unattractive investment target, and as a16z's $80 million investment in Story Protocol (an IP protection platform) shows, "IP protection in the AI era" itself is emerging as a new investment theme.

Fourth, updating legal frameworks is urgently needed. AI is changing the standard for what is "readily ascertainable," risking the weakening of legal protections for trade secrets. The Motorola v. Hytera ruling is important as a precedent, but legislation tailored specifically to the AI era is only just beginning.

Fifth, the existence of Claude Mythos suggests this change will accelerate. If a model capable of autonomously discovering zero-day vulnerabilities becomes widely available, a world where every binary is effectively open source will become reality. In that world, the companies that survive will be those that can differentiate through data and relationships, not code.

References: Axios, "Anthropic leaked its own Claude source code" (2026/3/31); VentureBeat, "Claude Code's source code appears to have leaked" (2026/3/31); Fortune, "Anthropic leaks source code in second major security breach" (2026/3/31); The Hacker News, "Claude Code Source Leaked via npm" (2026/4); Bleeping Computer, "Claude Code source accidentally leaked in npm package" (2026/4); Layer5, "512,000 Lines and the Fastest-Growing Repo in GitHub History" (2026/4); Geoffrey Huntley, "Claude Code deobfuscation tradecraft" (2025/3); Fortune, "Anthropic Mythos revealed in data leak" (2026/3/26); Euronews, "Mythos poses unprecedented cybersecurity risks" (2026/3/30); Futurism, "Anthropic leaked model with unprecedented risks" (2026/3); CoinDesk, "Anthropic massive Claude Mythos leak" (2026/3/27); GitHub: LLM4Decompile (albertan017/LLM4Decompile); BrightCoding, "Mizuchi LLM Pipeline for Perfect Decompilation" (2026/3); arxiv: ReCopilot (2505.16366v1); RevEng.AI, "Training an LLM to Decompile Assembly Code"; arxiv: LLM4Decompile paper (2403.05286v2); GitHub: humanify (jehna/humanify); GitHub: DAILA (mahaloz/DAILA); NDSS 2026, "Decompiling the Synergy: An Empirical Study of Human-LLM Teaming in Software Reverse Engineering"; Secybers, "Ghidra vs IDA Pro 2026"; Promon, "App Threat Report 2026 Q1: The State of Code Obfuscation Against AI"; Promon, "AI deobfuscators won't help hackers yet"; Google Cloud Blog, "Scaling Up Malware Analysis with Gemini 1.5 Pro"; Google Cloud Blog, "Gemini for Malware Analysis"; TechCrunch, "Investors spill what they aren't looking for in AI SaaS" (2026/3); CNBC, "Story raises funds from a16z to stop IP theft by AI" (2024/8); KoreaTechDesk, "a16z $80M for IP Protection in Age of AI"; Greenberg Traurig, "Reverse Engineering in the Age of AI: Are Your Trade Secrets Still Safe?" (2025/12); Intel Confidential Computing Whitepaper (2025); HPE Security Advancements (2026/3); JDSupra, "2025 AI and Trade Secret Law Retrospective"; Anthropic, "acquires Bun as Claude Code reaches $1B milestone" (2025/12); Yahoo Finance, "Anthropic ARR surges to $19 billion" (2026); TechCrunch, "Anthropic raises $30B Series G at $380B valuation" (2026/2)