After a decade on GitHub, the Zig Software Foundation has packed its bags and moved the Zig programming language’s main repository to Codeberg – a non-profit, open-source code forge. The decision is more than a simple platform switch: it is a protest against what Zig’s leadership sees as GitHub’s declining engineering quality and its growing obsession with AI over reliability.
From GitHub Staple to Codeberg Refugee
For years, Zig – a low-level systems programming language positioning itself as a modern alternative to C – lived entirely on GitHub. That era formally ended when the Zig team announced that the project’s canonical repository was moving to Codeberg, a community-run platform powered by the Forgejo software. The old GitHub repository has been flipped to read-only, a historical mirror rather than an active home for development.
In an unusually blunt migration note, Zig’s founder Andrew Kelley suggested that GitHub has drifted away from engineering excellence, describing a slow decline since the platform’s acquisition by Microsoft and hinting that the project had been living on “borrowed time” before this move.
The Bug That Broke the Trust: safe_sleep.sh
The flashpoint for the break-up was not a vague feeling, but a very concrete – and very nasty – bug in GitHub Actions, the CI system that powers millions of open-source builds.
A script called safe_sleep.sh, introduced to replace standard POSIX sleep, was supposed to pause jobs safely.
Under heavy CI load, it could instead pin a CPU at 100 percent and loop forever.
On Zig’s self-hosted GitHub Actions runners, the bug was catastrophic. Developers reported hung processes that ran for hundreds of hours, silently taking runner machines out of circulation. When this happened, Zig’s CI ground to a halt: even commits to the master branch could sit in limbo, with no guarantee of being checked or merged safely.
To make matters worse, the underlying code change dated back to 2022, and community members had flagged the behaviour repeatedly since then. A fix was merged only in August 2025 – years after the problematic behaviour was introduced – while at least one related issue thread remained open until early December. For a project that relies heavily on continuous integration to validate every change, that lag felt like a serious failure of priorities.
‘Vibe-Scheduling’ and the AI Push
The safe_sleep.sh bug was only part of the complaint.
In public posts, Zig maintainers accused GitHub Actions of “vibe-scheduling” – an unflattering way of saying that CI jobs appeared to run in an unpredictable order, often timing out while others sailed through.
Combined with missing logs, awkward self-hosted runner support and an inability to reliably re-run jobs, the system started to look less like professional tooling and more like a roulette wheel.
Over all of this sits a deeper ideological clash. GitHub’s leadership has been loudly championing an “embrace AI or get left behind” message, with AI coding tools such as Copilot increasingly promoted as central to the platform. Zig, by contrast, has one of the strictest public no-LLM/no-AI policies in open source: contributors are told not to file issues, pull requests or bug comments generated by large language models, and not to ask the community to debug AI-written code.
For Zig’s maintainers, GitHub’s growing AI focus, combined with what they see as neglect of core engineering quality, sent a clear signal: the platform’s priorities no longer line up with the project’s values.
Why Codeberg, and What Changes for Zig Users?
Zig’s new home, Codeberg, is run by a non-profit association based in Europe, and markets itself as a privacy-friendly alternative to corporate forges. Under the hood it runs Forgejo Actions, a CI system that aims to be mostly compatible with GitHub Actions while offering a simpler, more predictable experience.
For everyday Zig users, the short-term changes are simple but important:
- The official Zig repository now lives at codeberg.org/ziglang/zig.
- The GitHub mirror is read-only and kept mainly for discoverability and historic purposes.
- Issues and pull requests will now be handled on Codeberg, under Zig’s stricter no-AI participation rules.
For CI, Zig’s own runners and workflows are being retooled to use Forgejo Actions. The team argues that this setup already feels more reliable and transparent, despite being run by a far smaller organisation than Microsoft.
A Signal to the Rest of Open Source
Zig is not the only project to push back against AI-assisted coding or to worry about the direction of large commercial platforms, but it is one of the first modern programming languages to fully walk away from GitHub’s gravitational pull.
The move underlines several tensions in today’s open-source world:
- Control vs convenience – centralised platforms make collaboration easy, but also concentrate power over infrastructure and policy.
- AI speed vs code quality – some teams embrace AI for productivity; others, like Zig, see it as a source of bugs, legal risk and noise.
- Engineering excellence vs growth priorities – when a platform focuses on AI features and monetisation, core reliability can feel like an afterthought to maintainers depending on it.
Whether other projects follow Zig to Codeberg or similar hosts remains to be seen. But the language’s high-profile exit sends a clear message: developer trust is fragile, and even the biggest platforms can lose it if basic tooling – like CI – stops feeling dependable.
What Developers Can Take Away from the Zig–GitHub Split
If you run your own open-source project, Zig’s move is a reminder to periodically audit your dependencies – not just libraries, but infrastructure: CI systems, hosting platforms, and the policies that govern them.
It may also be a good moment to browse Zig’s own official migration announcement and code of conduct to see how a strict AI stance is written and enforced in practice.
And if you are curious how decisions in one technical domain ripple into others, our feature on Formula 1 strategy and driver futures in Red Bull’s 2026 driver line-up shows how engineering trust, long-term planning and risk all interlock in high-stakes environments – not so different from the trade-offs open-source maintainers face today.
