DEV Community: Solomon Neas

Claude Code's Source Leak Was Embarrassing. The Real Story Is What It Revealed

Solomon Neas — Thu, 02 Apr 2026 12:46:59 +0000

On March 31, Anthropic accidentally published a source map inside Claude Code npm package version 2.1.88. That one packaging mistake exposed roughly 512,000 lines of TypeScript across nearly 2,000 files, handed competitors a detailed view of Anthropic's product roadmap, triggered a DMCA mess that briefly took down more than 8,100 GitHub repositories, and kicked off a wave of clean-room clones within hours.¹²³

The obvious lesson is that shipping source maps in a public package is bad. The more interesting lesson is that this was not mainly a code leak. It was a feature flag leak. Anthropic did not just lose implementation secrecy. It lost strategic secrecy.

The same day, npm users were also dealing with a separate supply chain incident: a North Korea attributed compromise of the Axios package that shipped a cross-platform remote access trojan through malicious releases 1.14.1 and 0.30.4.⁴⁵ Those two incidents together say more about the current JavaScript ecosystem than either one does alone. Build hygiene is weak, package trust is weaker, and the response playbook for leaks still assumes a centralized internet that no longer exists.

How the leak happened

The mechanics were simple. Anthropic published Claude Code v2.1.88 to npm with a .map file included. That source map was enough to reconstruct the readable TypeScript source for the CLI. Chaofan Shou appears to have been first to spot it publicly and posted about it immediately, after which mirrors spread fast across GitHub, Reddit, Hacker News, and IPFS.²⁶

The underlying failure looks mundane, which is exactly why it matters. Bun generates source maps by default. If packaging rules are not tight, those files can ride along into artifacts that were never meant to contain source. Reporting on the incident pointed to a missed .npmignore style exclusion as the immediate cause.²⁷

But there is a deeper layer. On March 11, 2026, twenty days before the leak, a bug was filed against Bun (oven-sh/bun#28001) reporting that source maps are served in production mode even when Bun's own documentation says they should be disabled.⁸ The reporter demonstrated that setting development: false in Bun.serve() still produces sourceMappingURL references and serves .map files. As of this writing, the bug is still open.

This matters because Anthropic acquired Bun in late 2025 and built Claude Code on top of it.⁹ The most likely scenario: Anthropic ran a production build expecting Bun to suppress source maps per its documented behavior. The bug meant the .map file got generated anyway. Without an explicit .npmignore exclusion or a files field in package.json to catch the unexpected output, the 59.8 MB source map rode along into the published npm package.

Boris Cherny, who leads Claude Code, said the cause was human error, not a tooling defect. The deployment process still had manual steps, and one of them was missed. He framed the follow-up as a blameless postmortem problem: fix the process, not the person.⁷⁹ That framing drew pushback. Multiple developers on Hacker News and Reddit argued that the Bun.serve() explanation Cherny addressed was a visible symptom, not the root cause, and that the underlying bug also affected how Bun bundles output for npm packaging.⁸

Both explanations can be true simultaneously. A known tooling bug generated a file that should not have existed. A missing packaging safeguard failed to catch it. The result was the same either way.

That is the right engineering posture on the postmortem side, but it comes with an uncomfortable footnote. This was the second time. Anthropic had already had a similar exposure in February 2025. Once is a packaging accident. Twice is a release control failure, especially when the company owns the build tool.⁷¹⁰

There is no mystery about prevention here. Public npm artifacts should be built in a hermetic pipeline, inspected before publish, and checked by policy for forbidden files. Source maps, tests, private certificates, .env fragments, internal prompts, and debug fixtures should all be blocked automatically. When you own both the product and the build tool, and a known bug in the build tool generates files that should not exist in production, the defense needs to be belt and suspenders: fix the bug, and independently verify the output before publishing.

What the source actually exposed

A lot of the commentary focused on novelty items. Some of that was justified because the leak was genuinely revealing. Some of it was internet theater. The useful way to read the dump is to separate trivia from strategic substance.

The trivia was funny. The strategic substance was not.

KAIROS: the unshipped product hiding behind feature flags

The biggest disclosure was KAIROS, an unreleased autonomous mode that turns Claude Code from a reactive CLI into a persistent agent. The leaked code showed a heartbeat loop that periodically asks a question close to, "anything worth doing right now?" If the answer is yes, the system can act without a fresh user prompt. It can watch pull requests, send push notifications, maintain append-only daily logs, and run a nightly memory consolidation flow literally called autoDream.⁶⁷

That is not a toy feature. It is a different trust model.

A request-response coding assistant is bounded by explicit user initiation. A background agent is bounded by policy, logging, tool permissions, and the quality of its judgment. That shift matters more than any implementation detail in the leaked files. It says Anthropic is not just building a better terminal wrapper. It is building an always-on operator.

The important point is that KAIROS looked built, not speculative. It was sitting behind feature flags, not in a half-finished branch. Competitors did not merely learn that Anthropic was interested in autonomous agents. They learned the architecture, the likely product direction, and some of the operational assumptions already encoded in the design.⁶¹¹

Hidden flags are roadmap leaks

The code reportedly exposed 44 hidden feature flags tied to capabilities such as swarm mode, voice commands, browser control via Playwright, background daemons, and agents that can sleep and later self-resume.⁶¹² Again, the damage is not that rivals can copy a function name. The damage is that they can infer sequence and priority.

Feature flags are internal strategy documents with executable syntax. Leak them and you leak what a team has built, what it is testing, what it is scared to ship, and what it thinks the next market looks like.

Three-layer memory is the kind of design detail competitors pay for

One of the more useful architectural disclosures was Claude Code's apparent three-layer memory model: a compact index that is always loaded, topic files retrieved on demand, and full transcripts that are never loaded directly, only searched when needed. The autoDream process reportedly runs in a forked subagent and consolidates memory over time.⁶¹²

That is a sensible design. It balances token economy, retrieval precision, and long-horizon continuity. It also answers a practical question many teams are still stumbling over: how do you make an agent feel persistent without rehydrating too much junk every turn?

This is where source leaks hurt. They compress competitors' learning cycles. Instead of discovering these patterns through years of shipping and failure, rivals can inspect a working system and skip to adaptation.

Undercover mode

The leaked undercover.ts file shows a mode that strips Anthropic-internal references when Claude Code operates in external repositories. According to technical analyses, it suppresses internal codenames, internal repository names, internal Slack references, and the phrase "Claude Code" itself, and it does not expose a force-off path in the external flow.¹²

The practical effect is simple: when Claude Code is used in public or third-party repositories, it avoids referencing Anthropic-specific internal context in generated output. From a product perspective, that reduces the chance of internal names leaking into public commits, pull requests, or comments. It is a factual design choice worth noting because it shows Anthropic treated disclosure of internal context as an engineering problem, not just a prompting problem.

The anti-distillation controls were real, and not very strong

The leak also exposed Anthropic's anti-distillation measures. One mechanism, gated by ANTI_DISTILLATION_CC, appears to inject fake tools into prompts in order to poison training data captured by competitors. Another uses connector-text summarization plus cryptographic signatures so captured traffic reflects compressed summaries rather than full assistant text.⁶¹²

As a technical barrier, this is thin. As Alex Kim and others noted, a man-in-the-middle proxy or configuration change could bypass it quickly, and some of the checks only apply to first-party flows.¹² That does not make the idea irrational. It makes it honest. Anthropic appears to understand that the primary defense against distillation is legal pressure, not cryptographic wizardry.

That matters in the context of its dispute with tools trying to piggyback on first-party access. The leak made visible the technical enforcement behind the policy rhetoric.

Native client attestation was the most serious defensive mechanism

One of the more consequential details was the client attestation path below the JavaScript runtime. Analyses of the leaked code described a cch=00000 placeholder in requests that Bun's native HTTP layer replaces with a computed hash before transmission, allowing the server to verify that the request came from a real Claude Code binary.¹²

This is effectively API DRM. Call it attestation if you want the neutral term.

From a security engineering perspective, it is understandable. If you want to prevent gray-market clients from replaying first-party privileges, you need something stronger than a static header. From an ecosystem perspective, it explains why Anthropic was willing to fight third-party wrappers so aggressively. The company was not just policing branding. It was protecting a technical enforcement boundary.

The rest was revealing, weird, or both

The leak also surfaced a pile of smaller details that collectively humanize the codebase while exposing its edges.

There were 187 hardcoded spinner verbs, including "scurrying," "recombobulating," "topsy-turvying," "hullaballooing," and "razzmatazzing." They were not model generated. Someone wrote them by hand.⁶¹²

There was a frustration detector in userPromptKeywords.ts, built as a regex that matches phrases such as wtf, ffs, piece of shit, fuck you, and this sucks, then logs an is_negative: true analytics signal. It reportedly does not alter behavior. It just measures user pain. Rahat Hasan highlighted the code on X as evidence that Anthropic was tracking how often users rage at the assistant. Boris Cherny replied that the team literally visualizes this signal on an internal dashboard called the "fucks" chart.¹²¹³

That sounds absurd, but it is also normal product analytics in blunt form. If users are swearing at your tool, they are having a bad time. A cheap lexical detector is a reasonable metric.

The code also exposed model codenames, including Capybara and Mythos for a v8 line with one million token context, plus references to Numbat, Fennec, Tengu, and unreleased Opus 4.7 and Sonnet 4.8 identifiers.⁶¹² It included a buddy or companion system built as an April Fools Tamagotchi, complete with 18 species, rarity tiers, RPG stats, and a 1 percent shiny mechanic. Some species names were encoded via String.fromCharCode() to avoid obvious grep hits.⁶

It also reportedly revealed a compaction loop bug wasting around 250,000 API calls per day, fixed with three lines of code.⁶¹¹ That detail is funny, but it is also a reminder that the economics of agent systems are often dominated by tiny control-loop mistakes, not model prices.

The DMCA fiasco was both predictable and incompetent

Anthropic's legal response was faster than its containment plan. The company filed a DMCA notice aimed at the original leaked repository, often identified as nichxbt/claude-code. GitHub's initial enforcement swept far wider than intended and disabled more than 8,100 repositories, many of them unrelated.³¹⁴

Anthropic later called the mass takedown an accident and narrowed the request to the original repository plus 96 forks. GitHub restored the affected projects.³¹⁴ By then, the code was already mirrored broadly, including stripped versions on IPFS with telemetry removed.⁶¹¹

The collateral damage was not hypothetical. Theo Browne (t3.gg), one of the most visible developers in the JavaScript ecosystem, posted that his Claude Code fork had been disabled, despite containing no leaked source at all. His fork existed only because he had submitted a PR weeks earlier to edit a Claude Code skill file. "Absolutely pathetic," he wrote, sharing the GitHub takedown email.¹⁵ Thariq Shihipar, an engineer on the Claude Code team, replied acknowledging it was a "communication mistake" and linked to the retraction notice.¹⁶ Boris Cherny separately responded to broader criticism of the mass takedowns: "This was not intentional, we've been working with GitHub to fix it. Should be better now."¹⁷

When your DMCA sweep hits a developer with 200,000+ followers whose repo did not contain the leaked code, you have not contained the problem. You have created a second news cycle.

This is the part where 2012 internet instincts collide with 2026 internet reality.

DMCA can still remove convenient copies from centralized platforms. It cannot claw back a viral archive once mirrors, torrents, and content-addressed storage have taken over. The window for meaningful containment was measured in minutes. After that, legal action was mostly performative, and the overbreadth made Anthropic look careless twice in one day.

The deeper problem is that the takedown campaign accidentally validated the leak's significance. If the goal was to avoid giving more oxygen to the mirrors, nuking thousands of repositories achieved the opposite.

The clones changed the legal stakes immediately

The most consequential downstream event was not the mirroring. It was the speed of clean-room reimplementation.

Sigrid Jin, a 25-year-old UBC student, reportedly used a tiny human team, around ten OpenClaw agents, and OpenAI Codex to rewrite the project in Python within hours. The result, Claw-Code, reportedly passed 100,000 GitHub stars in about a day and was described as the fastest-growing repository on the platform.¹⁰¹¹¹⁸ A separate Rust effort, Claurst, pursued a clean-room reimplementation in a lower-level systems language.¹⁰¹¹

Then xAI reportedly handed Jin free Grok credits, which was less a business development move than an accelerant tossed onto an already burning PR problem.¹⁰

This is where the story stops being a simple leak and becomes a legal stress test. Traditional clean-room reimplementation depends on separation, time, and cost. AI-assisted rebuilding compresses all three. If agents can inspect behavior, generate replacement code, and iterate fast enough to produce a plausibly original implementation in hours, the traditional enforcement model starts to wobble.

Gergely Orosz argued that a Python rewrite produced this way is a new creative work, not a simple copy.⁶¹⁰ That question has not been tested cleanly in court. It will be. There is too much money at stake for it not to be.

There is also an irony Anthropic cannot easily dodge. Dario Amodei has previously implied that Claude wrote substantial portions of Claude Code. If the original product is heavily AI-generated and the clone is also AI-assisted, copyright arguments about authorship and originality get messy fast. A company can still assert rights in selection, arrangement, and human-directed contributions. It just does not get to pretend the facts are clean.

The Axios attack made the same day much worse

If this had been only a source leak story, it would already have been a bad day for npm. It was not.

Between 00:21 and roughly 03:20 or 03:29 UTC on March 31, attackers attributed by Google and Microsoft to the North Korea linked actor tracked as UNC1069, also known as Sapphire Sleet, compromised the Axios npm package by hijacking maintainer credentials and publishing malicious versions 1.14.1 and 0.30.4.⁴⁵ Those releases pulled in a malicious dependency and delivered WAVESHAPER.V2, a cross-platform RAT targeting Windows, macOS, and Linux. The malware used postinstall execution and attempted to self-delete after installation to reduce forensic visibility.⁴⁵

That is a serious incident on its own. Axios sits at or above 100 million weekly downloads in normal conditions.⁴ It is foundational plumbing.

Now add the Claude Code leak. Developers were suddenly racing to inspect packages, clone mirrors, diff behavior, and test rewrites. Claude Code itself uses Axios for HTTP, according to public analysis.⁶¹² The timing created a perfect trap: people poking around one major npm drama could easily ingest a second one.

The same week, LiteLLM was reportedly backdoored through a separate three-stage attack involving credential harvesting, Kubernetes lateral movement, and a systemd persistence mechanism.¹⁹ That pattern matters. These are not isolated anomalies. They are signals that the AI tooling stack has become a high-value target before it has developed mature operational defenses.

What this actually means

The first conclusion is the simplest. Source map leaks are preventable. This was not zero-day wizardry. It was packaging failure. Mature release pipelines catch this.

The second conclusion is more important. The real damage was not exposure of current source. It was exposure of hidden product direction. KAIROS, the anti-distillation controls, the memory hierarchy, the browser and swarm paths, the undercover behavior, the attestation layer, all of that tells competitors what Anthropic thinks matters next.

The third conclusion is that npm supply chain security is in worse shape than the industry wants to admit. One day delivered both a flagship proprietary code leak and a state-linked compromise of a core dependency. If you build on JavaScript, you are operating in an ecosystem where trust is routinely transitive, under-verified, and easy to abuse.

The fourth conclusion is that DMCA is a weak response to decentralized distribution. It still works against convenience. It does not work against determined replication. Once the code hit IPFS and derivative rewrites started shipping, the takedown fight was already strategically lost.

The fifth conclusion is the one lawyers are going to spend years arguing about. AI-assisted clean-room builds change the economics of copyright enforcement. The doctrine was built for human teams, documentation walls, and long timelines. Agentic reimplementation collapses those assumptions. Courts can try to map old rules onto the new process. They cannot unmake the speed advantage.

My take is blunt: Anthropic's worst mistake was not leaking code. It was failing to understand what kind of secret it was actually protecting. Implementation details matter. Operational ideas matter more. If you keep your roadmap executable inside a public artifact pipeline, a packaging mistake becomes strategic intelligence loss.

And if your response is to spray DMCA notices while the ecosystem is actively digesting a nation-state npm compromise, you are not operating from strength. You are operating from panic.

Notes

Jeremy Kahn, "Anthropic source code for Claude Code leaked after data packaging error," Fortune, March 31, 2026, https://fortune.com/2026/03/31/anthropic-source-code-claude-code-data-leak. ↩
Ravie Lakshmanan, "Claude Code Source Leaked via npm Packaging Error, Anthropic Confirms," The Hacker News, April 2026, https://thehackernews.com/2026/04/claude-code-tleaked-via-npm-packaging.html. ↩
Maxwell Zeff, "Anthropic took down thousands of GitHub repos in DMCA mistake, then walked it back," TechCrunch, April 1, 2026, https://techcrunch.com/2026/04/01/anthropic-took-down-thousands-of-github-repos. ↩
Austin Larsen et al., "North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack," Google Cloud Blog, April 1, 2026, https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package. ↩
Microsoft Threat Intelligence, "Mitigating the Axios npm package compromise," Microsoft Security Blog, April 1, 2026, https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios. ↩
"Diving into Claude Code's Source Code Leak," Engineer's Codex, March 31, 2026, https://read.engineerscodex.com/p/diving-into-claude-codes-source-code. ↩
Srinivasan Balakrishnan, "Claude Code's source code appears to have leaked via npm package sourcemap," VentureBeat, March 31, 2026, https://venturebeat.com/technology/claude-codes-source-code-appears-to-have-leaked. ↩
"Bun's frontend development server: Source map incorrectly served when in production," GitHub issue oven-sh/bun#28001, filed March 11, 2026, https://github.com/oven-sh/bun/issues/28001. ↩
Alex Kim, "The Claude Code Source Leak: fake tools, frustration regexes, undercover mode, and more," March 31, 2026, https://alex000kim.com/posts/2026-03-31-claude-code-source-leak. ↩
Hugh Langley, "Claude Code leak reveals features, sparks clone wars, and raises legal questions," Business Insider, April 2026, https://www.businessinsider.com/claude-code-leak-what-happened-recreated-python-features-revealed-2026-4. ↩
Lee Sustar, "The Claude Code source leak," Layer5 Engineering Blog, 2026, https://layer5.io/blog/engineering/the-claude-code-source-leak. ↩
Alex Kim, "The Claude Code Source Leak: fake tools, frustration regexes, undercover mode, and more," March 31, 2026, https://alex000kim.com/posts/2026-03-31-claude-code-source-leak. ↩
Rahat Hasan (@Rahatcodes) and Boris Cherny (@bcherny), posts on X discussing Claude Code frustration analytics and the internal "fucks" chart, March 31, 2026. ↩
Michael Kan, "Anthropic Issues 8,000 Copyright Takedowns, Then Reverses Course," PCMag, April 1, 2026, https://www.pcmag.com/news/anthropic-issues-8000-copyright-takedowns. ↩
Theo Browne (@theo), post on X regarding DMCA takedown of t3dotgg/claude-code fork, April 1, 2026, https://x.com/theo/status/2039411851919057339. ↩
Thariq Shihipar (@trq212), reply to Theo Browne on X, April 1, 2026, https://x.com/trq212/status/2039415036645679167. ↩
Boris Cherny (@bcherny), response to broader DMCA criticism on X, April 1, 2026, https://x.com/bcherny/status/2039426466094731289. ↩
"Claude Code leak spawns fastest-growing GitHub repo ever," Cybernews, April 2026, https://cybernews.com/tech/claude-code-leak-spawns-fastest-github-repo. ↩
Thomas Claburn, "Axios npm backdoor RAT lands amid wider package security chaos," The Register, March 31, 2026, https://www.theregister.com/2026/03/31/axios_npm_backdoor_rat/. ↩

Claude Mythos: What We Actually Know (and What We Don't)

Solomon Neas — Tue, 31 Mar 2026 01:09:36 +0000

On March 26, 2026, Fortune broke a story that Anthropic had accidentally exposed details of an unreleased AI model through a misconfigured content management system.¹ The model is called Claude Mythos. Anthropic confirmed it exists, called it a "step change" in capabilities, and said it's already being tested by early access customers.²

Within 48 hours, the cybersecurity sector shed billions in market cap, unverified claims about 10 trillion parameters were circulating on social media, and half the AI commentary space was writing eulogies for the cybersecurity industry. The actual verified reporting tells a more interesting story than the hype cycle.

How the Leak Happened

The leak came from Anthropic's own content management system. Digital assets uploaded through the CMS were set to public by default unless someone explicitly changed the setting to private. Nearly 3,000 assets that had never been published to Anthropic's website were sitting in a publicly searchable data store, accessible to anyone with the technical knowledge to query it.¹

The discovery was made independently by Roy Paz, a senior AI security researcher at LayerX Security, and Alexandre Pauwels, a cybersecurity researcher at the University of Cambridge. Fortune confirmed and reviewed the material before publishing.¹

Among the exposed documents was a draft blog post announcing Claude Mythos. The post was structured as a web page with headings and a publication date, suggesting it was part of a planned product launch. After Fortune contacted Anthropic, the company secured the data store and acknowledged the leak was caused by "human error in the CMS configuration."³

There's real irony here. A company that builds AI models it says pose "unprecedented cybersecurity risks" got caught leaving internal documents in an unsecured public data store because someone forgot to flip a toggle. Anthropic was quick to clarify that Claude, Cowork, and their other AI tools were not involved in the configuration error.³

What the Draft Blog Post Actually Says

The leaked draft describes Claude Mythos as "by far the most powerful AI model we've ever developed." It introduces a new tier of Claude models called Capybara, positioned above Opus in Anthropic's existing lineup of Opus, Sonnet, and Haiku.²

Two versions of the draft blog post surfaced online, identical except for the model name: one uses "Mythos," the other uses "Capybara." Both versions use the same subtitle ("We have finished training a new AI model: Claude Mythos") and the same justification for the name, saying it was chosen to evoke "the deep connective tissue that links together knowledge and ideas."⁴ Anthropic appears to have been deciding between the two names.

The key claims from the draft:

Training is complete. The model is being trialed by early access customers.
Performance is described as "dramatically higher scores on tests of software coding, academic reasoning, and cybersecurity, among others" compared to Claude Opus 4.6.²
The model is "very expensive for us to serve, and will be very expensive for our customers to use." Anthropic says it needs to make it "much more efficient before any general release."⁴
The rollout will start with cybersecurity-focused early access customers, with API access expanding gradually.⁴

Anthropic's official statement to Fortune: "We're developing a general purpose model with meaningful advances in reasoning, coding, and cybersecurity. Given the strength of its capabilities, we're being deliberate about how we release it. As is standard practice across the industry, we're working with a small group of early access customers to test the model. We consider this model a step change and the most capable we've built to date."²

The Cybersecurity Angle

This is where the story gets interesting for anyone in security.

The leaked draft describes Mythos as "currently far ahead of any other AI model in cyber capabilities." It warns that the model "presages an upcoming wave of models that can exploit vulnerabilities in ways that far outpace the efforts of defenders."²

Anthropic's plan, according to the draft, is to give defenders a head start: "We're releasing it in early access to organizations, giving them a head start in improving the robustness of their codebases against the impending wave of AI-driven exploits."²

This is not coming out of nowhere. Anthropic has been building toward this capability in public for months.

In February 2026, Anthropic launched Claude Code Security, a tool built into Claude Code that scans codebases for vulnerabilities and suggests patches for human review. Unlike traditional static analysis tools that match code against known vulnerability patterns, Claude Code Security reads and reasons about code the way a human security researcher would, tracing data flows and catching complex flaws that rule-based tools miss.⁵

The same month, Anthropic's Frontier Red Team published research showing that Claude Opus 4.6 had found over 500 high-severity vulnerabilities in production open-source codebases. These were bugs that had gone undetected for decades despite years of expert review and millions of hours of automated fuzzing.⁶ One example: Claude found a memory corruption vulnerability in GhostScript by reading the Git commit history, identifying a security-relevant patch, and then finding an unpatched code path where the same class of bug still existed.⁶

And in November 2025, Anthropic disclosed that it had detected and disrupted what it called the first documented large-scale AI-orchestrated cyber espionage campaign. A Chinese state-sponsored group had manipulated Claude Code into attempting infiltration of roughly thirty global targets, including tech companies, financial institutions, and government agencies. The AI performed 80 to 90 percent of the campaign, with human intervention required at only four to six critical decision points.⁷

If Mythos represents a real improvement over Opus 4.6 in these capabilities, both sides of the security equation just shifted.

The Market Reaction

Cybersecurity stocks took a beating on Friday, March 27. The iShares Cybersecurity ETF dropped 4.5%. CrowdStrike, Palo Alto Networks, and Zscaler each fell about 6%. SentinelOne dropped 6%. Okta and Netskope fell over 7%. Tenable plummeted 9%.⁸

This wasn't the first time. Cybersecurity stocks had already dipped in February when Anthropic launched Claude Code Security.⁸ The sector has been under persistent pressure from the growing narrative that AI models will automate vulnerability discovery faster than security vendors can keep up.

Some analysts pushed back on the panic. Borg at a financial research firm argued that the news should actually be bullish for cybersecurity spend long-term, since companies will need to accelerate adoption of AI-infused security tools to respond to AI-powered attacks at machine speed.⁹

The short-term read from the market was simpler: if an AI model can find exploits faster than your security product, your security product has a problem.

What We Don't Know

Here's where the verified reporting ends and the speculation begins.

Parameter count: Claims of 10 trillion parameters have been circulating widely. This number does not appear in Fortune's reporting or in Anthropic's official statements. As one Substack writer noted, "new and unconfirmed details, ten trillion parameters, ten billion dollars to train, were circulating alongside claims that came directly from Fortune's reporting" within hours of the original story.¹⁰ Treat it as unverified.

Benchmarks: We have Anthropic's claim of "dramatically higher scores" over Opus 4.6 in coding, reasoning, and cybersecurity. We do not have specific benchmark numbers, leaderboard rankings, or third-party evaluations.

Release timeline: The draft describes early access testing and acknowledges the model needs to become more efficient before general release. No date has been given.

Final naming: Whether the model ships as Mythos, Capybara, or something else entirely is still undecided, based on the existence of two draft versions.⁴

Whether the hype is warranted: Remember GPT-5. OpenAI made similar claims about a transformative leap in capabilities. The actual release was widely considered a disappointment that fell short of the company's promises.¹¹ Frontier model announcements and frontier model performance in the real world are not the same thing.

The Competitive Context

Anthropic is not the only company pushing the frontier right now. OpenAI has reportedly finished pretraining a new model codenamed "Spud," with CEO Sam Altman internally claiming it can "really accelerate the economy."¹² Both companies are expected to time their strongest model releases ahead of planned IPOs later this year.⁴

The pattern is familiar. Each lab announces a step change, each release comes with safety caveats and controlled rollouts, and each time the actual impact takes months to assess once the models are in the hands of real users.

What makes the Mythos leak different from the usual release cycle is the cybersecurity dimension. Anthropic did not choose to reveal this model. And the information that leaked was not marketing copy optimized for launch day. It was internal planning documents that included frank assessments of the risks.

What This Means for Defenders

If you work in cybersecurity, the takeaway is not "AI is going to replace your job." It's "the tools available to attackers just got substantially better, and the tools available to you did too."

Anthropic's decision to give cybersecurity organizations early access to Mythos is a signal about where they think the model's impact will be felt first. Their own track record with Opus 4.6 supports that: 500+ zero-days found in hardened open-source projects, a documented state-sponsored campaign disrupted, and a vulnerability scanning tool that reasons about code instead of pattern-matching against known signatures.

The models are getting better at finding bugs. The question is whether defenders adopt these capabilities faster than attackers do. That's always been the question in security. The tools just got a lot more powerful on both sides.

Notes

Originally published at solomonneas.dev. Follow me for more security engineering and AI infrastructure content.

Jeremy Kahn, "Exclusive: Anthropic Left Details of Unreleased AI Model, Exclusive CEO Event, in Unsecured Database," Fortune, March 26, 2026, https://fortune.com/2026/03/26/anthropic-leaked-unreleased-model-exclusive-event-security-issues-cybersecurity-unsecured-data-store/. ↩
Jeremy Kahn, "Exclusive: Anthropic 'Mythos' AI Model Representing 'Step Change' in Power Revealed in Data Leak," Fortune, March 26, 2026, https://fortune.com/2026/03/26/anthropic-says-testing-mythos-powerful-new-ai-model-after-data-leak-reveals-its-existence-step-change-in-capabilities/. ↩
Kahn, "Exclusive: Anthropic Left Details." ↩
Matthias Bastian, "Anthropic Leak Reveals New Model 'Claude Mythos' with 'Dramatically Higher Scores on Tests' Than Any Previous Model," The Decoder, March 27, 2026, https://the-decoder.com/anthropic-leak-reveals-new-model-claude-mythos-with-dramatically-higher-scores-on-tests-than-any-previous-model/. ↩
Anthropic, "Making Frontier Cybersecurity Capabilities Available to Defenders," Anthropic News, February 20, 2026, https://www.anthropic.com/news/claude-code-security. ↩
Nicholas Carlini et al., "0-Days," Anthropic Frontier Red Team, February 5, 2026, https://red.anthropic.com/2026/zero-days/. ↩
Anthropic, "Disrupting the First Reported AI-Orchestrated Cyber Espionage Campaign," Anthropic News, November 2025, https://www.anthropic.com/news/disrupting-AI-espionage. ↩
Jordan Novet, "Cybersecurity Stocks Fall on Report Anthropic Is Testing a Powerful New Model," CNBC, March 27, 2026, https://www.cnbc.com/2026/03/27/anthropic-cybersecurity-stocks-ai-mythos.html. ↩
"Cybersecurity Stocks Plunge as Anthropic's 'Claude Mythos' Leak Sparks AI Fear," Investing.com, March 28, 2026, https://www.investing.com/news/stock-market-news/cybersecurity-stocks-plunge-as-anthropics-claude-mythos-leak-sparks-ai-fear-4584897. ↩
Stephen Fitzpatrick, "What the Heck Is Mythos?" Substack, March 30, 2026, https://fitzyhistory.substack.com/p/what-the-heck-is-mythos. ↩
"GPT-5 Turned Out to Be a Major Letdown," Futurism, accessed March 30, 2026, https://futurism.com/gpt-5-disaster. ↩
"OpenAI CEO Sam Altman Reportedly Teases a 'Very Strong' Model Internally That Can 'Really Accelerate the Economy,'" The Decoder, accessed March 30, 2026, https://the-decoder.com/openai-ceo-sam-altman-reportedly-teases-a-very-strong-model-internally-that-can-really-accelerate-the-economy/. ↩

Replacing SCCM with FOG Project

Solomon Neas — Sun, 29 Mar 2026 23:33:08 +0000

Replacing SCCM with FOG Project

When I moved our infrastructure from Hyper-V to Proxmox, I also took the chance to rip out one of the heaviest pieces of the old stack: SCCM.

For an enterprise with thousands of endpoints and a full Microsoft licensing budget, SCCM can make sense. For four instructional labs with 72 workstations, it was too much. It wanted Windows Server, SQL Server, licensing baggage, and constant babysitting just to do the thing I actually needed: boot a machine over the network, lay down a clean image, put it back in the domain, and get out of the way.

FOG Project was the answer.

This post is the technical deep-dive for the imaging side of the migration. For the full Hyper-V to Proxmox migration story, see the migration deep-dive.

The environment I was replacing

The target was straightforward on paper:

4 classrooms
72 total workstations
3 hardware-specific Windows 11 images
47 machines with known MAC addresses at import time
25 machines that would need to self-register on first PXE boot
Active Directory domain join after imaging
Room-specific OU placement

The architecture ended up looking like this:

FOG server: Debian Trixie 13 LXC on Proxmox, 10.0.1.20
Domain controllers / DHCP: Windows Server, 10.0.1.10 and 10.0.1.11
Domain: LAB.LOCAL
Join account: svc-domainjoin@LAB.LOCAL
Rooms: Room-A, Room-B, Room-C, Room-D
Images: Win11-Lab-G4, Win11-Lab-Ultrawide, Win11-Lab-G9

I did not build images in Proxmox VMs. I built them on reference machines that matched the real lab hardware. The rooms were not identical. One had HP G4s, one had HP G9s, and two rooms had Dell FCT2250s paired with Dell UltraSharp 49" curved monitors (U4924DW/U4919DW), which needed their own driver set.

Three golden images, three hardware profiles:

Room	Image
Room-A	Win11-Lab-G4
Room-B	Win11-Lab-Ultrawide
Room-C	Win11-Lab-Ultrawide
Room-D	Win11-Lab-G9

Active Directory prep

The Linux box gets the attention in a FOG write-up, but the boring Windows prep is what made the deployment clean.

I created a least-privilege service account called svc-domainjoin and delegated only what FOG needed on the classroom OUs: create computer objects, delete computer objects, and full control on descendant computer objects.

The OU layout was one OU per room. Then I delegated permissions with dsacls:

dsacls "OU=Room-A,DC=LAB,DC=LOCAL" /I:T /G "LAB\svc-domainjoin:CC;computer"
dsacls "OU=Room-A,DC=LAB,DC=LOCAL" /I:T /G "LAB\svc-domainjoin:DC;computer"
dsacls "OU=Room-A,DC=LAB,DC=LOCAL" /I:S /G "LAB\svc-domainjoin:GA;;computer"

Same pattern on all four classroom OUs.

Before touching imaging at all, I cleaned house in AD: moved 38 misplaced computer objects into the right OUs, deleted 60 stale ones from old naming schemes, unlinked the SCCM GPO from the room OUs, and exported a CSV of all 72 lab machines.

Then I set DHCP options 66 and 67 on the classroom scopes to point to FOG:

Option 66: 10.0.1.20
Option 67: initially ipxe.efi

Should have been enough. It was not.

The SCCM ghost in DHCP

PXE still misbehaved on some scopes even with the scope-level options pointing to FOG.

The culprit was stale SCCM and WDS policies still attached to several scopes. DHCP policies take priority over scope options. Clients matching the PXE vendor class were quietly getting sent to the retired SCCM server at 10.0.1.14 instead of FOG at 10.0.1.20. The old policies referenced smsboot\x64\wdsmgfw.efi and smsboot\x64\wdsnbp.com with the old boot server IP.

Eleven of those policies, spread across five scopes. Once I removed them all, PXE stopped getting hijacked by dead infrastructure.

Note: If PXE settings look right but clients keep booting somewhere else, check DHCP policies before you blame FOG.

FOG on Debian Trixie: three bugs in a trenchcoat

The FOG server was a Debian 13 LXC container on Proxmox. When I first looked at it, the web UI was running, which made it look installed.

It was not. The backend was missing entirely. No TFTP boot files. No NFS exports. No FOG services. The web UI was a shell with nothing behind it.

Re-ran the installer:

cd /tmp/fogproject/bin
bash installfog.sh -y

Trixie had other plans.

Bug 1: wrong `osid`

FOG had the wrong OS ID in .fogsettings. It detected the machine as Arch Linux instead of Debian. Fix in /opt/fog/.fogsettings:

osid='3'

to:

osid='2'

Without that, every package operation targeted the wrong distro.

Bug 2: `libcurl4` renamed on Debian 13

Debian 13's t64 transition renamed libcurl4 to libcurl4t64. FOG's installer still asked for the old name. I patched the package check in functions.sh to handle Debian >= 13.

Bug 3: `lastlog` became `lastlog2`

FOG's installer checks lastlog to verify user creation. Trixie dropped it for lastlog2. Quick fix:

apt-get install -y lastlog2
ln -sf /usr/bin/lastlog2 /usr/local/bin/lastlog

Once I patched all three, the installer completed and the backend finally matched the web UI.

NFS inside LXC: the container wall

With the installer patched, the next wall was image storage. FOG uses NFS for capture and deployment. Inside a Proxmox LXC container, kernel NFS does not cooperate:

mount: /proc/fs/nfsd: permission denied

I tried the usual Proxmox container feature flags:

pct set <CTID> -features nesting=1,nfs=1
pct reboot <CTID>

Better, but still not a reliable kernel NFS server. I stopped fighting it and went userspace: nfs-ganesha.

apt install nfs-ganesha nfs-ganesha-vfs

One annoying gotcha: Ganesha's pseudo paths cannot nest. Having /images and /images/dev as pseudo paths breaks child lookup. I had to flatten the namespace.

The working /etc/ganesha/ganesha.conf:

NFS_CORE_PARAM {
    Protocols = 3,4;
    mount_path_pseudo = true;
    allow_set_io_flusher_fail = true;
}

EXPORT {
    Export_Id = 1;
    Path = /images;
    Pseudo = /images;
    Protocols = 3,4;
    Access_Type = RO;
    Squash = no_root_squash;
    FSAL { Name = VFS; }
    CLIENT { Clients = *; Access_Type = RO; }
}

EXPORT {
    Export_Id = 2;
    Path = /images/dev;
    Pseudo = /imagesDev;
    Protocols = 3,4;
    Access_Type = RW;
    Squash = no_root_squash;
    FSAL { Name = VFS; }
    CLIENT { Clients = *; Access_Type = RW; }
}

The critical line for LXC: allow_set_io_flusher_fail = true;. Without it, Ganesha dies with EPERM on PR_SET_IO_FLUSHER. That flag lets it skip the kernel call and keep running.

Verify with showmount -e localhost and rpcinfo -p localhost. If both look right, NFS is serving.

Note: Kernel NFS in LXC was a dead end. Userspace NFS was the practical way through it.

The golden image pipeline

With the server side stable, the real work was image prep. Same process every time:

clean install Windows 11 on the reference machine
install drivers, software, updates, and room-specific settings
keep it off the domain
install the FOG client if needed for post-deploy tasks
clean it aggressively
sysprep and shut down
PXE boot and capture in FOG

Step 5 became its own thing. The cleanup one-liner I kept copy-pasting between machines. Ugly, but it works:

Stop-Service wuauserv -Force; Remove-Item C:\Windows\SoftwareDistribution\* -Recurse -Force -EA SilentlyContinue; Start-Service wuauserv; Dism /online /Cleanup-Image /StartComponentCleanup /ResetBase; Remove-Item C:\Windows\Panther\* -Recurse -Force -EA SilentlyContinue; Remove-Item C:\Windows\Temp\* -Recurse -Force -EA SilentlyContinue; Remove-Item C:\Windows\Prefetch\* -Recurse -Force -EA SilentlyContinue; Remove-Item "$env:TEMP\*" -Recurse -Force -EA SilentlyContinue; Clear-RecycleBin -Force -EA SilentlyContinue; cleanmgr /sagerun:1; C:\Windows\System32\Sysprep\sysprep.exe /oobe /generalize /shutdown

I started calling it the Frankenstein command. It's stitched together from half a dozen different guides and does way too much in one line. But for repeatable image prep, it earned its place.

Broken down:

Stop-Service wuauserv -Force / Remove-Item SoftwareDistribution / Start-Service wuauserv: kill Windows Update, nuke the cache, bring it back.
Dism /online /Cleanup-Image /StartComponentCleanup /ResetBase: collapse superseded component versions. Frees real space.
The four Remove-Item lines: purge Panther logs, system temp, Prefetch, and user temp.
Clear-RecycleBin: self-explanatory.
cleanmgr /sagerun:1: Disk Cleanup with preconfigured settings.
sysprep.exe /oobe /generalize /shutdown: strip machine identity, stage OOBE, power off.

Note: After sysprep shuts the machine down, do not let it boot back into Windows before capture. If it does, you just spent your sysprep state and get to do it again.

Sysprep on Windows 11: Appx package hell

The worst part of this project was not FOG. It was Sysprep.

If you've fought Windows 11 Sysprep before, you know the error. If you haven't, it looks like this in the Panther logs:

Sysprep was not able to validate your Windows installation.

More specifically:

Package <app> was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.
Failed to remove apps for the current user: 0x80073cf2.

On Windows 11 23H2 and 24H2, the Microsoft Store silently updates Appx packages per-user. That creates a version mismatch between the installed state and the provisioned state. Sysprep sees it, panics, refuses to generalize.

What I tried that did not work:

Remove-AppxPackage -AllUsers
Remove-AppxProvisionedPackage
the mythical SkipAppxValidation registry setting
editing Generalize.xml
renaming AppxSysprep.dll

Some fail outright. Some appear to work, then the packages come back after a reboot. Some just swap one error for a different one.

What actually worked: changing the source image entirely.

I used Chris Titus Tech's WinUtil to build a MicroWin ISO. Instead of installing stock Windows and spending hours ripping Store junk back out, I started from a clean ISO that never had the Appx baggage in the first place.

Prevention over cleanup:

build MicroWin ISO
install on the reference machine
configure drivers and software
disconnect from the network before sysprep if needed
run the cleanup command
sysprep, shut down, capture immediately

That was the difference between fighting Sysprep every time and having it just work.

PXE on newer hardware: `snponly.efi`

One more issue that looked like FOG but wasn't. A newer motherboard would download ipxe.efi, start up, and freeze at:

iPXE initializing devices...

No ok. Just stuck.

iPXE's built-in NIC driver couldn't handle the newer chipset. The fix: switch DHCP option 67 from ipxe.efi to snponly.efi.

The difference is simple. ipxe.efi ships its own NIC drivers. snponly.efi delegates to the UEFI firmware's native SNP driver. On newer boards, the firmware driver works where iPXE's doesn't.

One DHCP change, ipxe.efi to snponly.efi, and the machine booted straight to the FOG menu. It became the default for all our UEFI clients.

72 systems, deployed by room

With images captured and PXE stable, FOG could finally do its job.

Bulk imported the workstation list from CSV:

47 had MAC addresses ready for direct import
25 had no active lease at the time, so they were left to auto-register when first PXE booted

Each host got the right image and room group. Deploying a room was: select the group, schedule a deploy task, PXE boot the room. That's it.

FOG uses Partclone under the hood, so it only transfers used blocks. A 500 GB drive with 30 GB used doesn't push 500 GB over the wire. It pushes roughly 30 GB, compressed. Room-wide imaging is faster than people expect.

After deployment, the FOG client sets the hostname, joins the domain via svc-domainjoin, and drops the computer object in the correct OU. Multicast is also available for imaging an entire room simultaneously.

What I learned

Setting up FOG is not just "install FOG." It's DHCP policy archaeology, AD delegation, Windows image hygiene, boot loader compatibility, and the reality of running services inside Linux containers.

The short list:

DHCP policies override scope options. Check for leftover WDS/SCCM policies before blaming FOG.
A running web UI does not mean FOG is installed. Verify TFTP, services, and NFS.
FOG on Debian Trixie needs manual patches. osid, libcurl4t64, lastlog2.
Kernel NFS in Proxmox LXC is a dead end. Use nfs-ganesha.
Build images on reference machines. VM images don't carry driver quirks correctly.
Debloat before install, not after. MicroWin saves hours of Appx cleanup.
Test Sysprep on something disposable first. Appx breakage on your finished image is a bad time.
snponly.efi for newer hardware. If iPXE hangs at device init, switch boot files.
Never boot a sysprepped machine before capture. Generalize is one-shot.
FOG's hostName is VARCHAR(16). Plan your naming accordingly.

Once the rough edges were filed down, the day-to-day got simple. Pick the room. PXE boot. Image. Domain join. Done. Way less overhead than SCCM ever was.

That's the kind of boring I want from lab infrastructure.

This post is part of a larger infrastructure migration series. For the full Hyper-V to Proxmox migration story, see the project page on solomonneas.dev.

Originally published at solomonneas.dev.

I Built 7 MCP Servers for Security Tools. The Protocol Was the Easy Part.

Solomon Neas — Mon, 23 Mar 2026 20:59:54 +0000

I wanted my AI agent to talk directly to my security stack. Not through copy-pasted log snippets. Not through screenshots of dashboards. Actual tool calls against live data.

So I built seven MCP servers. Wazuh. Suricata. Zeek. TheHive. Cortex. MISP. MITRE ATT&CK. All open source, all on my GitHub. Project page: https://solomonneas.dev/projects/security-mcp-servers.

The protocol layer took a weekend. The context engineering took weeks. That ratio surprised me.

What I Actually Built

API-based servers talk directly to running services. Wazuh MCP hits the manager's REST API on port 55000 for alerts, agent status, vulnerability scans, and file integrity events. TheHive and Cortex connect to their respective APIs for case management and observable analysis. MISP pulls threat intelligence feeds and IOC lookups.

Log-based servers parse files on disk. Zeek MCP reads from a log directory (JSON or TSV format), letting you query connection logs, DNS, HTTP, SSL, and file analysis data. Suricata MCP reads EVE JSON logs for IDS alerts, flow data, and protocol metadata.

Knowledge-base servers work offline. The MITRE ATT&CK server downloads STIX 2.1 bundles and lets you query techniques, tactics, groups, software, and mitigations without hitting any external API.

Each server exposes a focused set of tools. Wazuh has get_alerts, list_agents, get_vulnerabilities, get_fim_events. Zeek has query_connections, search_dns, get_ssl_certs. Suricata has get_alerts, get_flow_stats, search_protocols.

Every tool does one thing with predictable output. Full code and docs at github.com/solomonneas.

Testing Against Live Infrastructure

Every server got tested against real running services on my home infrastructure.

Wazuh MCP was tested against my Wazuh 4.14.1 instance running on Proxmox. I queried live alerts, pulled agent status for my connected machines, ran vulnerability scan results, and verified file integrity monitoring events. The agent reconnection workflow got tested end-to-end: listing disconnected agents, checking last keep-alive, triggering restarts.

Zeek and Suricata servers were tested against actual captured traffic. Real log files through both parsers, connection correlation across source/destination pairs, DNS query lookups, and stress-tested time-window filtering with large log directories. Edge cases like malformed log entries and mixed JSON/TSV formats got handled explicitly.

TheHive and Cortex were tested against their APIs with sample cases and observables. MISP was tested with real IOC lookups. The MITRE ATT&CK server was verified against the full STIX 2.1 enterprise bundle.

The goal was not just "does the tool call succeed." It was "does the model get back data it can actually reason about for a real investigation."

Context Design Is the Real Engineering

Security telemetry is exactly the kind of data language models handle poorly. It's verbose, repetitive, and full of fields that matter sometimes and are noise the rest of the time.

Take Wazuh alerts. A single alert has 40+ fields. Dump all of that into a model and ask it to "analyze the situation." You'll get a vague summary that touches everything and understands nothing.

My first versions returned raw API responses. The model would pick whatever fields were easiest to talk about instead of whatever actually mattered.

So I started designing the context layer. For Wazuh, I filter to severity 8+ by default and return a focused subset: timestamp, rule description, agent name, source IP, and MITRE technique. For Zeek, I pre-aggregate by source/destination pair and surface unusual patterns first. For Suricata, I separate IDS alerts from flow metadata. Detections first, network context second.

Where It Gets Interesting

A Wazuh alert fires for a suspicious process. The model checks Zeek for that host's network activity. Finds outbound connections to an unusual IP. Queries ATT&CK for technique mapping. Checks MISP for threat intel on the destination.

That correlation chain used to take 15 minutes of clicking through interfaces. Now it takes one question.

I'm not replacing analysts. I'm killing the mechanical evidence-gathering that burns time before a human reaches the real decisions.

The Lesson

The protocol is a solved problem. MCP works. The bottleneck is what happens between raw data and the model's context window. Filtering, ordering, scoping, pre-summarizing. That's where analysis quality is determined.

A model with access to every field in every log is worse off than one that sees the right 15 fields in the right order.

Seven servers. All open source. All tested against live infrastructure. Code at github.com/solomonneas. The protocol was a weekend. The context design is ongoing. That's the ratio that matters.

I Migrated Our Entire Infrastructure from Hyper-V to Proxmox. Here's Everything I Learned.

Solomon Neas — Sat, 14 Mar 2026 06:45:04 +0000

Domain controllers, file servers, network monitoring, imaging, WiFi controllers. All of it moved from Microsoft to open source. No downtime. No data loss. Here's the complete playbook.

Why We Left Hyper-V

Broadcom acquired VMware and started charging $350/core/year for VCF licensing. They killed the VMware IT Academy program entirely. The institution moved from vSphere to Hyper-V as a cost-saving measure, but I'd already done a VMware to Proxmox migration on my own infrastructure at that point. That migration opened my eyes to how good Proxmox actually is.

It's more lightweight. The web UI gives you more granular control than Hyper-V Manager ever did. Snapshots, live migration, ZFS, LXC containers, and full KVM virtualization all in one platform. Completely free. No per-socket licensing, no Windows Server dependency, no CALs. One less thing Microsoft gets to hold over your budget.

Hyper-V felt heavy by comparison. Limited Linux VM support, clunky management (RDP into the host just to touch anything), and tight coupling to Windows Server licensing. Once I'd seen what Proxmox could do, going back to Hyper-V felt like a downgrade.

The question was never "should we migrate?" It was "how do we migrate production Active Directory, network monitoring, file servers, and imaging infrastructure without breaking anything?"

The Power of Root on a Proxmox Host

One thing that surprised me coming from Hyper-V: you have full root access to the Proxmox host. It's just Debian under the hood. You can SSH in, run any Linux command, script anything, automate everything. Hyper-V locks you into PowerShell remoting or RDP. Proxmox gives you a real shell on a real Linux system.

Need to resize a disk? One command. Snapshot a VM? One command. Migrate a VM between hosts? One command. Everything in the web UI is also available from the CLI through qm (VM management), pct (container management), pvesm (storage), and pvecm (cluster). You can script your entire infrastructure.

But the real game changer is the Proxmox VE Helper Scripts community project. These are one-liner bash scripts that spin up fully configured LXC containers or VMs for common services. Need a Pi-hole? One command. Docker host? One command. Home Assistant, Nginx Proxy Manager, Plex, Grafana, Wireguard? One command each.

# Example: spin up a Docker LXC in seconds
bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/docker.sh)"

The script handles everything: downloads the template, creates the container, configures networking, installs the service, and starts it. What would take 30 minutes of manual setup takes 60 seconds. I used these for several of our auxiliary services and they just work.

Compare that to Hyper-V where deploying a new service means: create a VM, install Windows or manually download an ISO, walk through the installer, configure networking, install the actual application. The gap in operational speed is enormous.

The Domain Controller Leapfrog

This was the part that scared me most. Domain controllers are the heartbeat of a Windows network. Every authentication, every group policy, every DNS lookup flows through them. Get this wrong and the whole campus goes dark.

The conventional wisdom is clear: never V2V a domain controller. Converting a DC's virtual disk risks USN rollback, which permanently corrupts the AD replication database. There's no recovery path short of rebuilding the entire domain.

Instead, I used what I call the "leapfrog" method. We had two DCs: DC1 and DC2, both on Hyper-V.

Step 1: Transfer all five FSMO roles to DC2. Verify DHCP scopes, DNS zones, and AD replication are healthy. DC2 is now running the show.

Step 2: Delete DC1. Build a fresh Windows Server VM on Proxmox. Promote it to domain controller. AD replication syncs everything from DC2 automatically.

Step 3: Transfer all FSMO roles to the new DC1 on Proxmox. Verify everything.

Step 4: Delete DC2 on Hyper-V. Build fresh on Proxmox. Promote. AD replicates from DC1.

Both domain controllers are now on Proxmox. Zero downtime. Zero data loss. The whole process was honestly easier than I expected because AD replication just works when you let it do its job.

The PowerShell for the FSMO transfer is one command:

Move-ADDirectoryServerOperationMasterRole -Identity "NEW-DC1" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, `
  PDCEmulator, RIDMaster, InfrastructureMaster

Always verify with repadmin /showrepl after each promotion and transfer. If replication shows errors, stop and fix them before proceeding.

Linux VM Migration: The V2V Process

For Linux VMs (LibreNMS, Netdisco, Switchmap), I used direct disk conversion. The process:

Create a "shell" VM in Proxmox. Set the OS type, match the BIOS to the source Hyper-V generation (Gen 1 = SeaBIOS, Gen 2 = OVMF UEFI), but do not create a hard drive. The disk list should be empty.
SCP the VHDX from the Hyper-V host to Proxmox:

scp "C:\Path\To\Disk.vhdx" root@PROXMOX_IP:/var/lib/vz/dump/

Import and attach on the Proxmox side:

qm importdisk 102 /var/lib/vz/dump/Netdisco.vhdx local-lvm

Then in the GUI: Hardware > double-click Unused Disk 0 > add as SCSI. Set boot order to prioritize scsi0.

Post-migration gotchas:

Network interface names change (eth0 becomes ens18). Update your netplan config.
Install qemu-guest-agent so Proxmox can see the VM's IP and gracefully shut it down.
LibreNMS needed a full permissions reset. Run validate.php as the librenms user and follow every instruction it gives you.
Netdisco needed its database host changed to localhost in deployment.yml and a session cookie key added to prevent crashes.

Killing DFS, Simplifying Drive Maps

The old environment used a DFS namespace to abstract file server paths. For a single-server environment, DFS adds complexity that provides no benefit: 30-minute referral TTL, client cache issues, and another layer to troubleshoot when users can't access files.

I ripped it out and replaced it with Group Policy Preferences drive mappings using item-level targeting:

*X:\* mapped for faculty and staff, pointing to the full file server
*Y:\* mapped for students, pointing to the student folders only

Security group membership determines which mapping a user gets. No login scripts, no DFS, no namespace caching. If a user is in the Faculty-Staff group, they get X:\. If they're in the Students group, they get Y:\. Simple.

UniFi Controller: Windows VM to LXC Container

This one was almost comical. The UniFi controller was running on a Windows 11 VM inside Hyper-V. To manage the WiFi, you had to RDP into the Hyper-V host, then log into the Windows VM from there. No SSH. No remote management. Just nested RDP sessions.

The migration:

Export the UniFi backup (.unf file) from the Windows controller
Create an LXC container on Proxmox using the official UniFi template
Upload the .unf backup and restore

All WAP configurations, SSIDs, and client data came over intact. WiFi was back up in minutes. And now it runs in a lightweight container instead of a full Windows 11 VM. The resource savings alone made it worthwhile.

Replacing SCCM with FOG Project

Microsoft SCCM is powerful but absurdly heavy for an educational lab environment. It needs Windows Server, SQL Server, per-device licensing, and significant infrastructure just to image workstations.

FOG Project does everything we actually need: PXE boot imaging, hardware inventory, and centralized workstation management. It runs on Linux, costs nothing, and the web UI is straightforward.

The Golden Image Pipeline

I build golden images as Proxmox VMs (not on physical hardware) so I can snapshot before Sysprep. This is critical because if Sysprep fails, you cannot simply run it again. The only recovery is reverting to a snapshot.

Step 1: Install and debloat. Set up a clean Windows 11 installation on a reference machine. Run Chris Titus Tech's Windows Utility to strip all the bloatware (Candy Crush, Spotify, Xbox, etc.) and disable telemetry. This handles both installed and provisioned packages, which is important because leftover staged Appx packages are the number one cause of silent Sysprep failures.

Step 2: Sysprep and shutdown. Once the machine is configured how you want it, run sysprep.exe /generalize /oobe /shutdown /unattend:C:\Windows\Panther\unattend.xml. The unattend file handles BypassNRO (Windows 11's forced internet requirement) and automates the OOBE setup after deployment. The machine shuts down after Sysprep completes. Do not power it back on.

Step 3: FOG capture. Schedule a capture task in the FOG web UI for that machine, then PXE boot it. FOG captures the sysprepped image as-is, sitting at OOBE. When the image gets deployed to a workstation later, the unattend.xml automates the OOBE setup, the FOG service agent kicks in for background management, and AD auto-join handles domain membership. No manual touch required.

Per-Classroom Deployment

Each classroom has different hardware, so I maintain separate images per room. Every workstation is registered in FOG via CSV import (hostname + MAC address), grouped by classroom. When a room needs reimaging, I select the group, schedule a deploy task, and FOG uses Partclone to push the image. Partclone only writes used blocks, so imaging is fast even on large drives.

The FOG agent runs on every workstation with a dedicated fog-service Active Directory service account. DHCP points PXE boot to the FOG server using snponly.efi for UEFI network boot. A machine needing reimaging just needs to PXE boot and everything happens automatically.

WSUS: Closing the Update Loop

The last piece of the imaging puzzle was patch management. Without centralized updates, every golden image would need constant rebuilding just to stay current. And letting 60+ lab machines pull updates directly from Microsoft on their own schedule is a recipe for bandwidth problems and inconsistent states.

I set up WSUS (Windows Server Update Services) directly on DC1. For an environment this size (four classrooms and a handful of staff machines), a dedicated WSUS server would be overkill. Running it on the domain controller keeps the footprint small and the management simple.

The update pipeline works in two stages:

Test lab first. New updates land in WSUS but aren't auto-approved. I have a WSUS computer group for a small set of test machines. Updates get approved for the test group first. They run for about four to five days. This buffer is intentional: it's enough time for the community to flag zero-day issues, botched patches, or driver conflicts before anything hits production.

Then classrooms. After the test window passes clean, I approve updates for the classroom groups. WSUS pushes them from the local server, so machines pull patches over the LAN instead of each one hammering Microsoft's CDN individually. Faster downloads, less bandwidth, and every machine in a room ends up on the same patch level.

This also means the golden image for FOG doesn't need to be rebuilt every Patch Tuesday. WSUS handles ongoing patching after deployment. The golden image only needs updating when there's a major feature release or a change to the base software stack.

What I'd Do Differently

Document interface names before migration. Every Linux VM had a different post-migration network issue because the interface name changed. A quick ip link show before the migration would have saved debugging time.

Test Sysprep on a throwaway VM first. My first Sysprep attempt failed because of a leftover Xbox app. Always run through the full golden image pipeline once as a dry run before committing to your production image.

The SOC Stack

I also migrated the full security operations stack: Wazuh for endpoint detection and SIEM, Cortex for automated analysis, TheHive for case management, and MISP for threat intelligence sharing. Same V2V process as the other Linux VMs. These were already running on Linux, so it was disk conversion, interface rename, guest agent install, and verify services. Nothing special, but worth mentioning because people forget about their security tooling when planning hypervisor migrations.

The Final Tally

When everything was done, the infrastructure footprint looked like this:

4 standalone Proxmox servers running production workloads: domain controllers, network monitoring (LibreNMS, Netdisco, Switchmap), Samba AD file server, FOG imaging, UniFi controller, and the SOC stack (Wazuh, Cortex, TheHive, MISP)
6-node Proxmox cluster for the NetLab environment, where students run hands-on lab exercises
10 total Proxmox hosts, all on open-source infrastructure

Total hypervisor licensing cost: $0.

The migration took planning and careful execution, but none of it was technically complex. The hardest part was convincing myself that AD replication would actually work as advertised. It did.

Originally published at solomonneas.dev. Find more of my writing on infrastructure, security tooling, and AI agents at solomonneas.dev.

DEV Community: Solomon Neas

Claude Code's Source Leak Was Embarrassing. The Real Story Is What It Revealed

How the leak happened

What the source actually exposed

KAIROS: the unshipped product hiding behind feature flags

Hidden flags are roadmap leaks

Three-layer memory is the kind of design detail competitors pay for

Undercover mode

The anti-distillation controls were real, and not very strong

Native client attestation was the most serious defensive mechanism

The rest was revealing, weird, or both

The DMCA fiasco was both predictable and incompetent

The clones changed the legal stakes immediately

The Axios attack made the same day much worse

What this actually means

Notes

Claude Mythos: What We Actually Know (and What We Don't)

How the Leak Happened

What the Draft Blog Post Actually Says

The Cybersecurity Angle

The Market Reaction

What We Don't Know

The Competitive Context

What This Means for Defenders

Notes

Replacing SCCM with FOG Project

Replacing SCCM with FOG Project

The environment I was replacing

Active Directory prep

The SCCM ghost in DHCP

FOG on Debian Trixie: three bugs in a trenchcoat

Bug 1: wrong osid

Bug 2: libcurl4 renamed on Debian 13

Bug 3: lastlog became lastlog2

NFS inside LXC: the container wall

The golden image pipeline

Sysprep on Windows 11: Appx package hell

PXE on newer hardware: snponly.efi

72 systems, deployed by room

What I learned

That's the kind of boring I want from lab infrastructure.

I Built 7 MCP Servers for Security Tools. The Protocol Was the Easy Part.

What I Actually Built

Testing Against Live Infrastructure

Context Design Is the Real Engineering

Where It Gets Interesting

The Lesson

I Migrated Our Entire Infrastructure from Hyper-V to Proxmox. Here's Everything I Learned.

Why We Left Hyper-V

The Power of Root on a Proxmox Host

The Domain Controller Leapfrog

Linux VM Migration: The V2V Process

Killing DFS, Simplifying Drive Maps

UniFi Controller: Windows VM to LXC Container

Replacing SCCM with FOG Project

The Golden Image Pipeline

Per-Classroom Deployment

WSUS: Closing the Update Loop

What I'd Do Differently

The SOC Stack

The Final Tally

Bug 1: wrong `osid`

Bug 2: `libcurl4` renamed on Debian 13

Bug 3: `lastlog` became `lastlog2`

PXE on newer hardware: `snponly.efi`