
I was scrolling through the whole Claude Code source map story when it hit that very specific part of my brain reserved for software comedy.

One part packaging mistake. One part security story. One part the entire internet suddenly becoming a reverse engineering community.

And yes, the first reaction is obvious.

This is funny.

A company shipping one of the most advanced AI coding tools on the planet allegedly exposed source maps in a way that made internal structure far easier to inspect. The same category of mistake a random frontend team can make on a sleepy Friday deploy. Except this time it landed next to a frontier AI product, so naturally the memes started immediately.

But after the jokes, I think there is a more interesting story here.

Not just gotcha. Not just dunking.

The real story is that coding has largely been solved in one very boring sense. A huge amount of software work is still just strings, flags, package contents, trust boundaries, and whether somebody remembered to check what actually shipped.

That part is not futuristic.

That part is old school engineering hygiene.

And when it fails, even the most hyped product in the room can suddenly look very ordinary.

## what actually happened

The broad public claim is pretty simple.

Claude Code was published in a way that allegedly exposed source maps. And if you do not spend your life trapped inside JavaScript build systems, a source map is basically a file that helps tooling map minified production code back to the original source structure.

So instead of seeing one compressed ball of JavaScript, you can often recover something much closer to the original code layout. File names. Function names. String constants. Comments in some cases. Logic flow. Feature names. Architectural hints.

That is a very different situation from just saying, well, technically all JavaScript is visible in the browser anyway.

Yes, shipped JavaScript is visible.

But there is a big difference between "visible in a mangled and annoying form" and "readable enough that the internet can start doing archaeology on your product by lunchtime."

I am not reproducing leaked code here. I am not linking it either. If something was exposed accidentally, I have zero interest in turning a funny engineering story into free redistribution.

But even without touching the code itself, the public discussion already tells us enough to talk about the important part.

## why source maps matter more than people think

A lot of developers treat source maps like a harmless frontend debugging detail.

They are not.

A production source map can expose things like:

- internal file structure
- meaningful function and variable names
- hidden feature flags
- embedded prompt or policy strings
- command shapes
- client side filtering logic
- debug paths
- operational assumptions
- trust boundaries that were never supposed to be this inspectable

Think of minified code like a shredded document.

It is not unreadable forever. But it is annoying enough that most people will not bother unless they really care.

A source map is the reconstruction guide sitting right next to the shredded paper.

That does not automatically mean total compromise. But it absolutely lowers the cost of understanding how the system works.

And if the tool touches terminals, local developer environments, MCP servers, private workflows, or anything adjacent to credentials, that drop in inspection cost matters a lot.

## the funniest part is also the most normal part

One reason people latched onto this story so hard is that AI labs still carry this weird aura around them.

People imagine some sacred cathedral of machine intelligence.

Then a packaging story like this happens and suddenly everybody remembers that under the giant model, giant valuation, giant safety rhetoric, and giant brand halo, there is still just a product.

A normal product.

Made out of UI logic, heuristics, strings, pattern matching, release scripts, and whatever made sense to the team at the time.

That should not be surprising.

But it still is.

There is something deeply funny about expecting alien machinery and finding what looks, from the outside, like very familiar software behavior. Not divine machinery. Just software. Some elegant bits. Some messy bits. Probably some rushed bits. Usually all at once.

That is not even a Claude specific observation. That is the software industry.

## the regex detail made people laugh for a reason

One of the details making the rounds was the claim that some negative sentiment detection relied on a hardcoded list of hostile or frustrated words.

If that public reporting is accurate, then yes, that is funny.

You build a frontier model that can explain compilers, summarize papers, and write React components. Then somewhere in the stack there is still a tiny product rule doing the emotional equivalent of:

> if user says "this sucks", mood = bad

That contrast is comedy.

But it is also normal.

A lot of modern AI products are layered systems. The model is one layer. The product around it is another. Safety logic, UX rules, cheap heuristics, throttles, routing, telemetry, and edge case handling often live in ordinary application code.

That does not make the product fake.

It just means a lot of AI magic is still normal software wearing a very expensive coat.

And honestly, I wrote recently about how much of the real difficulty with AI coding agents lives in the surrounding system, not the raw model output. If you have used these tools seriously, none of this should feel shocking. It should feel familiar. You can read that piece here: [Everything I Got Wrong About AI Coding Agents](/posts/everything-we-got-wrong-about-ai-coding-agents).

## where the story stops being funny

The jokes are the easy part.

The less funny part is what happens whenever internal source becomes much easier to inspect.

People start finding assumptions.

And assumptions are where security stories begin.

I am intentionally not going into exploit paths or operational details. But in general, incidents like this can help people reason about:

- which commands exist internally
- what debug views or diagnostic paths are present
- what gets printed to terminal output
- how environment variables are handled
- which controls are client side instead of real enforcement
- where trust boundaries are weaker than the product marketing suggests
- whether any part of the system was quietly relying on obscurity

That last point matters.

Security through obscurity is not imaginary. It does add friction. It does slow people down. It does reduce casual inspection.

It is just not a foundation.

If a system only feels safe because nobody has looked closely yet, then it is not really safe. It is merely uninspected.

And a source map story can change that very quickly.

The entire internet becomes your unpaid review team.

Some of those reviewers are helpful.

Some are definitely not.

## the real lesson is boring and that is why it matters

What keeps sticking with me is how unglamorous the real lesson is.

We already know what good engineering hygiene looks like.

Do not expose artifacts you did not mean to expose.

Do not assume npm packaging defaults are harmless.

Do not rely on client side hiding for anything sensitive.

Do not let terminal adjacent tooling casually print things that sit too close to secrets.

Do not ship build outputs you have not audited.

Do not move so fast that release discipline becomes optional.

None of this requires AGI to understand.

None of this is some new philosophical crisis about the future of software.

It is just engineering discipline.

The kind that feels boring right until the day you skip it and the whole internet notices.

## the weird product details are not actually the point

A lot of people got distracted by the weirder screenshots and claims floating around.

Hidden modes. Internal instruction strings. novelty mechanics. product oddities that look slightly absurd once they leave their original context.

I get it. Those are fun to talk about.

But I do not think that is the main story.

Every large product contains strange internal DNA. Every team has at least one feature or internal rule that sounds ridiculous when somebody screenshots it out of context. That part is not special.

What matters is not that the code apparently contained weirdness.

What matters is that the weirdness was inspectable at all.

That is the thing teams should actually learn from.

## there is a trust problem sitting underneath all of this

There is also a wider emotional reason stories like this spread so fast.

AI companies have benefited enormously from public code, public writing, public discussions, and open source ecosystems. Whether you think that is fair, inevitable, transformative, or exploitative, the relationship is obviously asymmetrical.

So when an AI company accidentally exposes its own internal code and then the public conversation immediately shifts to "you are not allowed to look at that," people are going to notice the asymmetry.

Legally, training on public material and republishing exposed internal code are not the same thing.

Technically, also not the same thing.

But emotionally, people are obviously going to compare them anyway.

And once they do, the whole thing starts to feel very convenient.

Your code helped build the machine. Their code is sacred.

That tension is a huge part of why these stories travel so fast.

## for the nerds who want the receipts

<Notice type="info">
This section is optional. The main point is already done. If you skip everything below, the takeaway stays the same. Source maps are not a harmless detail when the product being shipped sits near trust boundaries and sensitive developer workflows.
</Notice>

At a very high level, the production pipeline looks something like this:

```text
original source files
  -> bundle and transform
  -> minify
  -> ship compressed production JavaScript
  -> optionally ship a source map beside it
```

The source map is a mapping between positions in the generated bundle and positions in the original source.

So a tool can effectively do this kind of jump:

```text
app.min.js
  line 1, column 48291
    -> src/features/mcp/commands/getInfo.ts
       line 87, column 12
```

Do that enough times across a bundle and the internal structure stops being hidden in any meaningful sense.

That does not always mean you recover a perfect repo.

But it can absolutely mean you recover enough structure to make reverse engineering dramatically easier.

And if the original code contains long string constants, comments, feature names, policy text, debug messages, command labels, or heuristic logic, those become far easier to inspect than they would be from minification alone.

This is why shipping source maps in production is not automatically wrong, but it is also not something you should do by accident.

For a simple public app with sanitized artifacts, maybe the tradeoff is fine.

For a high scrutiny developer tool that sits near terminals, local files, environment variables, prompts, and trust boundaries, you should think very hard before making that tradeoff.

## what I would do if I were shipping this kind of tool

I would assume the package will be inspected.

Because eventually it will be.

That means:

- audit exactly what npm ships
- check whether source maps are included
- inspect the built tarball, not just the repo
- review terminal output for secret adjacent behavior
- separate real safety controls from cosmetic ones
- assume every string constant is searchable
- assume every hidden path becomes visible eventually

This is not paranoia.

It is just shipping software in public.

## my honest take

Yes, the whole thing is funny.

It is funny because it punctures the aura.

It is funny because giant AI labs still trip over the same packaging rakes as everyone else.

It is funny because somewhere beneath the trillion dollar narratives, there is apparently still a pile of very ordinary product code doing very ordinary product things.

But the reason I care is not the comedy.

It is the reminder.

The more powerful these tools get, the less room there is for sloppy surrounding systems. Not because perfection is possible. It is not. But because source maps, client side heuristics, debug paths, and packaging mistakes become much more consequential when the product sits this close to code, credentials, and trust.

So yes, laugh at the memes.

I did too.

But if you are building in this space, the real takeaway is much less glamorous.

The future is still made out of source maps, package manifests, trust boundaries, string matching, and engineers remembering to check what actually shipped.

And that, more than anything, is why this story matters. 🫡


The Claude Code source map story turned into a public dunk fest, but the real lesson is about build hygiene, trust boundaries, and how exposed modern AI tools can get.

The Claude Code Source Map Story Is Funny Until You Think About What It Means


I was messing around in the Firefox console when I did something that should make nobody comfortable.

I called `Math.random()` a few times, copied three outputs into a script, and the script told me what the next random numbers would be.

Then I went back to Firefox, hit enter, and watched those numbers appear exactly as predicted.

Digit for digit.

This was not a magic trick. I was not editing the page. I was not intercepting anything. I was just using the fact that `Math.random()` is not random in the security sense.

And if you are using `Math.random()` to generate OTPs, this should be your sign to stop.

## the moment this stopped feeling random

The whole demo looked stupidly simple.

I grabbed three `Math.random()` outputs from Firefox. Then I fed them into a small program using Z3. That program recovered the internal state of Firefox's pseudorandom number generator and started printing the numbers that would come next.

I ran `Math.random()` again in Firefox.

It matched.

Again.

And again.

That is the part people miss about `Math.random()`. If you just stare at a decimal like `0.5466844185052394`, it *looks* random enough. Human eyes are very easy to fool here. We see noise and assume unpredictability.

But computers do not care about vibes.

If the generator is deterministic and leaks enough information through its outputs, an attacker can work backwards, recover state, and predict future values.

That is exactly the kind of property you do **not** want anywhere near OTP generation.

So I wanted the post to let people feel that punch in the stomach directly.

Run the lab below. It literally uses JavaScript `eval()` with a sandboxed Firefox-style `Math.random()`. Leak a few outputs, then watch the panel on the right predict what comes next.

<MathRandomEvalLab />

## why this is bad even before the Firefox trick

A six digit OTP already lives in a tiny space.

It is just a number from `000000` to `999999`.

That is only a million possibilities.

Not a lot.

And the moment you see code like this, alarms should start going off.

```js
function generateOtp() {
  return Math.floor(100000 + Math.random() * 900000).toString();
}
```

This looks normal.

It is still the wrong tool.

An OTP is not a UI flourish. It is not a dice roll in a game. It is not a particle effect.

It is a security boundary.

If someone can predict it, bias it, replay it, or reduce the search space enough to make guessing practical, that becomes an account takeover problem, not a JavaScript trivia problem.

So before we even get into Firefox internals, there are already two issues here:

1. OTPs have limited entropy by design.
2. `Math.random()` is not meant to protect secrets.

<OtpEntropyExplorer />

## what math.random actually is

`Math.random()` is pseudorandom.

That means there is some hidden internal state, some deterministic update rule, and a stream of outputs that only *look* random from the outside.

The exact implementation depends on the JavaScript engine. Firefox, Chrome, and Node do not all have to use the same thing.

In the Firefox case I was looking at, the generator was based on **xorshift128+**.

Which sounds fancy but the important part is very simple.

It keeps hidden internal state.

Every call mutates that state in a predictable way.

Then JavaScript shows you part of the result as the floating point number you see in the console.

So `Math.random()` is not some mystical randomness faucet from the heavens. It is a machine.

And machines can be modeled.

## how three outputs become enough

This is the part that broke my brain a little.

Firefox's generator had 128 bits of internal state.

Each `Math.random()` call leaked about 53 bits of useful information because the returned floating point number is built from a 53 bit mantissa.

So after three observed outputs, you are roughly looking at this:

- first call gives you 53 bits
- second call gives you 53 more
- third call gives you 53 more

That is 159 bits of visible information.

The internal state is 128 bits.

Now obviously this is the intuition, not a formal proof. Some bits are discarded, the constraints are messy, and the exact transition rules matter.

But this is why the whole thing becomes solvable with enough samples.

You are no longer staring at random looking decimals. You are collecting equations.

<MathRandomRecovery />

Once the solver finds the internal state that satisfies those observed outputs, the rest is boring.

You just run the same generator forward.

That is why the script could tell me what Firefox would return next.

And Firefox, very politely, confirmed it.

## why this should scare anyone generating OTPs in JavaScript

Because a lot of people still treat `Math.random()` like it is "good enough" randomness.

It is not.

Not for:

- OTPs
- password reset tokens
- magic links
- invite codes
- session secrets
- CSRF tokens
- anything where predictability becomes compromise

Also, one more thing.

If you are generating the OTP in the browser, the user already controls that environment. They can inspect your code, patch functions, automate requests, and generally behave like a menace.

The OTP should usually be generated on the server using a cryptographically secure source of randomness, stored safely, expired aggressively, and verified server side.

So even if you replace `Math.random()` with Web Crypto in the browser, that still does not magically make client side OTP generation the right architecture.

## what to use instead

If I am generating an OTP in Node.js, I would use `crypto.randomInt()`.

```js
import { randomInt } from "node:crypto";

function generateOtp() {
  return randomInt(0, 1_000_000).toString().padStart(6, "0");
}
```

If I need secure randomness in the browser, I would use Web Crypto.

```js
function generateOtp() {
  const max = 1_000_000;
  const range = 0x1_0000_0000;
  const limit = range - (range % max);
  const buf = new Uint32Array(1);

  do {
    crypto.getRandomValues(buf);
  } while (buf[0] >= limit);

  return (buf[0] % max).toString().padStart(6, "0");
}
```

That rejection loop is there to avoid modulo bias.

Which is exactly the kind of sentence you only get to say when you are using the correct primitive in the first place.

## the deep technical dive

<Notice type="info">
This section is optional. The main argument is already done. If you skip everything below, the takeaway stays the same. Do not use <code>Math.random()</code> for OTPs.
</Notice>

The Firefox demo used a generator from the xorshift family, specifically xorshift128+.

At a high level, the hidden state is just two 64 bit values.

You can think of it like this:

```txt
state = (s0, s1)
s0 = 64 bits
s1 = 64 bits

Total hidden state = 128 bits
```

On each step, the generator mutates that pair with XOR and shift operations. In rough pseudocode, the update looks like this:

```txt
newS0 = s1

t = s0 XOR (s0 << 23)
t = t XOR (t >> 17)
t = t XOR s1
t = t XOR (s1 >> 26)

newS1 = t
x = newS0 + newS1
```

JavaScript does not hand you all of `x` directly. It exposes a floating point output derived from part of it, which is why you see about 53 useful bits per call.

So the attack intuition becomes:

```txt
3 outputs × 53 visible bits each ≈ 159 visible bits
hidden internal state = 128 bits
```

Again, that does **not** mean you literally subtract one from the other and call it solved. The constraints are over bit vectors. There are discarded bits. The transition rules have to be modeled correctly.

But it does explain why a solver can recover the hidden state once enough outputs are observed.

The mental model I like is basic school algebra, just more cursed.

If I give you:

```txt
x + y = 10
x - y = 2
```

you can recover both unknowns.

One equation is not enough.

Two starts pinning things down.

Here, each observed `Math.random()` output gives you another pile of constraints on the unknown state bits. Z3 just does the ugly part for you.

A stripped down sketch of the recovery idea looks like this:

```js
// observed outputs from Firefox
const outputs = [r1, r2, r3];

// unknown internal state
const s0 = BitVec(64);
const s1 = BitVec(64);

// symbolically run the same PRNG transition
// constrain each generated output to match r1, r2, r3
// ask Z3 for any state that satisfies all constraints

const recovered = solve(outputs, s0, s1);
const next = forward(recovered);
```

That is the whole trick.

Not magic.

Just a deterministic machine being treated like a deterministic machine.

## one subtle thing people get wrong

When I tried the same Firefox specific recovery logic against Node, it failed.

That does **not** mean Node's `Math.random()` is suddenly safe for OTPs.

It just means the exact Firefox attack was built around the exact Firefox generator.

Different engine.

Different implementation.

Same security lesson.

If something was not designed to be cryptographically secure, do not promote it into a security primitive just because it is convenient.

## my honest take

`Math.random()` is not evil.

It is just being asked to do a job it was never hired for.

Use it for quick simulations.

Use it for animations.

Use it for random colors in a toy app.

Do not use it for OTPs.

The Firefox demo is fun because it feels like a party trick.

But the real lesson is boring and important.

Random looking is not the same as secure.

And in security, that difference is the whole game. 🫡


I took three Math.random() outputs from Firefox, recovered the internal PRNG state using Z3, and predicted the next values exactly. This is why OTPs must never use Math.random() — it is not random in any security sense.

Security

The Claude Code Source Map Story Is Funny Until You Think About What It Means

I Predicted Firefox's Math.random(). Don't Use It for OTPs.