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 | ⚠ its own sandbox collides with the engine's confinement and the crash is loud. ⇒ Recommended when you want it safer: run the vendor in one of our container images, so one boundary does the work — Sandboxing |
Qwen Code (qwen-code) | yes — dispatchable and seatable | yes, on Linux and macOS — measured at qwen-code 0.22.2 | ⚠ it nests rather than accepting the engine's confinement, on both platforms, and 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 | ⛔ its own sandbox nested inside ours is a SILENT stop: the run returns success and nothing is written — the finding. implemented; exercise state not established for macOS; therefore operational support is not proven there. ⛔ And on Linux the record carries five runs and no completion — two errored, two were refused, one failed under confinement. ⇒ Treat this backend as built and not yet operationally proven on any platform |
The product's own agent loop (agent-loop) | yes — dispatchable and seatable | yes, on Linux | confinement unmeasured on both platforms |
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 | confinement unmeasured on both platforms |
Deterministic tools (proc) | yes — dispatchable. ⛔ Not seatable, because it holds no vendor credential | yes, heavily, on Linux and macOS | confinement unmeasured on both platforms |
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 connects outward; a remote machine never dials in and holds no credential to it | 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 | yes | ⚠ A container is not the confinement boundary. It bounds the toolchain and the filesystem a session sees and says nothing about the network |
| Host confinement | yes — Landlock or bubblewrap on Linux, Seatbelt on macOS | per backend, and the cells differ — the matrix is the authority | ⚠ four of twelve cells are unmeasured. A blank cell there means nobody looked |
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 — the CLI, the runner-side agent and the console | yes — three 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.