Arbiter, Off the Machine It Was Built On
Arbiter now runs its agent sessions natively on Windows, with no Linux layer required. It finds your coding clients where you installed them, starts at sign-in without admin rights, and every build has to behave the same on Windows and Linux before it can ship.
Software that runs well on its author’s machine has passed the easiest test there is. For most of its alpha, Arbiter ran on one kind of setup: a Windows desktop that drove its agent sessions through a Linux layer, kept running at sign-in by scripts written for that one machine. It worked well there. Getting it ready for a first public pre-release meant making it work on yours.
Windows sessions without a Linux layer
On Windows, Arbiter now runs your Claude Code and Codex sessions in consoles it owns, out of sight, with no WSL required. A session lives whether or not a window is showing it. Arbiter can read it, type into it, and show or hide its window on demand, and the session is still there and still known after Arbiter itself restarts. These are the same live, drivable sessions the fleet view is built on, now without a translation layer underneath them.
On Linux, the same sessions run natively. If you already do your work inside WSL on Windows, that path is still supported, and Arbiter picks the right one for the system it is running on unless you tell it otherwise.
It finds your tools where you put them
Arbiter no longer assumes where your coding clients live. It looks for Claude Code and Codex the first time it needs them, and the daemon starts cleanly with neither installed. Install one later and it is found the next time it is called for, with no restart.
It starts with you, without asking for admin
arbiter service install sets Arbiter to start when you sign in. On Windows that is a per-user startup
entry: no administrator rights, no system service, running as you, in your session, with your own
logins. On Linux it writes a systemd user unit and prints the commands that enable it, rather than
running them on your behalf. arbiter service start, stop and status handle the rest.
Every build has to behave the same
Two operating systems and two ways of running, from source and as the shipped program, give four chances to disagree. So every build now runs one scripted session through the command line, the daemon and the MCP server, and the results have to match across Windows and Linux, source and binary. The same run checks that nothing was sent to our servers, that no database was written unencrypted, and that on Linux Arbiter’s home is readable only by you. A build that fails is not eligible for release.
The check earned its place on its first runs: it caught a listing command that tripped on a project folder with a non-Latin name on Windows, and a settings printout that the command which sets them could not read back. Both were fixed before the build left the project.
What it runs on
Windows 10 or 11, or Linux, on 64-bit x86. macOS is not supported yet. Claude Code and Codex are installed separately, as they always were. The goal behind all of this is narrow and practical: the terminal as a layer Arbiter owns should hold on your machine, not only on ours.
Arbiter is a proprietary working alpha in public binary release preparation. Follow the public release channel or RSS feed for updates.
Was this useful?