CLI, automatización y MCP

Todo lo que puedes hacer en la app también puedes hacerlo sin la ventana. El mismo binario que aloja la interfaz gráfica —bromure-cli, dentro de Bromure Agentic Coding.app/Contents/MacOS/— es una CLI completa de múltiples comandos, un plano de control HTTP, dos servidores MCP, un diccionario de AppleScript y un planificador. Este capítulo es la referencia de todos ellos.

Cuatro superficies de automatización se apoyan sobre un único plano de control:

• La línea de comandos bromure-cli — una CLI al estilo de Docker/kubectl para crear espacios de trabajo, arrancar VM, conectar terminales, ejecutar comandos y leer trazas.
• La API de automatización — el mismo plano de control expuesto como JSON sobre HTTP en la interfaz de loopback, para hacer scripting desde cualquier lenguaje.
• Servidores MCP — un servidor stdio que permite a un agente de IA (Claude Code, Claude Desktop) administrar la app, y un servidor browser que permite a un agente controlar el Chromium integrado de su espacio de trabajo.
• AppleScript — el diccionario Bromure AC Suite, para scripting de macOS y herramientas de captura de pantalla.

Las automatizaciones programadas —ejecuciones de agente recurrentes y desatendidas— se construyen sobre el mismo plano de control y se tratan al final del capítulo.

El plano de control: socket y API

Cada una de estas superficies acaba hablando HTTP con la app en ejecución a través de uno de dos transportes:

La CLI nunca habla directamente con una VM. Cada subcomando es un cliente HTTP ligero sobre el socket de control, de modo que los mismos comandos funcionan localmente y —cuando el socket se tuneliza sobre SSH— contra una instancia remota desde un cliente enriquecido. Si no hay ningún agente en ejecución cuando invocas un comando que necesita uno, la CLI arranca automáticamente un agente en segundo plano sin ventana (bromure-cli run --headless) y espera hasta 40 segundos a que responda /health. Los comandos de solo lectura (vm ls, describe, trace …) no arrancan nada automáticamente; en su lugar imprimen No bromure-cli agent running.

Nota: El socket de control siempre está disponible mientras la app se ejecuta y es independiente del interruptor Activar servidor de automatización. Ese interruptor solo controla el listener TCP en el puerto 9223. No necesitas activar la API de automatización para usar la CLI bromure-cli.

La línea de comandos bromure-cli

Puedes llamar al binario por su ruta completa dentro del paquete, pero la app ofrece una instalación única de un alias corto. Al iniciarse muestra un aviso —¿Instalar la herramienta de línea de comandos "bromure-cli"?— con los botones Instalar / Ahora no / No preguntar de nuevo. Al elegir Instalar se crea un enlace simbólico de /usr/local/bin/bromure-cli al binario de la app (un aviso de administrador). Bajo el nombre bromure-cli el binario oculta los comandos internos de la app —gestión de imágenes, el servidor mcp y el run predeterminado de la interfaz gráfica— y expone únicamente los grupos orientados a la terminal (Espacios de trabajo, Trazado, Inferencia local, Enterprise, remote); un bromure-cli sin argumentos imprime la ayuda en lugar de iniciar la app. Invocado como bromure-cli, todo está disponible y el subcomando predeterminado es run (la interfaz gráfica). Los ejemplos siguientes usan bromure-cli; sustitúyelo libremente por bromure-cli en los comandos que este expone.

Los comandos aceptan un id de espacio de trabajo, un prefijo de id corto o su nombre dondequiera que se muestre un argumento de espacio de trabajo. Los espacios de trabajo son las configuraciones de VM persistentes descritas en Espacios de trabajo; los grupos de comandos vm y workspaces son alias mutuos.

La app y el agente en segundo plano

Gestión de imágenes

La imagen base se instala una sola vez. Estos comandos están ocultos bajo el alias bromure-cli.

Nota: No existe un subcomando setup — eso pertenece al producto hermano Bromure (navegador). El comando de instalación de la imagen de Agentic Coding es init. Si no existe ninguna imagen base, iniciar la interfaz gráfica te encamina en su lugar al flujo de configuración interno de la app.

Control de espacios de trabajo y VM

Este es el grupo central. vm run tiene forma deliberadamente de Docker: arranca un espacio de trabajo y entrega tu terminal a la sesión tmux compartida bromure del invitado.

Vale la pena conocer algunos detalles operativos:

• Flags de vm run. --tool es claude, codex o grok; --auth es token, subscription o bedrock. -v/--volume <hostdir> monta una carpeta del anfitrión en ~/<basename> dentro del invitado (repetible, hasta 8). -d/--detach arranca la VM y regresa en lugar de conectarse. --rm elimina el espacio de trabajo y su disco cuando la VM se detiene. Desconéctate de un tmux conectado con Ctrl-b d — eso deja la VM en ejecución.
• Consciente del TTY. El comportamiento predeterminado al estilo de Docker de entregar la terminal a tmux solo se aplica en una terminal real; las invocaciones por tubería o mediante script se comportan silenciosamente como si hubieras pasado -d.
• Autenticación de workspaces create. Para create, --auth también acepta local. Los colores son blue, red, green, orange, purple, pink, teal o gray.
• Conservar en blanco al editar. workspaces edit exporta toda la configuración con los secretos en blanco; un documento guardado con un secreto en blanco conserva el valor almacenado, de modo que un viaje de ida y vuelta nunca puede borrar tus claves. Un búfer sin cambios no guarda nada; un JSON no válido aborta.
• Esperas de exec. vm exec espera hasta 10 segundos al agente de shell del invitado; un 502 significa que la VM puede no estar en ejecución o que el nombre no coincidió. Los avisos de aprobación que se disparan durante una sesión conectada se muestran en tu terminal (véase Consentimiento en terminales adjuntas), nunca dentro del invitado.

Modelos, enrutamiento y Fusion

La inferencia local se trata en profundidad en Modelos locales y la síntesis multimodelo en Fusion; los interruptores de la CLI son:

fusion también acepta on/engage y off/disengage como sinónimos.

Inspección de trazas

Estos leen las trazas de sesión MITM por espacio de trabajo. No devuelven nada a menos que el espacio de trabajo tenga el trazado activado —véase Ajustes de trazado— y la historia completa está en Trazado.

Acceso remoto

La puerta de entrada SSH opcional está desactivada por defecto y documentada por completo en Acceso remoto. Todas las operaciones pasan por la app en ejecución a través del socket de control.

Inscripción en Enterprise

Contrapartes en la CLI de la hoja Inscribirse en bromure.io…, para el aprovisionamiento de dispositivos mediante script. Véase Enterprise.

Comandos de integración e internos

La TUI remota (__remote-menu)

Cuando el acceso remoto SSH está activado, cada inicio de sesión remoto se fuerza (mediante ForceCommand) hacia una interfaz de terminal ANSI hecha a mano en lugar de un shell — un minishell de pantalla alternativa y 256 colores gobernado por las teclas de flecha y los dígitos que funciona sobre cualquier PTY de SSH (usa ssh -t). Refleja toda la CLI como menús:

• Espacios de trabajo — crear con un formulario de una sola pantalla (Nombre, Herramienta, Autenticación, Clave API, Memoria, Color, Carpetas, Generar SSH, Configuración completa…, Crear), acciones por espacio de trabajo (Conectar, Nueva pestaña, Describir, Configurar…, Fusion, Enrutamiento, Worktrees…, Reiniciar…, Suspender, Detener para los espacios de trabajo en ejecución; Iniciar, Describir, Configurar…, Eliminar para los apagados) y una vista de tabla sin formato. Configurar… reproduce de forma nativa cada panel del editor de la interfaz gráfica.
• Modelos — los modelos instalados y el catálogo de descarga; al elegir un modelo no instalado se ofrece hacer model pull en línea con progreso en vivo.
• Trazas — Resumen / Nombres de host / Fugas / Recientes / Borrar.

Mientras estás conectado al tmux de un espacio de trabajo, un atajo de teclado mágico (por defecto Ctrl-], mostrado en el banner) hace aparecer una superposición de control dibujada por el anfitrión: un árbol de pestañas, Nueva pestaña, Worktrees…, Fusion, Enrutamiento, Editar configuración…, Reiniciar…, Suspender, Desconectar. El invitado nunca ve la tecla que la dispara — anúlala con el archivo remote/overlay-key o $BROMURE_OVERLAY_KEY. Ctrl-b d desconecta de tmux y vuelve al menú. La historia completa del acceso remoto y del cliente enriquecido, incluida la superposición y la configuración de la conexión, está en Acceso remoto.

La API de automatización de loopback

El plano de control también puede exponerse como JSON sobre HTTP en TCP para hacer scripting desde cualquier lenguaje. Está desactivado por defecto.

Activarla

Abre Bromure → Preferencias → Automatización — el panel API de automatización y servidor MCP.

1. Activa Activar servidor de automatización. Cuando está activo, el panel indica Escuchando en 127.0.0.1:9223; desactivarlo detiene el servidor de inmediato.
2. Opcionalmente establece el Puerto (el campo está rotulado (predeterminado: 9223)) y la Dirección de enlace (predeterminada 127.0.0.1). El puerto y la dirección de enlace surten efecto la próxima vez que se inicia el servidor — desactiva y vuelve a activar el interruptor para aplicarlos ahora.

También puedes accionar el interruptor sin la interfaz gráfica:

defaults write io.bromure.agentic-coding automation.enabled -bool true

Advertencia: Establecer la Dirección de enlace en algo distinto de 127.0.0.1 expone la API —y el servidor MCP que la respalda— a la red, y el panel advierte Un enlace fuera de loopback expone la API a la red. El servidor MCP no tiene autenticación. No hay autenticación en el listener TCP más allá del límite de loopback y de la puerta BROMURE_DEBUG_CLAUDE que se describe abajo. Deja la dirección de enlace en loopback a menos que tengas una razón específica y de confianza para no hacerlo.

Modelo de autenticación

El listener TCP y el socket de control sirven las mismas rutas, pero con acceso distinto:

En otras palabras: el socket de control es la vía de acceso completo, exclusiva del propietario; la API TCP abre el subconjunto seguro en loopback y protege las rutas potentes tras el flag de depuración. Los segmentos de ruta están codificados con un único porcentaje (para que funcionen los nombres de espacio de trabajo con espacios) y se aceptan cuerpos de solicitud de hasta 8 MB.

Endpoints para scripting

Las rutas más útiles:

Como la ruta del socket de control contiene espacios, captúrala primero en una variable:

SOCK="$HOME/Library/Application Support/BromureAC/control.sock"

# Full mirror snapshot (control socket only)
curl --unix-socket "$SOCK" http://localhost/state

# List running VMs (control socket — no debug flag needed here)
curl --unix-socket "$SOCK" http://localhost/vms

# Boot a workspace by name
curl --unix-socket "$SOCK" -X POST http://localhost/vms \
  -d '{"profile":"Claude Dev"}'

# Answer a queued lifecycle prompt with one of its offered button labels
curl --unix-socket "$SOCK" -X POST http://localhost/prompts/PROMPT_ID/answer \
  -d '{"choice":"Not Now"}'

El subconjunto seguro funciona sobre la API TCP una vez la has activado — por ejemplo, listar y abrir sesiones no necesita ningún flag de depuración:

# List sessions
curl http://127.0.0.1:9223/sessions

# Open a session for a workspace
curl -X POST http://127.0.0.1:9223/sessions -d '{"profile":"Claude Dev"}'

Nota: GET /vms (listar las VM en ejecución) está disponible sobre la API de automatización TCP sin ningún flag de depuración. Las rutas de VM que mutan —POST /vms (arrancar una VM) y POST /vms/<id>/exec— requieren BROMURE_DEBUG_CLAUDE sobre TCP; contrólalas a través del socket de control (como arriba) cuando no quieras ejecutar la app en modo de depuración. Toda la superficie de endpoints —incluidas las acciones de worktree y pestaña, /trace, /remote y las rutas de réplica del cliente enriquecido— se resume en el Apéndice.

El servidor MCP de AC (bromure-cli mcp)

bromure-cli mcp ejecuta un servidor MCP de JSON-RPC en stdio (nombre de servidor bromure-cli) que permite a una herramienta de IA administrar la app. Envuelve la API HTTP de automatización y AppleScript, así que activa primero el servidor de automatización — las herramientas de listado de sesiones y perfiles llaman a la API HTTP en --api-url (predeterminado http://127.0.0.1:9223).

Las herramientas que expone:

• bromure_ac_list_profiles, bromure_ac_list_sessions
• bromure_ac_open_session (espera hasta 30 segundos a la ventana), bromure_ac_close_session
• bromure_ac_get_profile, bromure_ac_set_profile (reemplazo JSON atómico, se conserva el id)
• bromure_ac_get_profile_setting, bromure_ac_set_profile_setting (las claves incluyen name, color, comments, tool, authMode, apiKey, closeAction, memoryGB, folderPathsCount, mcpServerCount, keyboardLayoutOverride, keyRepeatDelayMs, keyRepeatRateHz)

Con --debug (y BROMURE_DEBUG_CLAUDE establecido en la app) añade bromure_ac_app_state, bromure_ac_vm_exec, bromure_ac_vm_read_file y bromure_ac_vm_write_file.

Para conectarlo a Claude Code, añade lo siguiente a ~/.config/claude-code/.mcp.json (o el equivalente de tu cliente). Este es el fragmento exacto que la sección Configuración del cliente MCP del panel de Preferencias ofrece para copiar:

{
  "mcpServers": {
    "bromure-cli": {
      "command": "/Applications/Bromure Agentic Coding.app/Contents/MacOS/bromure-cli",
      "args": ["mcp"]
    }
  }
}

Nota: Las herramientas de perfil get/set invocan osascript (AppleScript contra la app en ejecución), por lo que la app gráfica debe estar en ejecución y macOS puede pedir una vez el permiso de Automatización. El JSON de perfil viaja con los secretos en blanco a menos que BROMURE_DEBUG_CLAUDE esté establecido.

El servidor MCP del navegador en el espacio de trabajo

Al margen del servidor MCP de AC, a cada agente de un espacio de trabajo se le asigna automáticamente un servidor MCP browser — sin configuración. Controla el Chromium integrado del espacio de trabajo, que se ejecuta en su propia VM desechable. El panel MCP del editor del espacio de trabajo describe los servidores MCP propios del espacio de trabajo; el servidor de navegador integrado está siempre presente por encima de lo que añadas allí.

El servidor expone 23 herramientas de navegación e inspección — browser_navigate, browser_new_tab, browser_list_tabs, browser_activate_tab, browser_close_tab, browser_back, browser_forward, browser_reload, browser_screenshot (con opción de página completa), browser_evaluate, browser_get_text, browser_get_html, browser_get_links, browser_click, browser_fill, browser_type, browser_press_key, browser_wait_for, browser_network, browser_network_summary, browser_clear_network, browser_console y browser_pick_element (un selector de elementos interactivo de 60 segundos).

El transporte es una capa stdio de Python generada, bromure-browser-mcp.py, dispuesta en modo de solo lectura dentro del invitado en /mnt/bromure-meta/. Marca el anfitrión sobre el puerto vsock 5830 y se reconecta indefinidamente ante las caídas, de modo que el cliente MCP nunca retira las herramientas. Una llamada de herramienta contra un navegador cerrado lo abre y espera al arranque en frío. Como el navegador es una VM separada, las instrucciones del servidor advierten a los agentes que alcancen el servidor de desarrollo de un espacio de trabajo por la IP de LAN del espacio de trabajo (hostname -I), nunca localhost.

Nota: En un cliente enriquecido, el flujo del navegador-MCP del agente puede empalmarse sobre un canal SSH para que un agente remoto controle el panel del navegador que ves localmente. Solo hay un relé activo a la vez. Véase Acceso remoto.

Los servidores MCP HTTP que añades en el editor pueden autenticarse a través del intermediario OAuth del lado del anfitrión: realiza el descubrimiento RFC 8414 y el registro dinámico de cliente RFC 7591 (como Bromure AC), ejecuta un flujo de código de autorización PKCE en el navegador de tu sistema y sirve la retrollamada en un listener de loopback (puertos 28500–28599). La página de éxito dice Autorizado — Puedes cerrar esta pestaña y volver a Bromure AC. Todo el flujo se ejecuta en el anfitrión, de modo que la VM nunca ve credenciales OAuth reales.

AppleScript (Bromure AC Suite)

Un diccionario de scripting, el Bromure AC Suite, es una tercera superficie de automatización — útil para la orquestación y para las herramientas de captura de pantalla que necesitan IDs de ventana. Apunta a application "Bromure Agentic Coding" desde Script Editor o osascript. Abarca:

• Perfiles — list profiles, create ac profile <name> [color <c>] (devuelve un UUID), delete ac profile <name|uuid> y el viaje de ida y vuelta del documento completo mediante get profile json / set profile json (todo el perfil Codable; se conserva el id; los secretos almacenados se fusionan bajo los campos en blanco).
• Ajustes por campo — get profile setting … key … / set profile setting … key … to value ….
• Ventanas del editor — open profile manager, open ac profile editor, close ac profile editor, select editor category <key> y get editor window id / get main window id (un CGWindowID para screencapture -l).
• Sesiones — open ac session, close ac session, list ac sessions.
• Estado y ajustes de la app — get app state (JSON), más get ac app setting / set ac app setting para las claves automation.enabled, automation.port, automation.bindAddress, remoteAccess.enabled, remoteAccess.port, remoteAccess.bindAddress, managed.serverURL y managed.acIngestURL. Establecer automation.enabled acciona el servidor HTTP en vivo.

Por ejemplo, para abrir una sesión:

osascript -e 'tell application "Bromure Agentic Coding" to open ac session "Claude Dev"'

Nota: El JSON de perfil viaja con los secretos depurados a menos que BROMURE_DEBUG_CLAUDE esté establecido. Establecer apiKey en una cadena vacía mediante set profile setting borra la clave en lugar de conservarla — a diferencia del comportamiento de conservar-en-blanco de los puentes de ida y vuelta JSON. El cambio de idioma deliberadamente no es scriptable; relanza la app con, por ejemplo, -AppleLanguages "(fr)" en su lugar.

Automatizaciones programadas

Una automatización programada es una ejecución de agente recurrente y desatendida vinculada a un espacio de trabajo: cuando se dispara, crea un worktree de git nuevo y lanza allí el agente elegido con tu prompt, y la ejecución aparece como una pestaña de worktree corriente. Las automatizaciones se crean y administran desde el tablero de automatizaciones (⇧⌘A, o la sección AUTOMATIZACIONES de la barra lateral), y toda la funcionalidad —disparadores, sintaxis de programación, encadenamiento, la pantalla de inyección obligatoria, el historial de ejecuciones y dónde persisten las automatizaciones— está documentada en Automatizaciones. Esta sección cubre solo la superficie del plano de control que la funcionalidad expone: controlar las automatizaciones a través de la API, responder a los prompts de decisión que una ejecución desatendida puede plantear y cómo funciona el consentimiento sobre una terminal conectada.

Controlar las automatizaciones a través de la API

Toda la funcionalidad se refleja en el socket de control para el cliente enriquecido:

Responder a los prompts pendientes

Algunas decisiones de ciclo de vida —una ampliación de almacenamiento, un restablecimiento por desviación, un borrado por compromiso— normalmente aparecen como un aviso local. Cuando las dispara un cliente enriquecido remoto en su lugar, se ponen en cola en vez de mostrarse en el anfitrión: aparecen en GET /state bajo pendingPrompts (cada uno con un id, profileID, title, message y etiquetas de botón) y se responden con POST /prompts/<id>/answer:

SOCK="$HOME/Library/Application Support/BromureAC/control.sock"
curl --unix-socket "$SOCK" -X POST http://localhost/prompts/PROMPT_ID/answer \
  -d '{"choice":"Upgrade"}'

Pasa como choice una de las propias etiquetas de botón del prompt. Si ningún cliente responde en 180 segundos, el prompt se resuelve con su alternativa segura (cancelar / ahora no — nunca la opción destructiva); si ningún cliente ha sondeado /state en 10 segundos, recurre a la alternativa de inmediato. Estas rutas son solo del socket de control. Un cliente enriquecido muestra estos prompts como avisos locales corrientes.

Consentimiento en terminales adjuntas

Mientras una terminal está conectada interactivamente a una sesión —mediante vm exec -it, vm attach o una conexión SSH— los avisos de aprobación del lado del anfitrión (uso de credenciales y similares) se muestran en tu terminal, no dentro del invitado. El aviso dice 🔒 Bromure — se requiere aprobación con opciones numeradas y Choice [1-N] (Enter or timeout = deny). Enter, tiempo de espera, EOF o desconectarse significan todos denegar, de modo que un invitado comprometido nunca puede falsificar una aprobación. El tmux del invitado se vuelve a pintar después.

Endpoints de depuración (BROMURE_DEBUG_CLAUDE)

Iniciar la app con BROMURE_DEBUG_CLAUDE establecido desbloquea rutas adicionales en la API de automatización TCP y levanta la puerta de depuración sobre el control de VM:

• POST /sessions/<id>/exec y las rutas de control /vms/… sin el socket de control.
• GET /app/state.
• GET /debug/ui-shot?path=…&which=unified|picker|editor — la app renderiza su propia ventana en un PNG (sin necesidad del permiso de Grabación de pantalla) y devuelve un volcado de marcos de subvistas; la salida predeterminada es /tmp/bromure-ui-shot.png.
• POST /debug/editor — controla el editor de ajustes para la herramienta de captura de pantalla.
• POST /detect/prompt-injection — ejecuta los detectores reales y devuelve su veredicto (esta ruta requiere el flag de depuración incluso en el socket de control).

El flag también permite que los secretos viajen tal cual a través de los puentes de JSON de perfil de AppleScript y MCP, y lo requieren las herramientas de VM de bromure-cli mcp --debug. GET /health informa debugEnabled para que puedas saber en qué modo está la app.

Advertencia: BROMURE_DEBUG_CLAUDE elimina la puerta de seguridad que normalmente mantiene exec, el control de VM y los secretos de perfil en crudo fuera de la API TCP de loopback. Ejecuta la app con él solo en una máquina que controles, y nunca lo combines con una dirección de enlace fuera de loopback — hacerlo expondría el acceso completo al shell de la VM, secretos sin redactar y capturas de ventana a cualquiera que pueda alcanzar el puerto. Es distinto de BROMURE_AC_DEBUG (registro de eventos por stderr) y BROMURE_CLI_DEBUG (diagnósticos del socket de la CLI), que son interruptores de registro inofensivos. Los endpoints de depuración, todas las variables de entorno y cada ubicación de archivo mencionada en este capítulo están catalogados en el Apéndice.