Nothing on Your Machine Can Stand In for Your Second Factor
The coding agents Arbiter supervises run as you, on your machine. So once your authenticator is enrolled, nothing they can read or write counts as your second factor: not a file, not a setting, not a shortcut. Here is what that rules out.
Two-factor approval is the line between reading your fleet from your phone and acting on it. The last pass on the remote path made that line strict by default. This one asks a harder question about the same line: who else on your machine could reach it?
The honest answer is uncomfortable. The coding agents Arbiter launches run as you, under your user account, with your files. That is what makes them useful. It also means anything your own account can read, they can read. A second factor that a process running as you could recover, mint or skip is not a second factor. It is a first factor with extra steps.
So the rule is now explicit: once an authenticator is enrolled, nothing on the machine stands in for a current code from it.
Resetting the factor needs the factor
Re-enrolling or resetting an authenticator needs its current code or one of its recovery codes. Adding another authenticator while one exists needs a code from an enrolled one. There is no local shortcut that a process on the machine can use instead: earlier alpha builds had one, and it is gone. Registering a new MCP server, which decides what code Arbiter will start, needs a code too.
That closes the obvious attack from inside: a supervised agent cannot quietly replace your authenticator with one it controls, and then pass every check that follows.
Guarded settings come from one guarded place
Some settings decide who may drive the machine, what it runs, and where its secrets go. In the shipped program those settings come only from Arbiter’s protected settings store, where changing them needs a code. A line in a settings file or in the engine’s environment cannot set them, and the engine refuses to start while its environment tries to. A process that can write a file as you still cannot hand itself remote control.
The guess limit cannot be switched off
A six-digit code is only as strong as the number of guesses it allows. The lockout that limits wrong codes can be tuned, between one and ten attempts and over a window of at least five minutes, but it can no longer be configured off. Nobody, including a process editing your configuration, can turn a six-digit code into an unlimited one.
Keys never land in your shell history
Arbiter asks for a key at a hidden prompt and never takes it from a command-line argument, so it does not end up in your shell history for anything else running as you to find.
Your agents ask before they act
When Arbiter connects to Claude Code as an MCP server, setup pre-approves only its read-only tools, such as status. The tools that start work, approve it or stop it are not pre-approved, so Claude Code asks you before it calls one. An agent can see what Arbiter sees; it cannot drive Arbiter without you saying yes.
Still your fleet, under your own logins
None of this changes what remote control is for: you, driving your own sessions on your own machine, under your own accounts, from your phone, as laid out in Take the wheel of your own agent sessions. What changed is that the agents doing the work are no longer anywhere near the gate that approves it.
Arbiter is a proprietary working alpha in public binary release preparation. Follow the public release channel or RSS feed for updates.
Was this useful?