Runtimes y bridge

La página de Runtimes (/space/runtimes) documenta dónde se ejecutan realmente tus agentes: el daemon bridge local/móvil para trabajo en el dispositivo, dispositivos emparejados, sandboxes cloud en Cloudflare Workers y los próximos runtimes Docker/SSH.

¿Nuevo en el lado de IA? Lee primero Conceptos de IA desde cero — los agentes necesitan herramientas para actuar, y esta página trata de dónde y cómo corren esas herramientas de forma segura.

Los conceptos detrás de los runtimes

Los agentes actúan mediante herramientas, y las herramientas necesitan algún sitio donde ejecutarse. Esta página lo divide en dos riesgos que la plataforma debe resolver:

• ¿Dónde puede actuar el agente? El bridge ejecuta acciones en tu máquina (archivos, shell, procesos, red) o en tu teléfono (notificaciones, SMS, contactos); los sandboxes cloud ejecutan código en un isolate aislado de Workers en el edge; los runtimes Docker/SSH apuntarán a contenedores y máquinas remotas. Cada una es una superficie de ejecución distinta.
• ¿Cómo lo mantenemos seguro? Un modelo autónomo llamando a desktop.shell.execute es genuinamente peligroso, así que cada capacidad está explícitamente acotada y sujeta a consentimiento (consent_prompt/consent_response), auditada en device_action_log, y protegida por un filtro de comandos destructivos. La conexión es WebSocket solo saliente, así que ni siquiera el propio daemon acepta tráfico entrante.

El bridge es también donde vive físicamente la promesa local-first: sync.chat.push refleja tu historial en el SQLite del dispositivo, así que los datos existen en tu hardware, no solo en un índice cloud.

El daemon bridge (conector de entorno local)

El SynthHires Bridge es un daemon ultraligero de escritorio/móvil que permite a los agentes ejecutar tareas y comandos en tu propia máquina — sin subir tus archivos a la nube y sin abrir puertos en tu router.

• Plataformas: Windows (exe), macOS, Linux (binarios compilados por CI vía /api/downloads/desktop), APK Android (CI) e iOS (build de simulador en CI; distribución firmada pendiente).
• Modelo de conexión: 100% WebSocket solo saliente a la plataforma (sin puertos de entrada), TLS 1.3.
• Seguridad: filtro de comandos destructivos, acciones con consentimiento, log de auditoría.
• Sondeo de estado: la página consulta el endpoint HTTP de estado del propio daemon (http://127.0.0.1:7333/status) — la fuente autoritativa de paired, WebSocket connected, RTT y version — y cae a /api/devices cuando el daemon no es alcanzable desde el navegador (p. ej. móvil o producción).
• Estados: comprobando → esperando emparejamiento → reconectando → conectado (con RTT) → offline / requiere login.

El protocolo de red

El lado web del protocolo vive en src/lib/agent/bridge-protocol.ts (versión 1), con espejo serde-camelCase en el daemon Rust. Los frames son JSON sobre WebSocket:

Frame	Propósito
hello / hello_ack	Handshake con versión de protocolo + capacidades
heartbeat / heartbeat_ack	Liveness con medición de RTT
scope_update	Cambios de ámbito de capacidades (grant/revoke)
resume	Reconexión con reanudación de sesión
action_request / action_cancel	Solicitar o cancelar una acción de dispositivo
consent_prompt / consent_response	Diálogo de consentimiento humano-en-el-bucle
action_result / action_stream	Finalización de acción (o salida en streaming)
revoke	Revocación de dispositivo/ámbito
error	Errores de protocolo con close codes

Capacidades

El protocolo expone capacidades limitadas (BRIDGE_CAPABILITIES), cada una requiere consentimiento explícito:

• Escritorio: desktop.shell.execute, desktop.fs.read / write / delete / verify / list / watch, desktop.process.list / kill, desktop.network.fetch.
• Sync: sync.chat.push (espejo de conversaciones en el SQLite del dispositivo).
• Móvil: mobile.notifications.read / dismiss, mobile.sms.read / send, mobile.contacts.read, mobile.location.read, mobile.automation.perform, mobile.clipboard.read / write.

Emparejamiento

El emparejamiento ocurre vía /space/connections (pestaña Dispositivos) o la página de runtimes: descarga el bridge, ejecútalo, y usa “Emparejar nuevo” con un código de emparejamiento (tabla pairing_codes). Los dispositivos emparejados aparecen en DeviceList, con estado online/offline, RTT y un log de auditoría de las acciones consentidas (device_action_log).

Dispositivos emparejados

DeviceList muestra cada dispositivo emparejado con estado de conexión y te permite revocar el acceso en cualquier momento. Los registros de dispositivo viven en devices + device_tokens; revocar mata el token y cierra el WebSocket.

Sandboxes cloud (Workers)

La pestaña de Sandboxes gestiona entornos aislados de Cloudflare Workers para la ejecución de código de agentes:

• Cada sandbox tiene su propio isolate V8 con memoria, timeout y región configurables.
• Modelo stateless por isolate: sin fs, sin APIs solo-Node — el código corre en el edge cerca de tus datos.
• Los sandboxes son el objetivo de ejecución remota por defecto cuando no hay un bridge local emparejado.

La idea de ventana de contexto también aparece aquí: el código de los agentes corre en un runtime aislado y con recursos limitados en lugar de en tu máquina, así que un bucle desbocado queda contenido en lugar de tocar tu entorno.

Docker y SSH (próximamente)

Runtime	Timeline	Descripción
Docker	Q3 2026	Pull de cualquier imagen OCI y ejecución de agentes dentro de contenedores efímeros — ideal para pipelines CI y builds reproducibles
SSH	Q4 2026	Conexión a cualquier máquina (workstation, VPS, bare metal) con acceso terminal completo y comandos con consentimiento

Estrategia de almacenamiento local-first

El bridge participa en el modelo de almacenamiento local-first: sync.chat.push hace espejo del historial de chat en el SQLite local del dispositivo, así que tu historial completo de mensajes/código/diffs existe en tu hardware incluso cuando el índice cloud solo lleva las filas ligeras por conversación (~200 B cada una) necesarias para la sincronización del sidebar entre dispositivos.