Control remoto y móvil
Control Center es una app de escritorio, pero el trabajo que sigue no se detiene
cuando te alejas de tu escritorio. El control remoto empareja tu celular con
tu cc_server, usando Remote, la app
complementaria en remote.usectrl.dev, para que puedas seguir la flota desde ahí:
leer mensajes y tickets, responder a un agente, clasificar tu feed de noticias,
sin que el audio, la transcripción, el código fuente ni las credenciales que
viven en el servidor salgan nunca de él.
Piénsalo como un compañero de la interfaz de escritorio orientado sobre todo a la lectura. No pretende reemplazar al cliente de escritorio completo.
Transporte
Sección titulada «Transporte»El celular llega a cc_server por WebSocket: ya sea una conexión directa
(loopback, LAN, tailnet o wss://) o una sala con acceso por invitación en un
broker de señalización que retransmite tramas selladas. No hay canal de datos
punto a punto.
Qué puede hacer el celular
Sección titulada «Qué puede hacer el celular»El celular emparejado llega a una porción pequeña y deliberada de la superficie del servidor:
- Leer tickets, agentes, espacios y sus mensajes, y tu feed de noticias
- Responder: enviar un mensaje en un espacio, actualizar o asignar un ticket, marcar un artículo como leído o guardado
- Ejecutar un playbook: instanciar una plantilla de plan guardada con sus parámetros. Esto solo propone un plan; nada se ejecuta ni se gasta hasta que un operador lo aprueba en Plan Studio en un cliente completo
- Cambiar de espacio de trabajo, desde el selector propio del celular
Eso es casi todo. Un celular es un Principal de menor privilegio que un cliente completo. No puede generar procesos, gastar presupuesto de LLM, hacer push a GitHub ni crear espacios de trabajo. Consulta el modelo de acceso para ver cómo se aplica eso en lugar de solo pretenderse.
Cómo se construye el enlace
Sección titulada «Cómo se construye el enlace»La conexión viaja por un relevo intermediado: el servidor se une a una sala
con acceso por invitación en un broker wss:// como su propietario, y cada
cliente emparejado —escritorio, web, celular— se une a la misma sala con un
token de admisión de tiempo limitado. Concurren tres piezas:
| Pieza | Rol |
|---|---|
| Remote (app del celular) | La app web complementaria, alojada en remote.usectrl.dev de forma predeterminada, o autoalojada. Se carga en un navegador y guarda el registro de emparejamiento en IndexedDB. |
| Broker del relevo | Un relevo wss:// sin estado (cc_signaling_server) que aloja salas de N vías. Transporta solo tramas opacas: cada carga útil se sella de extremo a extremo entre el celular y el servidor, así que el broker nunca ve datos de la app ni el secreto de emparejamiento, y nunca interpreta lo que reenvía. |
cc_server |
El propietario de la sala. Responde a las llamadas del celular a través del mismo despachador que usan todos los demás clientes. |
Una oferta de emparejamiento lleva un descriptor de conexión que enumera
todas las rutas al servidor (LAN, tailnet, wss:// público, relevo) más su
huella de identidad. El resolutor del celular elige la mejor ruta alcanzable y
fija la huella en la primera conexión (TOFU); el relevo garantiza la
conectividad aun cuando no exista ninguna ruta directa, sin poder leer nunca el
tráfico.
Qué es la carga útil de emparejamiento
Sección titulada «Qué es la carga útil de emparejamiento»El emparejamiento se genera desde la app y se entrega como un enlace profundo; consulta Emparejar un dispositivo para el procedimiento. Aquí lo que importa es la anatomía.
https://<pwa-host>/#<payload>La carga útil viaja en el fragmento de la URL, la parte después de # que
los navegadores nunca envían al servidor, así que el host HTTPS de la PWA nunca
la ve. Lleva todo lo que el celular necesita para llegar al servidor y
demostrar quién es: el descriptor de conexión (todas las rutas más la huella de
identidad), un id de dispositivo recién generado, una clave precompartida de 32
bytes y una marca de caducidad. El celular la decodifica, guarda un registro de
emparejamiento localmente y elimina el fragmento para que el secreto salga de
la URL.
Hay dos formas de carga útil y no son intercambiables. El QR del celular
generado desde el panel de emparejamiento en la app es el PairingPayload v2
de arriba, apuntado al host de la PWA de Remote. cc_server pair --client-url
emite un enlace v1 distinto y más antiguo ({s, i, k} — URL del servidor, id
de dispositivo, clave) destinado únicamente al cliente web.
También difieren en su vigencia, algo fácil de errar:
| Generado por | Caducidad de la credencial |
|---|---|
Panel de emparejamiento en la app (pairing.mint) |
30 días, siempre |
cc_server pair en la línea de comandos |
Ninguna — la credencial no caduca |
El modelo de acceso
Sección titulada «El modelo de acceso»Un dispositivo emparejado está autenticado pero no es confiable. Varias compuertas independientes impiden que un emparejamiento aprobado (o filtrado) se convierta en control total del servidor.
1. La pertenencia, no el emparejamiento, es la frontera
Sección titulada «1. La pertenencia, no el emparejamiento, es la frontera»Una clave de emparejamiento válida demuestra qué dispositivo eres. Lo que puedes leer o cambiar lo decide tu rol de espacio de trabajo, que se vuelve a resolver en cada llamada, y los permisos por repositorio en todo lo que exponga contenido de repos. Un dispositivo que tiene una clave perfectamente válida pero pertenece a un usuario que no es miembro del espacio de trabajo indicado se rechaza con «Not a member of this workspace».
El mínimo de rol se deriva del tipo de operación salvo que esta declare el
suyo: las lecturas necesitan guest, las mutaciones necesitan member y las
operaciones destructivas necesitan admin.
2. Un celular es un nivel de sesión inferior
Sección titulada «2. Un celular es un nivel de sesión inferior»Más allá de la verificación de rol, una sesión de celular tiene una capacidad menor que una de escritorio o web. Las operaciones declaradas exclusivas de cliente completo se rechazan para un celular antes de que se ejecute el manejador, sin importar cuán privilegiado sea el usuario detrás de él: generar, listar, renombrar y revocar emparejamientos de dispositivos; leer y configurar la conectividad del túnel; el respaldo del servidor y la exportación/importación de espacios de trabajo; la detección y terminación de procesos; los sondeos de adaptadores; la configuración del servidor; la administración de SSO; el control de la flota; y tomar el control de un agente en ejecución o devolverlo.
3. Una lista de permitidos con denegación predeterminada
Sección titulada «3. Una lista de permitidos con denegación predeterminada»Para la superficie de herramientas de MCP en concreto (tools/call), una lista
de permitidos con denegación predeterminada rige qué herramientas puede invocar
el celular. Todo lo que no esté en la lista se rechaza antes de ejecutarse. La
lista es predominantemente de lectura y observación, más un puñado de
escrituras solo locales —un mensaje, una actualización de ticket, una marca
en un artículo— que no gastan presupuesto de LLM, no generan procesos y no
tocan ningún sistema externo.
Denegados, por ejemplo: consultar a un agente, iniciar una revisión con IA, detener a un agente, publicar una revisión en GitHub, contratar o despedir agentes, crear un espacio de trabajo.
4. Alcance de espacio de trabajo por llamada
Sección titulada «4. Alcance de espacio de trabajo por llamada»El servidor no tiene un «espacio de trabajo actual». Es sin estado por
diseño: cada llamada con ámbito de espacio de trabajo debe nombrar su
workspace_id de destino en sus argumentos, y el despachador rechaza la llamada
de plano cuando falta o nombra un espacio de trabajo que el servidor no tiene
registrado —antes de que nada abra una base de datos. Un celular nunca puede,
por lo tanto, heredar el ámbito de otro cliente ni desviarse hacia él, y
nombrar un espacio de trabajo ajeno tampoco ayuda, porque la verificación de
pertenencia de la compuerta 1 sigue aplicándose. Este es el mismo
invariante de aislamiento de espacios de trabajo
que aplica el resto del producto.
5. Tramas selladas de extremo a extremo con la clave precompartida
Sección titulada «5. Tramas selladas de extremo a extremo con la clave precompartida»Cada trama entre el celular y el servidor se sella con la clave de emparejamiento; el token de admisión solo mete a un cliente en la sala, no descifra nada. El broker retransmite texto cifrado y nunca ve la clave. Un dispositivo revocado descubre que su credencial ya no está, así que falla en cerrado al reconectarse.
Una credencial generada por la app tiene un límite de 30 días; pasado ese plazo, la compuerta de conexión la invalida y el celular debe volver a emparejarse. La revocación es en vivo: el servidor vigila la tabla de dispositivos y cierra las sesiones abiertas de un dispositivo revocado en cuestión de segundos en lugar de esperar a su siguiente conexión.
6. Límites de velocidad por Principal
Sección titulada «6. Límites de velocidad por Principal»Un limitador de ventana deslizante limita el tráfico remoto de herramientas a 120 llamadas por minuto, con un sublímite más estricto de 30 por minuto para los verbos que mutan. El presupuesto pertenece al Principal, no a la sesión: tres de tus dispositivos consumen de una misma asignación, así que un cliente secuestrado no puede ganar margen abriendo más sesiones y un miembro ruidoso no puede dejar sin recursos a los demás.
7. Un broker que no aprende nada
Sección titulada «7. Un broker que no aprende nada»El broker del relevo es deliberadamente simple: aloja salas, reenvía tramas selladas y no guarda cuentas, ni datos de la app, ni claves. Las salas tienen acceso por invitación y son transitorias. Los datos de la app, el audio, la transcripción, el código fuente y las credenciales se quedan todos en el servidor.
Actualizaciones en vivo
Sección titulada «Actualizaciones en vivo»Una vez emparejado, el celular recibe actualizaciones en vivo como tramas de notificación —mensajes nuevos de agentes, tickets asignados a ti, cambios de estado— que reflejan las notificaciones del propio escritorio. El servidor difunde esas tramas a todas las sesiones conectadas y el filtro de espacio de trabajo se aplica del lado del cliente, así que lo que ves queda acotado al espacio de trabajo que estás mirando.
Dónde vive
Sección titulada «Dónde vive»| Superficie | Qué muestra |
|---|---|
Ajustes → Tú → Tus dispositivos (/workspaces/:workspaceId/settings/you/devices) |
Clientes emparejados con estado en vivo, además de Vincular un nuevo cliente (navegador web, app de escritorio o celular) y revocar |
El mismo panel genera emparejamientos para un segundo navegador o app de escritorio, no solo para celulares: el flujo es idéntico, solo cambia el enlace profundo.
Ver también
Sección titulada «Ver también»- Espacios de trabajo y aislamiento: el alcance por llamada en el que se apoya
- Multijugador — identidad, pertenencia y presencia: roles, pertenencia y permisos de repositorio
- Implementación y clientes: dónde se ubica el control remoto entre los niveles de cliente
- Arquitectura: dónde se ubica el control remoto en la pila
- Emparejar un dispositivo