An operating system written by a fleet of Claude Code sessions.
Since 2026-09-11, Claude Code sessions have written Ferrix: its Rust kernel, its drivers, its compositor, its shell and its tests. A person, the customer, decides what is built, in what order, and what is good enough. The sessions plan the work, write the code, review each other's changes and land them once their tests pass. How the fleet works says who does what.
Linux apps without Linux. Ferrix runs tested, unchanged Linux programs
on its own kernel: Chrome, git, curl, rustc, Valve's Steam client and,
through Proton, a Windows game. Disk, network, graphics, input and power
drivers run as separate processes that Ferrix can restart when they crash.
Ferrix is experimental. Logins, su and the lock screen check passwords,
but it is not ready to be your everyday operating system, and most of its
tests run in QEMU.
See what works · Try it without building · Boot Ferrix · Read the technical guide · Visit the website
Ferrix on an Intel N150 mini PC: Arknights: Endfield from Steam, in a window, through Ferrix's own Intel GPU driver, with ferrofetch and btop beside it.
Commits on main |
3,479 in six weeks (first commit 2026-09-11) |
| Rust in this repository | about 965,000 lines, about 48,000 of them generated tables (components in their own repositories not counted) |
| Architectures | x86-64, AArch64 and ARMv7-A, booted on every landing that changes the image |
| Hardware | an Intel N150 mini PC, a Pixel 7 and an STM32MP157D-DK1 board |
Counted with git rev-list --count main and the lines of every tracked .rs
file at main 628202493.
Arknights: Endfield runs on an Intel N150 mini PC under Ferrix, started from Steam through Proton and drawn by Mesa's Vulkan driver over Ferrix's own Intel GPU driver (docs/INTEL-GPU.md). That driver is not in the kernel: it is an ordinary process, written by following Linux's i915 file by file. On 2026-10-23 the game ran at about 21.5 frames a second standing and 19.7 walking, at 1280x800. It is not smooth yet: one frame in a hundred takes 60 to 95 ms, and finding where those come from is the work under way.
On the same machine the GPU driver was killed with kill -9 while the
system ran. Ferrix started it again, its back end was up in 12 ms, and
Vulkan found the GPU again afterwards
(docs/INTEL-GPU.md §11). Under QEMU the driver can also
run as two processes, a keeper that holds what programs hold and a worker
that drives the GPU, so that a worker can die and be replaced while a
Vulkan program goes on (§12, step 1 of its plan).
- Linux programs, unchanged: Chrome,
rustc,git,curl, Valve'ssteamcmdand Steam client, and other tested binaries, 32-bit x86 programs included. Wine and Proton run Windows programs, among them Endfield's launcher and the game. Claude Code runs a full session on Ferrix's desktop (docs/CLAUDE-CODE.md). Ferrix implements the Linux system calls these programs need, and has its own C library, ferrousli. - A desktop: hyprix, Ferrix's Wayland compositor, reads
hyprland.confand tiles windows. Since this week it also has a floating layout with snapping, an activities overview, title bars it draws itself, a top bar, and screens added and removed while it runs (docs/DESKTOP.md). A fullscreen program's own buffer can go straight to the screen. Each display driver lists the modes its screen can run, on Intel, NVIDIA and virtio GPUs, and the mode can change at run time (docs/DISPLAY.md). GTK 4 and libadwaita programs from Debian 13 run on it (docs/GNOME.md). X11 programs appear as ordinary windows through yserver, an X server written in Rust. - Drivers outside the kernel: disk, network, graphics, input, sound, console and power drivers run as processes. On x86-64 and AArch64 an IOMMU limits what a driver's device can reach. A driver's processes are sealed in a job: none can leave it except by ending, so killing the job ends them all. On the N150, a ring-3 power driver sets the processor's voltage-regulator current limit through typed kernel calls (docs/POWERCTL.md).
- Real hardware: on the N150, Ferrix boots to its desktop with
/on the SATA drive, its own network driver for the Motorcomm YT6801, USB input and the Intel GPU (docs/N150.md). It has also booted on a Pixel 7, on all eight cores, and on an STM32MP157D-DK1 board. NVIDIA's own driver runs as a process on an RTX 3060 passed to a virtual machine. - Users, namespaces and containers: the full desktop runs as the user
ferrix, not root, and passwords are checked byauthd. Ferrix has pid, user, mount, network, UTS, IPC and cgroup namespaces, cgroup v2 limits and seccomp filters;cargo xtask test-containerruns an unprivileged container under a memory limit on all three architectures. - Storage, networking, updates: the root filesystem is btrfs, read and
write. Inside Ferrix,
gitclones a repository andcurlfetches over HTTPS. A disk can carry two system slots, and a new system that does not come up falls back to the good one (docs/AB-BOOT.md). - Developing Ferrix on Ferrix: the toolchain volume carries
cargo,clippy,rust-analyzerand the helix editor, and Ferrix builds its own image (docs/DEV-ON-FERRIX.md). The zinc shell is zsh-compatible, runs oh-my-zsh, and behaves as zsh'sshemulation when it is started assh. - A kernel without the Linux layer, as a build: the build flag
linux_abi=offbuilds a kernel that speaks only Ferrix's own system calls. Its code is 1.4 MB against 7.4 MB with the Linux layer, on x86-64 (docs/LINUX-ABI-SEPARATION.md). It is built, not booted or claimed for anything yet.
The roadmap tracks what is done and what is still being built, and the backlog what is broken.
Ferrix is not one long chat. It is a team of Claude Code sessions with roles, and one person, the customer, above them (AGENTS.md).
- The customer decides scope, priorities and every question of judgement: which game to aim at, how slim the kernel stays, whether a power limit may be raised on real hardware.
- The product owner, a Claude session, turns the customer's requests into tasks, starts agents for them, and lands their work.
- Worker agents each work in a git worktree of their own, build and boot their change in QEMU, and send it to a shared gate pool that runs the tests a change needs.
- A landing lock lets one session at a time move
main, fast-forward only, once its tests passed. - The certification consultant, another Claude session, reviews every change to the kernel's certified core before it lands, and asks for a negative control: the check is broken on purpose and must fail.
- Quality roles watch CI, flaky tests, documentation drift and performance.
The working rules come from mistakes the fleet made, and each says which one. Human contributions are welcome; see CONTRIBUTING.md.
Certification is an aim, not a fact. The project aims at Common Criteria EAL5+, DO-178C DAL C, IEC 62304 Class C and EN 50716 SIL 2 for the kernel's core. Nothing is certified, and no outside assessor is involved: the consultant's review is internal, not independent. Its findings register holds 28 open and 63 closed findings of 91 (docs/certification/).
15 seconds, in real time, of a 70-second recording
that starts at the firmware: rustc compiling and running a program, then Chrome
loading Wikipedia.
 |
 |
 |
The zinc shell, driver processes and a curl request. |
Chrome browsing Wikipedia on Ferrix. | btop showing what's running. |
Captured on x86-64 under KVM. How the screenshots were made.
Ferrix lives in the ferrix-os organization. This
repository holds the kernel, its libraries, the system's programs and the build;
the parts below have repositories of their own, which cargo xtask checks out into
this tree at the commits components.toml names.
Each release carries the x86-64 desktop as one zip. You need QEMU and nothing else: no Rust, no build. On Linux or macOS:
curl -LO https://github.com/ferrix-os/ferrix/releases/latest/download/ferrix-x86_64-desktop.zip
unzip ferrix-x86_64-desktop.zip && sh ferrix-x86_64-desktop/run.shOn Windows, in PowerShell:
Invoke-WebRequest https://github.com/ferrix-os/ferrix/releases/latest/download/ferrix-x86_64-desktop.zip -OutFile ferrix.zip
Expand-Archive ferrix.zip .; powershell -ExecutionPolicy Bypass -File ferrix-x86_64-desktop\run.ps1A QEMU window opens on the desktop with a terminal in it; try btop,
ferrofetch or curl https://example.com. The scripts use KVM, WHPX or
HVF when the machine has one and emulate otherwise, which is slower. The
desktop is the one cargo xtask run-compositor boots, minus what needs a
download of its own: no Chrome, no Steam and no rustc. / lives in
memory, so nothing is kept after QEMU exits. With released QEMU on Windows
the guest gets one processor. The zip's README.txt covers firmware,
options and the rest. The install guide walks through
it with pictures of each step on Windows and Linux, says what to do when
a step fails, and where installing Ferrix on a disk stands.
Install Rust and QEMU, then:
git clone https://github.com/ferrix-os/ferrix.git
cd ferrix
cargo xtask run --arch x86_64That opens a serial console. For the desktop, run cargo xtask run-compositor.
The technical guide covers firmware requirements,
other architectures, Windows, graphics options and the extra downloads needed
for Chrome and the Rust toolchain. Quit QEMU with Ctrl-A, then x.
The boot test starts Ferrix on all three architectures:
cargo xtask test-boot --arch allOther tests compile a program with an unmodified rustc inside Ferrix and boot
an x86-64 image built inside Ferrix. On 2026-10-03 Ferrix also built its own
AArch64 image inside Ferrix on a Pixel 7, in the phone's own virtual machine,
and that image passed the boot test. The guide
has the commands and serial output. These tests demonstrate specific working
paths; they are not a claim that every Linux app works. The N150's figures
above come from runs on that one machine, not from a gate.
Ferrix is MIT licensed. Explore the code and component docs, get the logo and press kit, or open an issue.