Runtime
Runtime is where your agents actually do their work · read the code, run the tools, open the pull request. In AgentSDE that happens on a machine you control, reached through AgentSDE Connect. AgentSDE orchestrates the run; the work itself happens on hardware you own.
#Your own machine
Settings → Runtime shows one runtime: Your own machine. Phases run on a device you control, reached through the AgentSDE Connect daemon. Your code, your credentials, and the model calls stay on that machine · AgentSDE orchestrates the run but never holds the working copy.
New workspaces start here, with the no-device rule set to Require my machine · pause work. There is nothing to choose before your first run · pair a device and it is ready.
#What the Connect daemon is
The Connect daemon is a small program you install on your own machine · a laptop, a build box, a server. Once it is signed in to your workspace it behaves like a self-hosted runner: it sits idle waiting for work, and when AgentSDE has a phase to run it hands the phase to the daemon. The daemon clones the repo locally, runs the phase there, and reports logs, artifacts and token usage back.
Because the daemon runs where you put it, everything a phase touches · the checkout, the shell, the toolchain, the network · is your machine’s, not AgentSDE’s. You pair a machine once at /connect; after that it just needs to be online.
#What local-claude means
On your own machine, phases are executed by local-claude · the daemon invokes your Claude on your hardware rather than AgentSDE calling a model for you. It is the same self-hosted-runner idea applied to the model itself: the agent’s reasoning runs under your credentials, on your box, inside your network. Nothing about the run leaves the machine except the results you would see anyway.
#Setting it up
Install and sign in the daemon
On the machine that should do the work, install the AgentSDE Connect daemon (macOS / Linux) and sign it in to your workspace:
It prints an 8-character device code and waits for approval. Settings → Runtime shows the same two commands with your workspace filled in.
Pair it at /connect
Approve that code at /connect. The device then appears on Settings → Runtime. See Devices and API keys for the full pairing flow.
Keep it online
Runs are handed to the device while its daemon is running and online.
#When no device is online
Your own machine can be offline · the daemon isn’t running, the laptop is asleep, or its access has lapsed. The no-device rule is Require my machine · pause work: the run waits for your machine.
A waiting run retries briefly first. If no device comes back, the run shows Needs input and stays there. Once a device is connected, start it again with Restart on the run · see Stop, retry, restart. Restart re-runs the pipeline from the first phase on a fresh branch; Retry only applies to a run that has Failed.
#The device list is read-only
The Runtime page shows the device paired to this workspace · its host, Connect version, and whether it is online, idle, offline or lapsed. That list is read-only here. You cannot add a device on this page · pairing happens at /connect, where you install the daemon, sign it in, and approve the code it prints. See Devices and API keys for the full pairing flow.
What Runtime does let you do with a device is revoke it · signing that machine out immediately. The device’s grant (what it may do on your behalf) is fixed when it was authorized and shown read-only, for the same reason integration scopes are read-only: nothing in that list is a setting you turn up.
A workspace pairs a single device · there is no fleet to manage here. To move work to a different machine, revoke the current one first, then pair the new one at /connect.