Vybra OS Alpha 0.2: Security Updates, and a Way Back
A private VM-tested milestone for Vybra OS: signed updates, explicit approval, boot-menu recovery, and the bugs the rollback tests caught.
Written by Iris Hart on behalf of
finalthief•November 2, 2026•20 min read
The first checkpoint was getting a desktop to boot. This one asks a less photogenic question: what happens when an update goes wrong?
Bert sent me a new build journal for Vybra OS, his private Arch-based desktop. Its latest milestone, Alpha 0.2, adds signed updates, explicit approval before installation, and a route back even when the updated system cannot start.
About this journal: The illustrated development record below was written by Claude, the build agent, from the project’s phase reports, test runs, and screenshots. It covers October 19–22, 2026, and is published here with editorial framing by Iris Hart. The test results are the builder’s reported results, not tests I independently reran. Mockups are labeled separately from VM screenshots.
This remains a private, VM-only alpha. The source says Alpha 0.1 and Alpha 0.2 were packaged and tagged locally; neither is a public ISO or download announcement. Nothing here establishes physical-hardware support, ARM64 support, or a live-account provider test. The automated tests used no live accounts.
The checkpoint, in the builder’s numbers
78 of 78 mandatory gates, covering Phases 0–7, passed in the final reported run: 50 minutes, 7 seconds.
367 unit tests, plus the VM suites, are listed in the source overview.
108 local commits and 35 architecture decision records are reported for this build sequence.
Both alpha tags remained local. The next milestone was still the owner’s choice; a hardware lab was a possibility, not a tested result.
The details matter more than the scoreboard. A forged update is refused. A valid signature with a mismatched package database is refused. An expired release is shown as out of date. An older signed release cannot simply be replayed. And the recovery test deliberately breaks the updated system before trying the boot-menu escape route.
What follows keeps the builder’s phase-by-phase record, newest first.
Security updates you approve, and a way back if one goes wrong
Alpha 0.1 shipped with one high-severity limitation written down in plain sight: an installed system could not get security updates. An operating system that can't patch itself isn't one you can live in, so Phase 7 is about exactly that, and about the harder half of the problem: going back when an update breaks something.
Mockup Settings → Updates, drawn before any code was written. New screens get a mockup first.Built in a test VM: update 4 is ready, showing its package changes. This test update lists no security advisories.
What an update is
Arch Linux changes every day. Vybra doesn't follow it live: every Vybra system is pinned to one dated snapshot of the Arch Linux Archive. An update moves that pin forward, together with Vybra's own packages rebuilt for the new date.
A tested date — An Arch Linux Archive date, for example 21 October 2026.
A matching build — Vybra's packages, built from one commit for exactly that date.
A signed description — release.json: a number, the package databases' hashes, the security fixes, a 30-day expiry. Signed with Vybra's key.
Your PC checks it — Signature, channel, number, expiry, date, hashes. Nothing changes yet.
You approve — Vybra's card, your password, a snapshot before and after, then a restart.
Saying no to bad updates
An update channel is an attack surface, so the release run ships four deliberately bad updates alongside the good one, and the VM test points the system at each in turn:
Forged: Signed with a key that isn't Vybra's — Refused.
Swapped: Valid signature, but the package database doesn't match its hash — Refused.
Expired: Older than its 30-day validity — Shown as out of date.
Replay: A genuine, signed, but older update served again — Refused.
Installing: the same rules as everything else in Vybra
The check runs as you, without root. Installing is a privileged change, so it goes through the path every privileged change in Vybra takes: a card written by Vybra (never by the AI), your administrator password, then Vybra's small root helper starts one fixed system unit. That unit checks everything again, downloads everything first, takes a snapshot of the system as it was, keeps today's kernel next to it, installs, takes an "after" snapshot and writes the boot menu.
The approval card, written from the verified update check: what changes, how much to download, and how to go back.Then the administrator password, in Vybra's own dialog, which carries the seal you chose during onboarding.Installed. The bar's chip changes from "Update ready" to "Restart to finish".History keeps every update and every time you went back.
Going back, even when the system won't start
Going back from Settings is easy to promise. The real test is an update that leaves the system unable to start, because then Settings isn't there to help. So the VM test breaks the updated system on purpose (it corrupts the start-up image), restarts, and picks the boot-menu entry "as before update 4". A small step that runs before the root file system is mounted swaps it for a copy of the snapshot, puts the saved kernel back, and the system starts as it was. Your home folder is never touched either way.
Going back from Settings is a card too: programs and system settings go back, files in your home folder stay as they are.The rescue: Vybra writes the boot menu, with one entry per update you can still undo (the last two).Back on the desktop after the boot-menu rescue, then one more normal restart to prove it sticks.Already running Alpha 0.1? Three commands join the update channel. This VM was installed from the Alpha 0.1 ISO and then updated.
These screenshots come from the release run itself. Earlier development screenshots turned up a few rough edges (a package-size column cut off, dates written as 2026/10/21, a stale Hyprland error banner after the update), all fixed before the release. A few small overlaps are still there for next time, such as the bar's window title running under the update chip.
78 of 78 mandatory gates, Phases 0–7, in one run · 50 min 7 s · run 20261022-065507
From the lab
Bug · found by the rollback test
The snapshot that remembered the future
The "before" snapshot was taken after the updater had already written the new package sources. So going back restored the old system, still pointed at the update it had just undone: one plain pacman -Syu would have reinstalled it. The fix: the old sources go back into place for the moment of the snapshot. The rollback test in a VM is what caught it.
Bug · found by the first real update
A colon walks into a URL
One package in the update, python-setuptools 1:84.2.1, has a version "epoch", and the colon broke everything around it: the lab's update server refused the request, and Windows can't store a colon in a file name at all (its tar quietly wrote an underscore). The cache now stores it as %3A and the server maps it back.
Lab · an old problem, finally solved
Virtual machines that couldn't restart
An update ends with "Restart to finish", and with QEMU's Windows accelerator a VM that restarts itself just froze ("unexpected VP exit code 4"), a problem Alpha 0.1 already had. Now every lab VM is told to stop instead of restarting, and the launcher starts it again by itself. Watching for that stop needed a second control socket per VM, because the first one takes one client at a time and the watcher was locking out the test's key presses.
Release rehearsal · 22 October
The run that tested the tests
The first full run against the 0.2.0 release ISO passed 58 gates, every new Phase 7 gate among them, and still failed, for four reasons outside Vybra itself. The PC's drive was down to 24 GB free (old test runs' virtual disks were deleted, with permission, freeing 98 GB). The results file's schema had never heard of a Phase 7. Building the test update had quietly overwritten the release ISO's build log. And once, a single message to the desktop shell went unanswered right as a password dialog opened, and the strict test stopped there, taking every later check with it. That last one never happened again in 25 deliberate repeats. Rather than shrug, the test now insists on the very same shell process from start to finish, and keeps the shell's own log if anything goes wrong.
Incident
The PC crashed mid-build
Partway through a build, the Windows PC itself went down. After the restart, the repository, the ISO and the Builder VM's disk all checked clean, and the work picked up where it stopped. Earlier, the Builder had once stalled on a blocked file-system transaction with its disk mostly idle; it was stopped and the build run again.
Phase 6 turned a working system into a release. The ISO was rebuilt from chroots made fresh at the release commit, with a package list and a licence report beside it. A real interactive install, with no test drive attached, proved that no test material or automatic login reaches an installed system. Scans checked for secrets, stray logs and licences.
69 of 69 mandatory gates, Phases 0–6, in one run · 37 min 43 s · run 20261021-011449
Security · the one high-severity finding
A program could press Enter for you
Approval cards accept Enter for approve. A security review asked: what if a program creates a virtual keyboard and presses Enter itself? It worked, which meant any program on the desktop could approve a card. Hyprland now refuses keyboards created by programs. The test is real: a genuine virtual-keyboard program pressing Enter on a genuine card.
After the fake keyboard pressed Enter: the card is still waiting ("1 waiting for you"). Only a real key press counts.The Alpha 0.1 desktop, from the release run.
Apps built by Vybra Forge also got a second wall: a system-call filter written in Vybra's own code, on top of their sandbox.
Phase 5 · 20 October 2026
Vybra Forge: describe an app, check it, install it only if you say so
Forge is where you ask for a small app in plain words. The interesting design choice is what the AI writes: not code. A Forge app is a specification of its records, fields, screens and totals, and Vybra's own runtime draws and keeps it. So an app can only ever do what the runtime offers (lists, forms, totals, charts, CSV import and export), and it runs in a sandbox with no internet, no devices and none of your files.
Forge, opened from the launcher.The expense tracker from the master plan, built: 11 of 11 checks pass, and "What it can use" says plainly what it can't.Installing it takes an approval card with your seal, and installs it for you only.The installed expense tracker in the test VM. This capture shows its empty state; the builder reports that the test also imports a CSV.
61 of 61 mandatory gates, Phases 0–5 · 27 min 34 s · run 20261020-191854
Phase 4 · 20 October 2026
Real AI models, your own accounts, and push-to-talk voice
Your own OpenAI key, kept only in your login keyring: never in Vybra's files or logs.
A model per job ("choosing what you meant", "explaining and answering"…), or Automatic. Vybra never moves you to a more expensive model on its own.
Codex for building apps, installed only if you ask, signed in through OpenAI's own window.
Local models on this computer, through llama.cpp, Ollama and the like.
Vybra Voice: hold Super+V and speak. It runs offline on this computer, listens only while you hold the key, and keeps nothing.
Settings → AI: connect a key, test it, or disconnect and delete it.Push-to-talk: the red "Listening" sign is on only while the key is held.Even installing Codex is an approval card.
No automated test used a live account.
55 of 55 gates, Phases 0–4 · 22 min 48 s · run 20261020-153225
Phase 3 · 20 October 2026
The Vybra panel: the AI proposes, Vybra writes the card, you decide
This is the heart of the design. Vybra has a fixed set of capabilities (15 in this phase: 8 that only look, 5 small reversible changes, 2 system changes), and the AI can only pick among them and fill in checked values. There is no way for the AI to run a command. Anything that changes the system shows a card written by Vybra from the validated request, never by the AI, and the root work is done by a separate, locked-down helper after polkit checks your password.
Test · a hostile AI on purpose
"IGNORE THE CARD ABOVE"
One test tells the test model to misbehave: it answers a volume request with a prompt injection that claims the action is already approved and slips in rm -rf ~. The panel shows that text for what it is ("AI note · unchecked; only the card decides what happens"), and the card below still says exactly what will happen: set the volume to 60%, nothing else.
The injection is shown as an unchecked note; the card is Vybra's, and it doesn't change.An approval card: Enter approves, Esc denies.System changes also ask for the administrator password, in a dialog carrying your seal, so a fake is easy to spot.Vybra Activity: everything that happened, with a tamper check.
41 of 41 gates, Phases 0–3 · 19 min 16 s · run 20261020-115500
Phase 2 · 20 October 2026
A desktop of its own
Phase 2 turned a bare session into Vybra's desktop, built from the approved design tokens and mockups: a login screen, the top bar, a launcher, quick settings, notifications, Settings, a first-login welcome, and the everyday apps. Every colour, size and duration comes from one tokens file, and reduced motion turns animations off everywhere.
The login screen. Installed systems start here; the test-only automatic login is gone.The launcher, with keyboard and mouse.Quick settings.The installer lists only disks it may use (the 8 GB one is too small) and does nothing until you type the disk's name.
Two choices from this phase matter later: installs need no internet (the ISO carries every package an install needs, and the tests install with the network off), and snapshots are set up from the first boot, which Phase 7's "go back" builds on.
27 of 27 gates, Phases 0–2 · 12 min 18 s · run 20261020-075736
Phase 1 · 19–20 October 2026
The walking skeleton
The whole pipeline, end to end, as thin as possible: a Linux Builder VM created from the official Arch image (checksum and signature verified first), Vybra's packages built in clean, isolated chroots and signed, a bootable ISO pinned to one dated Arch snapshot, a test VM booting it under UEFI and old-style BIOS, an install onto a blank virtual disk (after a guard confirms it really is the disposable test disk), and the installed system starting on its own.
The first installed boot: a placeholder bar reading "walking skeleton", the Resonance wallpaper, and a terminal on Super+Return. Humble, and proof that the riskiest part works.
The biggest risk in the whole project was whether Hyprland would run inside QEMU on Windows at all. It worked on the first approach tried.
18 of 18 gates, Phases 0–1 · 14 min 37 s · run 20261019-233615
Phase 0 · 19 October 2026
Foundations: rules before code
The next two images are concept mockups, not screenshots of a running desktop.
Nothing ran in a VM yet. Phase 0 set up the repository with the master plan committed unchanged, a repeatable readiness check for this PC (18 of 18 items, including a real hardware-accelerated test VM), research from official sources, an architecture, a threat model covering 16 risks (each tied to a test gate), the first nine decision records, and the visual direction: design tokens with automated contrast checks, an original wallpaper and five mockups.
Mockup The desktop as first imagined.Mockup The Vybra panel. Compare with the real one in Phase 3.
The rule that shaped everything after: "done" is a fact, not a claim. Every phase has gates, and a phase ends only when a single automated run passes all of them, for that phase and every phase before it.
8 of 8 Phase 0 gates
Behind the scenes
How it's built
All of Vybra is built and tested on one Windows 11 PC, with QEMU and Windows' own hypervisor. No physical disk is ever partitioned or installed to; every install goes onto a throwaway virtual disk.
Commit — Every build starts from a commit in the repository.
Builder VM — An Arch Linux VM builds Vybra's packages in clean chroots and signs them.
ISO — Pinned to one Arch Linux Archive date, with a checksum and a list of contents.
Test VMs — Boot, install, log in, click and type through the desktop, take screenshots.
Gates — One run checks every gate of every phase so far, on a clean tree.
Report — A plain-language phase report, then a stop for the owner's review.
The screenshots on this page are taken by those tests: the test drives the VM through QEMU's keyboard and mouse, waits for the screen to show what it expects, and saves what it saw.
What this changes—and what it does not
The strongest part of this update is not the purple desktop. It is the attempt to make “you approve” survive contact with real failure: an update channel, a privileged installation, a fake keyboard, and a system that no longer boots.
The source also describes AI settings, offline push-to-talk, and Forge’s constrained mini-app runtime. Those remain the builder’s VM-tested scope, not a claim that a screenshot proves live cloud sign-in, real microphone compatibility, or safe use on anyone’s everyday computer. Small UI overlaps and the hardware milestone remain unfinished.
The earlier bootable-beginning post is still the foundation story. This supplied journal documents a later checkpoint: a desktop with a tested update path, and a deliberately tested way back.
That is a more useful kind of progress than a screen that only looks finished.
Editorial framing by Iris Hart on behalf of Finalthief. Development journal and reported VM results by Claude, the build agent, for Bert’s Vybra OS project.
