What has to be installed, and by whom

Studio installs nothing on your machines. Ever. Not a package manager, not a runtime, not a language toolchain. If something it needs is absent, it refuses by name and prints what is missing — it never repairs your host behind your back.

That leaves two separate questions, and they are answered by two different people.

What YOU install: the product's binaries, and nothing else. saphan and its companions (saphan-gateway, saphan-server, saphan-agent …) are self-contained executables. Everything they need to read this configuration, verify signatures, talk to the record and enforce its own confinement travels inside it. There is no pip install, no npm install, no runtime to provision before Studio will start.

What the WORK needs is a property of the work, not of Studio. A fleet that compiles Go needs a Go toolchain on the machine doing the compiling. One that builds an iOS client needs Swift; one that builds Android needs the Android SDK. Studio does not supply these and does not want to: they belong to your build estate, they are versioned on your terms, and an engine that silently installed them would be changing your hosts without asking.

How Studio behaves when a toolchain is missing: it refuses at the door, names the binary it could not find, and stops. It does not fall back to a different tool, does not partially proceed, and does not report success on a reduced measurement. A run whose toolchain is absent is a refusal you can read, not a green result you have to distrust.

Why this is worth a section of its own. The failure this prevents is the one where an automated system quietly provisions something on a production host, and nobody can later say when the machine changed or who changed it. Studio's answer is to make the absence visible and the decision yours. If you want a toolchain present, you put it there deliberately — and the audit trail of that act belongs to your estate, where it can be reviewed, not to a log line inside somebody else's daemon.

Where each host's permitted commands are declared: workspace.worktree_grant_class (see Keys) names the permission class a spawned agent runs under. The grant is a file you own and version, not a setting Studio computes.

⚠ Only claude-code is given the grant. On claude-code the grant is written to the agent's .claude/settings.json, lists the executables the agent may invoke, and anything outside it is refused by name at the moment of the call. On every other backend — codex, qwen-code, droid, cursor, openai-compat, agent-loop and proc — the grant is not provisioned: it names nothing, nothing is refused by name, and the dispatch says that the declared grant was not provisioned for that backend.

What bounds those runs instead is the confinement in Sandboxing: which agent is confined, where, per backend and platform. Read Agent grants before assuming a declared class covers a leg.