Supported agents, runtimes and integrations
Every agent backend, execution shape, notification sink, datastore and surface — each at the state the release actually proves, with what is therefore not proven.
This is the canonical support page. Everything Saphan Studio can drive or connect to is listed here once, and every row carries three separate facts rather than one word.
| the column | what it means |
|---|---|
| In the release | the mechanism is in the accepted release tree and reachable from the product's own surface |
| Exercised | somebody ran it, on a named platform, and kept the output |
| Therefore not proven | what the two columns above do not let you conclude |
⛔ There is no single "supported" column, and that is deliberate. A mechanism can be complete, reachable and never once run on the platform you are about to run it on. Collapsing those into one word is the most expensive sentence this page could carry, so it does not carry it.
⚠ An empty exercise cell means nobody looked. It does not mean "no".
Agent backends
The backend vocabulary is a closed dictionary the product reads from one place; this table is a projection of it rather than a second list.
| Backend | In the release | Exercised | Therefore not proven |
|---|---|---|---|
Claude Code (claude-code) | yes — dispatchable and seatable | yes, on Linux and macOS, confined on both — measured at claude-code 2.1.234–2.1.251 | ⚠ a newer CLI may behave differently; vendors change their sandboxes |
Codex (codex) | yes — dispatchable and seatable | yes, on Linux and macOS — measured at codex-cli 0.149.1 | ⚠ on Linux the engine confines it and switches codex's own sandbox off; on macOS the engine does not confine it — it runs under its own sandbox and the run record says the engine makes no claim — Sandboxing |
Qwen Code (qwen-code) | yes — dispatchable and seatable | yes, on Linux and macOS — measured at qwen-code 0.22.2 | ⚠ confined by the engine on Linux; on macOS its sandbox collides with the engine's, so the engine does not confine it and the run record says so. It needs a writable profile home or it dies before doing any work |
Factory Droid (droid) | yes — dispatchable and seatable | Linux only, by hand, at droid 0.213.0 | confined by the engine on Linux; not confined by the engine on macOS, and the run record says so — Sandboxing. ⚠ Not exercised on macOS, and no completed run on Linux ⇒ treat this backend as built and not yet operationally proven on any platform |
Cursor (cursor) | ⛔ named, not built. The backend is in the vocabulary, but its adapter is not built, so a dispatch to it is refused | not applicable | — |
The product's own agent loop (agent-loop) | yes — dispatchable and seatable | yes, on Linux | it applies its own confinement rather than the engine's host sandbox; ⚠ not exercised on macOS |
Local and OpenAI-compatible models (openai-compat) | yes — dispatchable and seatable; any endpoint speaking the OpenAI chat dialect, configured as a named lane | yes, on Linux | the model call is made by the engine itself, in process, so there is no agent process to confine; ⚠ not exercised on macOS |
Deterministic tools (proc) | yes — dispatchable. ⛔ Not seatable, because it holds no vendor credential | yes, heavily, on Linux and macOS | it runs executables you name; the engine's host sandbox is not applied to it |
A lane carries an address and a name, never a secret. A local-model lane is one section of configuration: the endpoint URL and the name of the credential variable (Configuration).
Mixing is normal. A frontier model on one seat, a second account of the same tool on the next slot, a local model on a box in the corner — concurrently, each in its own seat, each accounted per run.
Routing is a decision, not a habit. Every class of work states its tier, and the standing principle is that work goes to the cheapest actor that delivers the same quality — checked by the same tests and the same gates regardless of who did the work. The economics are Cost management.
Execution
| Shape | In the release | Exercised | Therefore not proven |
|---|---|---|---|
| On the control plane's own machine | yes | yes, on Linux and macOS | — |
| On an admitted machine over SSH | yes — the control plane always opens the SSH connection; a runner does not dial it or poll it (Machines) | yes, on Linux and macOS | — |
| Inside a container image (OCI; Docker or Podman) | yes — per-language runner images, pinned by digest rather than by tag, each carrying its own declared class. Selected with run.confinement = container; local machine only, refused for a remote run | yes | ⚠ A container is not egress control. What a run may connect to is decided by egress control. On a macOS host codex, qwen-code and droid get no container |
| Host confinement | yes — Landlock or bubblewrap on Linux, Seatbelt on macOS | per backend, and the cells differ — the matrix is the authority | ⚠ a backend the engine does not confine on a platform is never described as confined; its run record says no engine boundary was claimed |
The images that ship: dev-go · dev-node · dev-ts · dev-python · dev-java ·
dev-android · probe, the last for measuring a host rather than working on it.
Git forges
⚠ This row is being re-measured and is deliberately not stated here today. What the product can read from a forge, what it cannot do to one, and which parts do not exist is on Pull requests and forge integrations, which is the page to read until this table carries it.
Notifications
A notice is a message out. Nothing comes back through it, and no message posted into your chat workspace can change anything in the fleet.
| Destination | In the release | Exercised | Therefore not proven |
|---|---|---|---|
| Slack — a channel | yes | yes | — |
| Slack — a direct message | yes | yes | — |
| Anything else | ⛔ no. Slack is the only sink in the release | not applicable | ⛔ Microsoft Teams is not built. It appears nowhere in the product's own code, and this page will not list it until it does |
One machine does the sending, and which one is a key you set (Notifications).
Data and deployment
| Component | In the release | Exercised | Therefore not proven |
|---|---|---|---|
| The built-in single-file record store | yes — needs nothing from you | yes | — |
| PostgreSQL, on infrastructure you run | yes | yes | — |
| CouchDB, for law and evidence | yes | yes | ⚠ the databases are created by hand — the one step left to you |
The machine payload — saphan (the CLI), saphan-agent (the runner-side agent), saphan-gateway (the client API) and saphan-server (the daemon that serves the console) | yes — four binaries, carried by every delivery route | yes, on Linux and macOS | — |
| deb / rpm package | yes — built | yes, deb on linux-amd64 | ⚠ no channel serves either file today, and neither is installed on arm64 Linux or on an rpm-family host — Air-gapped installation |
| macOS self-extracting installer | yes — built | ⚠ not installed from a served copy | ⚠ no channel serves it, and it is not signed or notarized |
The authorization server (saphan-oauth) | ⛔ carried by no release artifact | not applicable | Central servers states this rather than describing an install path that does not exist |
Human and machine surfaces
| Surface | In the release | Exercised | Therefore not proven |
|---|---|---|---|
| The command-line interface | yes | yes, daily | — |
| The web console | yes | yes | ⚠ several screens are drawn and not yet fed from the record — which is which |
The client API and gateway (/v1, /metrics) | yes — a separate process, part of the machine payload | yes | — |
| The read-only MCP projection | yes — reads only; no mutating tool exists, not even as a stub | yes | MCP server |
| The VS Code extension | yes — a read-only fleet view | yes | it runs the CLI; it opens no port |
| Mobile signalling | ⛔ not built. No such mechanism is in the product | not applicable | — |
What this page will not do
⛔ It does not list work in progress. A design document, an order, a backlog item or an unmerged branch is not a capability, and none of them appears above. If a mechanism is being designed, this page stays silent until it is in the release.
⛔ It does not compare vendors. Which backend suits which class of work is your decision; what this page owes you is the state of each one, not a ranking.
⚠ The confinement figures are one reading on one date. They say the behaviour was observed on that platform at that version — not that the vendor guarantees it at the next release. The matrix carries the dates and the method.