The Linux build was broken. We found it before you did.

What was broken

The .deb package always worked. The AppImage — the portable format that needs no installation — did not: on a fresh machine, first-launch runtime provisioning failed with Fatal Python error: init_fs_encoding and ModuleNotFoundError: No module named 'encodings'. Anyone who launched the AppImage before running the .deb first hit this. We caught it during our own pre-release validation, before it shipped to a download page.

Why the AppImage broke Python

Slipstream downloads and manages its own Python interpreter — it doesn't touch whatever Python is already on your system. The AppImage launcher, though, bundles a Python of its own for the app's tooling, and sets PYTHONHOME and PYTHONPATH to point at it. Those two environment variables are inherited by every child process the app spawns — including our managed uv and headroom subprocesses, which then tried to boot using the AppImage's bundled interpreter paths instead of their own. Wrong standard library, wrong encodings module, hard crash.

The .deb install never hit this because it has no AppImage launcher in the process tree — nothing was setting those variables in the first place. Same app, same code, different packaging format, different bug.

The fix

Every managed runtime subprocess — the initial Python provisioning, the headroom --version check, and the proxy process itself — now explicitly clears PYTHONHOME and PYTHONPATH before it spawns, regardless of what the parent process inherited. Slipstream's Python stays Slipstream's Python, whatever launched the app around it.

How we validated it

We don't take "it should work now" on a fix like this. We rebuilt the unsigned .deb and AppImage on Ubuntu 22.04 under emulation, then ran both packages through Ubuntu's real WebKitWebDriver — real GTK/WebKit, Xvfb, D-Bus, the actual Tauri bridge, no mocked commands — on fresh Ubuntu 22.04 and 24.04 containers.

* On 24.04, WebKit's driver itself crashed (a segfault, unrelated to Python) partway through one .deb UI-navigation check, after runtime provisioning had already reported ready — a known flakiness of running WebKitWebDriver under x86_64 emulation on Apple Silicon, not something we're papering over. We reran the AppImage check standalone on 24.04 to isolate it from that driver issue, and it passed end-to-end: fresh provisioning, dashboard, proxy start/stop, and navigation across every screen.

This covers emulated amd64 and AppImage extract-and-run mode. It does not cover a full GNOME/Wayland session, hardware GPUs, native FUSE mounting, or arm64 Linux.

Dependency refresh

The npm and Cargo lockfiles were refreshed within existing dependency ranges — no direct major-version bumps. Our sidecar download scripts also got sturdier: they now verify an installed binary's version and replace it when the pin changes, rather than silently keeping whatever was already there, and a failed download always leaves the previous binary intact.

Codex ChatGPT login fix

Wrapping a Codex CLI installation that authenticates via ChatGPT login (rather than an API key) now correctly sets requires_openai_auth = true in the generated provider config. API-key installs are untouched — they were never forced into the OAuth flow, and still aren't.