So last week, Anthropic shipped an npm package that accidentally included a source map. That source map pointed to readable TypeScript source files on their servers. A security researcher noticed, pulled the thread, and within hours the entire Claude Code codebase was mirrored on GitHub. Half a million lines of production code across about 2,000 files. The tool I build every Workhorse project on, fully exposed.

I'm not sharing any of the actual source, and be careful if you go digging around for it. Anthropic's been issuing DMCA takedowns, which is their right. But a lot of smart people analyzed what they found before those mirrors went down, and their breakdowns are worth paying attention to, especially if you're a designer running Claude Code the way I do.

I spent the weekend going through those analyses. What follows is everything that changed how I think about the tool.

It's not a chatbot. It's an agent runtime.

I think most designers assume Claude Code is basically Claude in a terminal window. You type, it responds, maybe it can peek at your files. That mental model is completely wrong.

What the source code shows is a full agent runtime built on Bun, TypeScript, and React. There's a tool system, a command system, a memory system, a permission engine, a task manager, a multi-agent coordinator, and MCP support on both the client and server side. When you type something, it passes through a CLI parser into what they call the query engine, which calls the LLM API, enters a tool execution loop, and renders the result back in your terminal. The model is just one piece of a much larger machine.

If you're treating it like a chat window, you're leaving most of the tool on the table. I'd guess 90% of the value lives in the systems wrapped around the model, not the model itself. That gap is the difference between spending a day building a full site versus spending a day arguing with your prompts.

There are 85 slash commands. You probably know five of them.

Roughly 85 slash commands showed up in the source. I knew maybe eight before this leak. Most people seem to know /help and /context and that's about it.

Here are the ones that actually moved the needle for me:

/init generates a CLAUDE.md file for your project, which functions as Claude Code's operating manual for your repo. More on this in a second because it deserves its own section.

/plan is the one I wish I'd found six months ago. It switches Claude Code into planning mode so it maps out what it wants to do before touching any files. For anything beyond a simple component, I use this by default now. It also burns fewer tokens than letting the agent trial-and-error its way through a build.

/compact compresses your conversation history. When you're four hours deep into a build and the context window is getting bloated, this trims the fat while keeping what matters. You can even tell it what to preserve: "compact but keep everything about the CMS integration." I run this constantly.

/review and /security-review are full structured review workflows. Not afterthoughts bolted on later. Dedicated first-class commands. That tells you something about how Anthropic thinks about the tool.

/cost shows your actual spend for the session. Just run it. You'll be glad you did before the invoice arrives.

/resume and /summary let you pick up where you left off between sessions. When a site build stretches across three days, these are the reason I don't have to re-explain the entire project every morning.

Halftone pattern

CLAUDE.md is the highest leverage file on your machine

The source confirms that Claude Code has a layered memory system, and CLAUDE.md sits at the center of it. I see a lot of people either skip this file entirely or treat it like a scratchpad. Both approaches waste the most powerful lever you have.

Think of it as an onboarding doc for a new hire. You wouldn't hand someone a product history essay and expect good work. You'd give them decision rules. We always use TypeScript strict mode. Components go in /components. Never touch the CMS schema without running migrations. Use pnpm, not npm. Design tokens live in tokens.ts. Keep it short, keep it opinionated, keep it operational.

At Workhorse, this file is the reason I can maintain consistency across builds. Claude Code reads it before every session. Nothing else I've found has a bigger impact on output quality, and it takes maybe 20 minutes to write a good one.

Permissions are why it feels slow

You know the thing where Claude Code stops every thirty seconds to ask if it can run a command, edit a file, execute a test? Maddening. I assumed for months that I just needed to prompt better to get around it.

Turns out the fix is way more straightforward. The source reveals a deep permission system with wildcard rules. You can set things like "allow all git commands" or "allow all file edits in my src folder" and it just stops asking. You configure these at the global, user, or project level in your settings file. Stuff you always want to allow, stuff you always want to deny, stuff you want it to ask about.

Setting up my permissions properly was maybe 15 minutes of work and it completely changed the experience. I went from babysitting every action to actually focusing on design decisions while the agent did its thing in the background.

It's built for multi-agent work

This caught me off guard. The source code reveals a coordinator subsystem with agent tools, team tools, and a task system designed for parallel work. Multiple agents can run simultaneously: one exploring the codebase, another implementing changes, another running tests. The architecture was designed for this from the ground up.

The practical takeaway is to stop writing massive prompts that try to do everything at once. "Refactor this module, update the tests, and fix the docs" as a single instruction fights the architecture instead of working with it. I've started breaking my builds into the same phases I use for agentic web design at Workhorse: research, build, humanization, QA. Each phase gets its own task and its own scope. The results have been noticeably better since I made that shift.

MCP is baked into the architecture

I've been connecting Claude Code to external tools through MCP (Model Context Protocol) for a while now, but I figured it was a bolt-on feature. The source shows otherwise. Claude Code is both an MCP client and an MCP server simultaneously. It can reach out to external tools, and other systems can reach into it. There's also a skills and plugin layer on top of that for building repeatable workflows and domain-specific extensions.

This is where it stops being a coding tool and starts being an integration layer. For web design, the MCP connections to Figma, to CMS platforms, to deployment pipelines are the reason I can take a project from concept to deployed site in days. The more tools you wire in, the more useful the whole system gets. I keep adding connections and haven't hit a ceiling yet.

There are features we haven't seen yet

Buried in the codebase are checks for a "userType" value of "ant," which gates certain capabilities for Anthropic's internal users. References to voice mode, something called Kairos, a daemon mode, and a coordinator mode all show up in the source. Some of these might be early experiments that never ship. Some might land next month. Hard to say.

What's clear is that Claude Code is heavily feature-flagged. We're using a subset of what's already built. Worth keeping an eye on updates, because anyone who already understands the underlying architecture is going to be able to pick up new features immediately.

Data rain pattern

The real takeaway: design your operating environment

If I had to boil this whole leak down to one sentence, it would be this: the people getting the most out of Claude Code aren't writing better prompts. They're building a better environment around the tool.

Keep your CLAUDE.md tight and update it as the project evolves. Learn the commands so you're working with the tool's actual capabilities instead of guessing at them. Set up your permissions once and stop fighting the approval flow. Break work into phases. Watch your token spend. Wire in external tools through MCP. Treat the whole setup like infrastructure you maintain, not an app you open.

That's how I've been running things at Workhorse for a while now. Claude Code isn't something I reach for when I need code written. It's the layer everything else runs on. This leak just showed me that the people who built it were thinking about it the same way the whole time.