Phase 3, Act III: The Building Is on Fire

I've spent two posts documenting how GitHub went from beloved developer platform to a Phase 3 extraction engine under Microsoft's roof. Phase 3: Profit covered the trust erosion — the data training opt-out nobody told you about, the absorption into CoreAI, the quiet class system between enterprise customers and the individual developers who built the place. Phase 3, Act II covered the billing model flip — usage-based credits landing June 1st, the same week a new data collection policy went live. Same direction, different levers.

I was going to wait before writing Act III. Then May happened.

On May 20th, GitHub confirmed what security researcher Mazin Ahmed had been warning about since December: a threat actor called TeamPCP had breached roughly 3,800 of GitHub's internal repositories. The attack vector was a malicious VS Code extension installed on an employee's device — specifically, a backdoored version of Nx Console, an extension with 2.2 million installs. That extension harvested credentials and used them to access GitHub's internal systems. TeamPCP is now selling the stolen dataset on BreachForums, asking north of $50,000.

Worth noting how GitHub chose to disclose this: five short posts on X. Not their official blog. Not githubstatus.com. Five tweets.

The part that should make you uncomfortable: Ahmed had presented this exact attack surface at Black Hat MEA last December. Not a similar attack. Not an adjacent risk. The specific mechanism — malicious VS Code marketplace extensions used to run supply chain attacks, harvest tokens, compromise developer infrastructure. He laid out the defenses. He shared controls Microsoft could implement to harden the marketplace. He asked the obvious question: what are you going to do about it?

As far as anyone can tell: nothing. No meaningful changes to VS Code marketplace governance between December and May. The controls that existed when the warning was issued were apparently still the controls in place when the breach happened.

Ahmed's post is worth reading in full. One detail is particularly hard to sit with: the day before GitHub disclosed the breach, a completely separate Nx Console backdoor was caught by the community in eleven minutes. Eleven minutes sounds fast — until you realize how many machines auto-update extensions in that window. And then consider that the one that actually hit GitHub's internal systems apparently wasn't caught at all until after the damage was done.

He also notes — and this is important — the same vulnerability class exists in Open VSX, the marketplace that powers Cursor and VSCodium. This isn't a Microsoft-specific problem. It's a software supply chain governance problem that the entire industry is collectively pretending isn't urgent.

The breach didn't land in a vacuum. It's the third major GitHub security event in six weeks.

At the end of April, security researchers at Wiz disclosed CVE-2026-3854 — a critical remote code execution vulnerability where any authenticated user with push access could trigger arbitrary code execution on GitHub.com servers through a crafted git push. GitHub patched it quickly and found no evidence of exploitation before disclosure. Still: a critical RCE in a platform that hosts a significant fraction of the world's production code. That landed. Then the breach landed.

Three major security events in six weeks, while the platform has simultaneously been hemorrhaging reliability.

Between May 2025 and April 2026, IncidentHub tracked 257 separate incidents on GitHub — 48 of them classified as major outages. That's roughly one significant disruption per week for a year straight, with February 2026 alone logging 37 incidents. Enterprise customers pay for 99.9% availability. Three nines isn't aspirational; it's table stakes for business-critical infrastructure. They didn't deliver it. The failure modes are varied and damning: database saturation, Redis cluster failures, security misconfiguration blocking VM metadata, webhook latency spiking 32x, Git operations degrading for eight hours straight. Different root causes, same direction.

The throughline is a drawn-out migration to Microsoft Azure that has throttled GitHub's computing capacity for months. As of March 2026, only 12.5% of GitHub's traffic was running on Azure — with a target of 50% by July. Running a major infrastructure migration alongside an AI-driven traffic explosion is, as GitHub's own CTO put it, an infrastructure team stretched thin. The February 9-10 outage knocked out GitHub Actions, pull requests, notifications, and Copilot features simultaneously. In April, a Merge Queue regression corrupted 2,092 pull requests — changes from previously merged PRs getting reverted, leaving codebases in broken states. GitHub found out from customer support tickets. Not their own monitoring.

GitHub Actions has logged 57 outages between May 2025 and April 2026. If your deployment pipeline runs on Actions — and a significant chunk of the industry's does — that's not a platform you can bet a business on.

The Verge ran a piece this week that opened with an employee quote I keep coming back to: "Basically, there is no GitHub company anymore. It's all Microsoft."

That's more literally true than it might read. When I wrote Phase 3: Profit, Thomas Dohmke was still nominally GitHub's CEO. In August 2025, he stepped down. Microsoft did not name a replacement. GitHub was folded into Microsoft's CoreAI division under Jay Parikh, Executive Vice President, and that was that. No announcement. No transition plan. Just a reorganization that ended GitHub's operational independence and made it a product team inside a larger org. There is no GitHub CEO. There is no GitHub company. There's a product called GitHub that runs on Microsoft's infrastructure and reports to Microsoft's AI division.

Now Julia Liuson — 34 years at Microsoft, oversaw GitHub's revenue and engineering operations — has announced her departure. Current and former employees describe a leadership vacuum and an ongoing talent exodus. The picture that emerges isn't of a company making strategic mistakes. It's of a platform running on institutional momentum while the people who knew how to operate it at scale keep leaving.

The Information also reports that OpenAI — Microsoft's most strategically important partner — is building an internal alternative to GitHub. When the company whose relationship with Microsoft helped fund this entire era of AI development decides it needs its own code host, that's not a footnote.

High-profile defections are already happening in the open source ecosystem. Mitchell Hashimoto — co-founder of HashiCorp — announced his project Ghostty is moving out of GitHub. His reason: it's "no longer a place for serious work." The Zig programming language maintainers moved to Codeberg back in November 2025, citing serious bugs with Actions and problems with GitHub's overall engineering culture. These aren't random protestors. These are people who depend on repository infrastructure to ship software, concluding that GitHub is no longer reliable enough to trust with that dependency.

Here's the uncomfortable part. I know all of this. I've been documenting it for months. My code isn't on GitHub — it lives on Codeberg and my self-hosted Gitea instance. I made that move deliberately. But GitHub keeps showing up anyway, not as a place that holds anything I care about, but as an identity layer that too many tools have decided is the only acceptable way to log in. It's not lock-in through your data. It's lock-in through the login prompt.

I spent part of today actually trying to reduce my Microsoft tooling footprint — specifically switching from VS Code to VSCodium, which is VS Code compiled from the open source code with Microsoft's telemetry and proprietary components stripped out. Same editor, minus the phone-home tax. My AdGuard setup has been fighting Microsoft telemetry on a whack-a-mole basis for a while now; VSCodium just wins that fight outright for the editor specifically.

The reality check came fast, but it wasn't as bad as expected. Most extensions carried over cleanly — and many that aren't on Open VSX will probably work fine anyway if you copy them directly from your existing VS Code install. On Mac that's a straight copy from ~/.vscode/extensions/ to ~/.vscode-oss/extensions/ (you may need to create that folder first — VSCodium lazy-initializes it). On Windows, VS Code extensions live under %USERPROFILE%\.vscode\extensions\ and VSCodium uses %USERPROFILE%\.vscode-oss\extensions\.

The catch with copied extensions is they're frozen at whatever version you grabbed. They won't update through Open VSX because they're not listed there. You could technically fire up VS Code periodically, let it update, and copy things over again — but that's a maintenance tax most people won't pay, and results will vary.

Where it gets genuinely thin is the ecosystem niceties. Quality-of-life extensions from small teams and solo developers mostly aren't on Open VSX — and realistically, why would they be? If you're a one or two person shop you probably haven't even heard of it, and if you have, maintaining a second marketplace listing isn't where your time goes. The big players with dedicated DevRel resources show up. Everyone else doesn't.

I also published my own Capy UI Theme to Open VSX today, which is where it gets genuinely absurd. To log into Open VSX — the supposedly Microsoft-free alternative run by the Eclipse Foundation — you need a GitHub account. Okay, annoying, but fine. Except then you also need a separate Eclipse Foundation account just to sign the publisher agreement. Two accounts for the open source alternative. One wonders why, if the Eclipse Foundation account is mandatory anyway, they didn't just use that for login and leave the GitHub dependency out entirely. No good answer that I could find.

The escape hatch requires the thing you're escaping from, and then asks for a second form of ID on top.

That's the lock-in working — and it operates on at least three distinct layers. There's the identity layer, the login prompt that keeps showing up in tools that should know better. There's the source control and CI layer — Actions pipelines, deployment hooks, integrations that took real time to build and would take real time to rebuild elsewhere. And if you're using Copilot, there's that dependency sitting on top of all of it. Each one alone is manageable. All three together is why people who know exactly what Microsoft is doing still haven't fully left.

It goes deeper than you'd expect too. App Store Connect — Apple's own developer platform — integrates directly with GitHub via Actions. Push to your repo, the workflow triggers, builds your app, and submits to App Store Connect automatically. Apple built their recommended iOS CI/CD pipeline around Microsoft's infrastructure. I spent a couple of hours finding that out the hard way when my Flutter setup confused the hell out of it, but the integration is absolutely there for native Apple developers. Microsoft's fingerprints on the iOS deployment workflow.

And it's worth noting what that integration quietly reveals about Apple. As I've written before, the walled garden is a business model — and Xcode is one of the walls. The fact that Apple can wire App Store Connect into a third-party CI pipeline through GitHub Actions proves they could let developers escape Xcode dependency if they wanted to. They don't want to. Mandatory Xcode, mandatory Mac hardware, mandatory App Store signing — that's not a technical constraint, it's a policy choice that keeps developers tethered. Anyway — we're not talking about Apple today. At some point you stop being surprised and just start taking notes.

Ahmed's question at the end of his post is worth sitting with: "If this attack were replicated inside your organization, would you be able to detect it?"

For most individual developers the threat model is different from GitHub's — you don't have 3,800 internal repositories full of production secrets. But the attack surface is the same. Every VS Code extension you've installed is code running on your machine with access to your filesystem, your environment variables, your credentials, your git config. The VS Code marketplace has been around since 2018 and the governance model is still "publish and hope someone notices if it's malicious."

A few things worth doing regardless of which editor you're running:

Audit your installed extensions. Anything you installed and forgot about, anything that came bundled with something else, anything you can't remember actively choosing — look at it. Check when it was last updated. Look at the publisher. You don't have to be paranoid; you have to be deliberate.

If you're managing a team, an extension allowlist is the right answer. Ahmed mentioned this in December; nobody built the open source tooling to do it easily, but commercial options exist. The fact that it's friction is not an excuse for skipping it.

And if GitHub Actions is load-bearing in your deployment pipeline, this is a good week to think through what a migration looks like. Not because you have to move tomorrow — but because the time to figure out the exit is before the platform fails in a way that costs you something real.

I said in the first Phase 3 post that the Microsoft acquisition playbook is legible if you're willing to look at it straight. Phase 1: adoption. Phase 2: integration. Phase 3: extraction. The billing change is extraction through pricing. The data policy is extraction through terms. The absorption into CoreAI was extraction through org structure.

The reliability crisis and the security breach are something slightly different — they're what happens when Phase 3 is executing while the underlying platform is under-resourced and losing the institutional knowledge needed to keep it running. Extraction requires a functioning platform to extract from. Right now that's not obviously guaranteed.

The developers who are leaving — Ghostty moving off GitHub after 18 years and 52,000 stars, Zig to Codeberg, the unnamed employees The Verge talked to — aren't leaving because they figured out a principle. They're leaving because the platform stopped being reliable enough to justify staying.

That's a different kind of signal than anything I've written about GitHub before.