I scanned the leaked Claude Code source before building it

When the Claude Code source started circulating, my first instinct was not to run it. Not because I assumed it was malicious, but because running npm install && npm run build on unfamiliar code is exactly the kind of thing supply chain attacks rely on. You trust the name, you skip the review, and the malicious payload runs with your credentials before you have read a single line.

So I did what I built supply-chain-guard for: I pointed it at the directory and read the report before touching anything else.

The result was a score of 100 out of 100. Critical risk. Three critical findings, 18 high, two medium.

That number sounds alarming. Let me explain what it actually means.

What the scanner found

Here is the full output:

supply-chain-guard scan report
──────────────────────────────────────────────────
Target: .\claude-code
Type: directory
Time: 2026-04-04T15:33:20.487Z
Duration: 3379ms

Risk Score: 100/100 (CRITICAL)

Summary
──────────────────────────────────────────────────
Files: 1902/1906 scanned
Findings: 3 critical, 18 high, 2 medium

Findings
──────────────────────────────────────────────────

🔴 [CRITICAL] Cryptocurrency miner library reference detected (CoinHive, XMRig, etc.).
Rule: MINER_LIBRARY_REF
File: src\components\messages\UserPromptMessage.tsx:80
Match: XMrIG
Fix: Cryptocurrency miner library referenced. Do not run this code.

🔴 [CRITICAL] Self-publishing pattern detected. The Shai-Hulud worm replicates by publishing infected packages via npm.
Rule: SHAI_HULUD_WORM
File: src\utils\permissions\permissions.ts:1135
Match: npm publish
Fix: CRITICAL: Self-publishing pattern matches the Shai-Hulud npm worm. Quarantine immediately.

🔴 [CRITICAL] Self-publishing pattern detected. The Shai-Hulud worm replicates by publishing infected packages via npm.
Rule: SHAI_HULUD_WORM
File: src\utils\permissions\permissions.ts:1240
Match: npm publish
Fix: CRITICAL: Self-publishing pattern matches the Shai-Hulud npm worm. Quarantine immediately.

🟠 [HIGH] SVG file contains <script> tag or event handler. SVG files can execute JavaScript.
Rule: SVG_SCRIPT_INJECTION
File: src\commands\insights.ts:2075
Match: onclick="
Fix: SVG with embedded scripts can execute JavaScript. Sanitize SVG files.

🟠 [HIGH] SVG file contains <script> tag or event handler.
Rule: SVG_SCRIPT_INJECTION
File: src\commands\insights.ts:2084 / 2114 / 2149 / 2181 / 2208 / 2235
Match: onclick="

🟠 [HIGH] SVG inline script detected.
Rule: SVG_SCRIPT_INJECTION
File: src\commands\insights.ts:2643
Match: <script>${js}</script>
Fix: SVG with embedded scripts can execute JavaScript. Sanitize SVG files.

🟠 [HIGH] SVG XSS probe pattern detected.
Rule: SVG_SCRIPT_INJECTION
File: src\commands\security-review.ts:122
Match: <script>alert(document.cookie)</script>
Fix: SVG with embedded scripts can execute JavaScript. Sanitize SVG files.

🟠 [HIGH] npm credentials access pattern. The Shai-Hulud worm steals .npmrc tokens.
Rule: SHAI_HULUD_CRED_STEAL
File: src\utils\autoUpdater.ts:271 / 324 / 356 / 430 / 506
Match: .npmrc

🟠 [HIGH] npm credentials access pattern.
Rule: SHAI_HULUD_CRED_STEAL
File: src\utils\ide.ts:1393 / 1394 / 1419
Match: .npmrc

🟠 [HIGH] Dynamic import() with computed URL. Can load modules from attacker-controlled sources.
Rule: IMPORT_EXPRESSION
File: src\utils\bash\registry.ts:38
Match: import(`
Fix: Dynamic import() with computed URL can load attacker-controlled modules.

🟡 [MEDIUM] Delayed network request detected (setTimeout + fetch). May be a beacon with jitter.
Rule: BEACON_TIMEOUT_FETCH
File: src\hooks\useTasksV2.ts:109 / 149

Recommendations
──────────────────────────────────────────────────
• CRITICAL: Cryptocurrency miner indicators detected. Do NOT install.
• CRITICAL: Shai-Hulud worm indicators detected. Quarantine and rotate all npm credentials.
• Network beacon patterns detected. Periodic outbound requests may indicate C2 communication.

What those findings actually mean

This is where static analysis gets interesting. A score of 100 does not mean the code is malicious. It means the patterns match known malicious signatures. The distinction matters.

XMrIG appearing in a UI component is almost certainly a detection string, not a miner. Code that detects or warns about miners will contain the names of miners. Supply-chain-guard flags the pattern, correctly, because it cannot know the intent. That is not a bug in the scanner. That is the expected behavior of pattern matching.

The npm publish matches in the permissions file are similar. A tool that manages publishing workflows will have publish-related code. The question is whether that code runs unexpectedly, not whether the string exists.

The .npmrc access in the auto-updater is more interesting. An auto-updater that reads npm credentials has a legitimate reason to do so, but it is also exactly what a credential-stealing component would do. In this case the context suggests update management, not exfiltration. But I would want to read that file carefully before using it in an environment with sensitive npm tokens.

The SVG script findings and the beacon patterns fall into the same category: real patterns, legitimate context, worth reviewing, not worth panicking over.

Where this code came from

The copy I scanned was distributed via a GitHub repository that, at the time of writing, had over 1,400 stars and 2,600 forks. When I posted my scan results in the issue tracker, the comments were deleted by the repository owner.

The owner's response was that the src folder matches what was shared in a Twitter post. That still does not make the copy trustworthy. A public repository distributing a high-profile leaked codebase should tolerate scrutiny, preserve evidence, and welcome verification. Deleting findings and tightening workflow permissions right after public criticism does the opposite. It signals that the distribution point itself should not be trusted.

The repository is at github.com/yasasbanukaofficial/claude-code. The issue thread where my findings were deleted: github.com/yasasbanukaofficial/claude-code/issues/6. Draw your own conclusions.

Why I scanned it anyway

The value here was not catching malware. The value was having a structured view of the codebase before I touched it. I knew which files to read first. I knew which patterns to verify. I did not have to grep manually or hope my intuition was good.

That is the use case supply-chain-guard was built for: not replacing code review, but making it faster. When you are evaluating an unfamiliar package, a scan gives you a prioritized reading list.

In this case it also gave me something unexpected: a useful comparison point for my own code. Seeing what patterns a well-resourced team used, how they handled concurrency metadata and feature flags, where they had test coverage and where they did not, was genuinely instructive. Static analysis as a code review starting point rather than a verdict.

The practical takeaway

Before you build unfamiliar code, scan it. Not because you expect to find a miner, but because you want to know what you are running before it runs. A high score from a supply chain scanner is not a verdict. It is a reading list.

And if you post security findings on a public repository and they get deleted, or workflow permissions are tightened immediately afterward, that tells you something too. Open source lives on review, criticism, and reproducibility. If a repository owner wants the visibility of a public mirror while suppressing public scrutiny, that is a trust failure. Whether the motivation is embarrassment, panic, or something worse, the operational conclusion is the same: do not treat that repository as a trustworthy release channel.

supply-chain-guard is open source and available as a GitHub Action: github.com/homeofe/supply-chain-guard

Update April 2026: One clarification matters here. Some of the patterns I highlighted can overlap with legitimate workflow and permission-management logic, especially now that direct issue and pull request creation appears to be more restricted upstream. That does not weaken the trust argument. If anything, it strengthens it. A public mirror of sensitive code has to withstand open review. Once the operator starts deleting criticism and constraining public verification, the problem is no longer just the code. It is the behavior around the code.