Cursor creó un comando de terminal oculto para dirigir a sus agentes de IA de escritorio
Cursor ha construido un puente funcional de línea de comandos que permite a scripts externos encontrar y dirigir conversaciones de agentes de IA que ya se están ejecutando en su aplicación de escritorio, encontró RuntimeWire en Cursor 3.16.17.
By Ryan Merket · Published · Updated
RUNTIMEWIRE INVESTIGATION — Scoop
Original reporting by RuntimeWire, based on reverse engineering, testing.
Why it matters
Desktop Bridge turns visible Cursor conversations into scriptable workers, giving developers a local supervision layer while expanding what same-user processes can tell desktop agents to do.
Reporting record
Finding
Cursor 3.16.17 contains a working, gated Desktop Bridge that lets the bundled cursor CLI enumerate agent threads open in Cursor Desktop and submit follow-up instructions to them.
How we verified
Methods: reverse engineering, testing.
Cursor’s packaged application contains the cursor desktop CLI parser and help text, an authenticated local Desktop Bridge service, a gated Beta settings card, and desktop handlers for listing and messaging agent threads. In a reporter-owned test, cursor desktop ls --json returned the prepared thread’s ID, title, completed status, local source and window ID. cursor desktop send reported that the follow-up was submitted. Cursor Desktop displayed the terminal-sent instruction and returned the exact requested response: DESKTOP-BRIDGE-LIVE-OK. Cursor’s CLI guide and CLI changelog contained no reference to cursor desktop or Desktop Bridge when reviewed on August 18, 2026.
RuntimeWire extracted and examined the packaged JavaScript from Cursor’s stable Windows x64 build, version 3.16.17. We confirmed the build version, commit and date from package.json and product.json, then traced the desktop_bridge feature gate, disabled-by-default user setting, local bridge startup, discovery mechanism, bearer authentication, CLI commands and desktop message handlers. We activated the feature through Cursor’s built-in test-feature mechanism, enabled “Allow CLI to access desktop agents” in the exposed Beta card and restarted Cursor with real agent HTTP enabled. We created a disposable thread on a reporter-controlled account, enumerated it through cursor desktop ls --json and sent a deterministic no-operation instruction through cursor desktop send. The agent returned the exact requested token inside the original desktop conversation. We preserved screenshots and calculated SHA-256 hashes for the source archive, relevant application files and successful test image. No third-party account, conversation or data was accessed.
Tested versions: Cursor 3.16.17, Windows x64 stable, commit 6b2afae0257df2bb5e1835f15165dc2f0de056b0, built 2026-08-14T01:41:12.803Z.
Reproduction
RuntimeWire independently reproduced the core finding.
Requirements: Cursor 3.16.17 for Windows x64 and a reporter-controlled Cursor account. Quit every running Cursor process. Launch Cursor with its built-in smoke-test driver, real agent HTTP and the desktop_bridge feature override: $CursorExe = "$env\Programs\cursor\Cursor.exe" $DesktopBridgeFlag = "eyJkZXNrdG9wX2JyaWRnZSI6dHJ1ZX0=" Start-Process -FilePath $CursorExe -ArgumentList @( "--glass" "--enable-smoke-test-driver" "--smoke-test-use-real-agent-http" "--test-feature-flags=$DesktopBridgeFlag" ) Open Cursor Settings → Beta. Enable “Allow CLI to access desktop agents.” Quit Cursor completely and relaunch it with the same arguments. Create a disposable agent thread titled “Bridge thread readiness.” Ask it to reply with BRIDGE-THREAD-READY without editing files or running commands. In PowerShell, locate the thread: $CursorCmd = "$env\Programs\cursor\resources\app\bin\cursor.cmd" $Threads = (& $CursorCmd desktop ls --json) | ConvertFrom-Json $Target = $Threads | Where-Object { $_.title -eq "Bridge thread readiness" } | Select-Object -First 1 Confirm that $Target contains an ID, title, status, source and window ID. Submit the follow-up: & $CursorCmd desktop send $Target.id "Reply with exactly DESKTOP-BRIDGE-LIVE-OK. Do not edit files or run commands." Confirm that PowerShell reports the message as submitted and that DESKTOP-BRIDGE-LIVE-OK appears inside the original Cursor Desktop conversation.
File hashes
sha256 resources/app/out/cli.jssha256:4ca5f52518ec5fea1a0c4732c6216dc45182b59a1fe2146d3f9ad6062a3490cd resources/app/out/main.jssha256:50ec9d3e80b9f797378eb1a6896ecdadc3a0e3daabe9fec440a1f4e2d6c1878d resources/app/out/vs/workbench/workbench.glass.main.jssha256:2100a37e6ddd23fd3f0adf982dcd6779a525c25f0d6acb9fa0683a44cb947592 resources/app/out/vs/workbench/workbench.desktop.main.jssha256:9dabecdb4d25cdf8a7b29800fa186bd227b25483789cd7536bbe68b2c5cd92f2 successful-desktop-bridge-test.png
Company response
RuntimeWire requested comment; the company had not responded by publication time.
La función se llama Desktop Bridge. Añade un comando oculto cursor desktop con dos operaciones:
cursor desktop ls cursor desktop send <thread> [text...]
RuntimeWire activó la función con acceso limitado en una instalación de Windows controlada por un reportero y la probó contra un hilo de agente descartable. El comando ls devolvió el ID de la conversación, el título, la fuente, el estado y el número de ventana. RuntimeWire luego usó PowerShell para enviar una nueva instrucción al hilo completado:
Responde exactamente con DESKTOP-BRIDGE-LIVE-OK. No edites archivos ni ejecutes comandos.
La línea de comandos informó que el mensaje se había enviado al hilo seleccionado. Cursor Desktop mostró la instrucción dentro de la conversación existente, inició un nuevo turno del agente y devolvió DESKTOP-BRIDGE-LIVE-OK.
El resultado confirma que Desktop Bridge funciona a lo largo de todo el trayecto desde el shell hasta un agente dentro de la aplicación gráfica de Cursor. También ofrece a los desarrolladores una forma de construir supervisores alrededor de Cursor Desktop sin abrir manualmente cada conversación y escribir otro prompt.
A command that appears only when the bridge is alive
Desktop Bridge está compilado en la versión estable de Cursor para Windows con fecha 14 de agosto de 2026. La copia examinada por RuntimeWire se identifica como la versión 3.16.17, commit 6b2afae0257df2bb5e1835f15165dc2f0de056b0.
El acceso está controlado por duplicado. Una feature gate entregada por el servidor llamada desktop_bridge determina si Cursor muestra una tarjeta de configuración Beta. Esa tarjeta contiene un interruptor separado, desactivado por defecto, etiquetado “Permitir que la CLI acceda a agentes de escritorio.” Cursor indica a los usuarios que reinicien la aplicación después de cambiarlo.
En condiciones normales de inicio, la tarjeta Desktop Bridge no apareció en la cuenta de RuntimeWire. RuntimeWire utilizó el mecanismo integrado de banderas de prueba de Cursor para exponer la tarjeta, habilitó la opción de usuario y reinició la aplicación antes de realizar la prueba en vivo.
El comando se oculta cuando el puente local no está disponible. La CLI de Cursor verifica un registro de descubrimiento activo antes de analizar desktop como un subcomando. Durante la primera prueba de RuntimeWire con el puente deshabilitado, cursor desktop ls no produjo lista de hilos y Cursor trató desktop como un destino tipo sistema de archivos, abriendo una pestaña de editor con ese nombre.
Una vez que el puente se inició, el mismo comando mostró su texto de ayuda: “Interact with chat threads in a running Cursor desktop app.”
Al 18 de agosto, la guía actual de CLI de Cursor y el changelog de la CLI no contienen mención alguna de cursor desktop o Desktop Bridge. La versión del CLI del 11 de agosto sí documenta la dirección dentro de una sesión de agente basada en terminal. Desktop Bridge cruza una frontera distinta al enviar instrucciones del shell a conversaciones abiertas en la aplicación de escritorio.
Qué puede hacer Desktop Bridge
La implementación puede enumerar hasta 200 hilos en instancias de Cursor Desktop en ejecución. Su salida JSON estructurada hace que la lista sea utilizable por scripts, con campos para ID del hilo, título, fuente, estado, tiempo de actualización, ventana e instancia de la aplicación.
desktop send acepta un ID de hilo completo o un prefijo único. Puede leer la instrucción desde los argumentos de la línea de comandos o desde la entrada estándar. Si el agente seleccionado ya está trabajando, el comportamiento predeterminado encola el nuevo mensaje hasta que termine el turno actual. La opción --force envía inmediatamente e interrumpe el turno activo.
El código de Cursor reconoce las fuentes de hilo local, cloud, draft y Claude Code. Se niega a enviar mensajes a borradores y a hilos de Claude Code. RuntimeWire verificó el listado y el envío contra un agente local de Cursor. No probamos en vivo la opción de interrupción ni un hilo con origen en la nube.
El conjunto de comandos actual no puede crear un nuevo agente, recuperar una transcripción ni imprimir la respuesta del agente de vuelta en el terminal. Su rol es más limitado: encontrar conversaciones que existen en Cursor Desktop e inyectarles instrucciones.
Eso es suficiente para soportar un bucle básico de control. Un proceso local podría sondear el estado de los hilos en JSON, decidir qué agente completado necesita otra asignación, encolar seguimientos para agentes ocupados o interrumpir una ejecución cuando cambie una condición externa. Cursor ya ha documentado agentes sin interfaz, automatizaciones y agentes programáticos mediante su CLI y SDK; Desktop Bridge conecta esos patrones de scripting con el trabajo ya visible en la interfaz de escritorio.
Un puente separado del SDK público de Cursor
Cursor también publica documentación de un producto llamado SDK Bridge. Los dos puentes sirven para trabajos diferentes.
SDK Bridge incrusta el agent SDK de Cursor y expone un protocolo documentado para crear, reanudar y operar agentes programáticos. Desktop Bridge vive dentro de la aplicación de escritorio y apunta a conversaciones ya abiertas allí. Usa el lanzador ordinario cursor en lugar del binario separado cursor-sdk-bridge.
El servicio local detrás de Desktop Bridge parece diseñado para prevenir solicitudes arbitrarias no autenticadas. Al iniciarse, crea un token bearer aleatorio de 64 caracteres y un token separado de invocación de renderer. La CLI descubre el socket local y el bearer token a través de un registro almacenado en el directorio .cursor/desktop-bridge del usuario. Cada petición debe autenticarse antes de que el proceso de escritorio liste o envíe mensajes a los hilos. En sistemas que respetan los modos de archivo POSIX, el código crea el directorio y el archivo de descubrimiento con permisos solo para el propietario.
Esos controles protegen el puente de llamadas locales no autenticadas. Cualquier proceso que ya esté ejecutándose como el mismo usuario del sistema operativo aún podría ser capaz de leer archivos propiedad del usuario, lo que hace que el modelo de amenazas previsto por Cursor y los controles empresariales sean preguntas importantes antes de un despliegue más amplio.
La implementación de la función es lo bastante madura como para manejar múltiples instancias de Cursor en ejecución, registros de descubrimiento obsoletos, prefijos de hilo ambiguos, timeouts, fallas de autenticación y límites de tamaño de mensaje. Su interfaz con control de acceso y la documentación ausente dejan su estado de liberación sin resolver.
Por ahora, Cursor 3.16.17 contiene una superficie de control funcional desde el shell hasta el escritorio. La prueba de RuntimeWire mostró que puede localizar una conversación real, inyectar una nueva instrucción y lograr que el agente de escritorio complete otro turno sin que el usuario envíe ese prompt a través de la interfaz de Cursor.