Runtimes & bridge

The Runtimes page (/space/runtimes) documents where your agents actually execute: the local/mobile bridge daemon for on-device work, paired devices, cloud sandboxes on Cloudflare Workers, and the upcoming Docker/SSH runtimes.

New to the AI side? Read AI concepts from scratch first — agents need tools to act, and this page is about where and how those tools run safely.

The concepts behind runtimes

Agents act through tools, and tools need somewhere to execute. This page splits that into two risks the platform has to solve:

• Where can the agent act? The bridge runs actions on your machine (files, shell, processes, network) or your phone (notifications, SMS, contacts); cloud sandboxes run code in an isolated Workers isolate at the edge; Docker/SSH runtimes will target containers and remote boxes. Each is a different execution surface.
• How do we keep that safe? An autonomous model calling desktop.shell.execute is genuinely dangerous, so every capability is explicitly scoped and consent-gated (consent_prompt/consent_response), audited in device_action_log, and guarded by a destructive-command filter. The connection is outbound-only WebSocket, so even the daemon itself never accepts inbound traffic.

The bridge is also where the local-first promise physically lives: sync.chat.push mirrors your history into the device’s SQLite, so the data exists on your hardware, not only in a cloud index.

The bridge daemon (local environment connector)

The SynthHires Bridge is an ultra-lightweight desktop/mobile daemon that lets agents execute tasks and commands on your own machine — without uploading your files to the cloud and without opening ports in your router.

• Platforms: Windows (exe), macOS, Linux (CI-built binaries via /api/downloads/desktop), Android APK (CI) and iOS (CI simulator build; signed distribution pending).
• Connection model: 100% outbound-only WebSocket to the platform (no inbound ports), TLS 1.3.
• Security: destructive-command guard filters, consent-gated actions, audit log.
• Status polling: the page polls the daemon’s own HTTP status endpoint (http://127.0.0.1:7333/status) — the authoritative source for paired, WebSocket connected, RTT and version — and falls back to /api/devices when the daemon isn’t reachable from the browser (e.g. mobile or production).
• Status states: checking → waiting for pairing → reconnecting → connected (with RTT) → offline / needs login.

The wire protocol

The web side of the protocol lives in src/lib/agent/bridge-protocol.ts (version 1), mirrored serde-camelCase on the Rust daemon. Frames are JSON messages over WebSocket:

Frame	Purpose
hello / hello_ack	Handshake with protocol version + capabilities
heartbeat / heartbeat_ack	Liveness with RTT measurement
scope_update	Capability scope changes (grant/revoke)
resume	Reconnect with session resume
action_request / action_cancel	Request or cancel a device action
consent_prompt / consent_response	Human-in-the-loop consent dialog
action_result / action_stream	Action completion (or streaming output)
revoke	Device/scope revocation
error	Protocol errors with close codes

Capabilities

The protocol exposes scoped capabilities (BRIDGE_CAPABILITIES), each requiring explicit consent:

• Desktop: desktop.shell.execute, desktop.fs.read / write / delete / verify / list / watch, desktop.process.list / kill, desktop.network.fetch.
• Sync: sync.chat.push (mirror conversations to the device’s SQLite).
• Mobile: mobile.notifications.read / dismiss, mobile.sms.read / send, mobile.contacts.read, mobile.location.read, mobile.automation.perform, mobile.clipboard.read / write.

Pairing

Pairing happens through /space/connections (Devices tab) or the runtimes page: download the bridge, run it, and use “Pair new” with a pairing code (pairing_codes table). Paired devices appear in DeviceList, with online/offline state, RTT and an audit log of consented actions (device_action_log).

Paired devices

DeviceList shows every paired device with connection status and lets you revoke access at any time. Device records live in devices + device_tokens; revoking kills the token and closes the WebSocket.

Cloud sandboxes (Workers)

The Sandboxes tab manages isolated Cloudflare Workers environments for agent code execution:

• Each sandbox gets its own V8 isolate with configurable memory, timeout and region.
• Stateless per-isolate model: no fs, no Node-only APIs — code runs at the edge close to your data.
• Sandboxes are the default remote execution target when no local bridge is paired.

The context window idea shows up here too: agent code runs in a resource-capped, isolated runtime rather than on your machine, so a runaway loop is contained instead of touching your environment.

Docker & SSH (coming soon)

Runtime	Timeline	Description
Docker	Q3 2026	Pull any OCI image and run agents inside ephemeral containers — ideal for CI pipelines and reproducible builds
SSH	Q4 2026	Connect to any machine (workstation, VPS, bare metal) with full terminal access and consent-gated commands

Local-first storage strategy

The bridge participates in the local-first storage model: sync.chat.push mirrors chat history into the device’s local SQLite, so your full message/code/diff history exists on your hardware even when the cloud index only carries the light per-conversation rows (~200 B each) needed for cross-device sidebar sync.