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. If that is true, I do not want to think about how many accounts may already be compromised and what kind of distribution campaigns could be running right now.

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: that tells you something too.

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