CLI, automatisation et MCP

Tout ce que vous pouvez faire dans l'application, vous pouvez aussi le faire sans fenêtre. Le même binaire qui héberge l'interface graphique — bromure-cli, dans Bromure Agentic Coding.app/Contents/MacOS/ — est à la fois une CLI multi-commandes complète, un plan de contrôle HTTP, deux serveurs MCP, un dictionnaire AppleScript et un planificateur. Ce chapitre en est la référence.

Quatre surfaces d'automatisation reposent sur un plan de contrôle unique :

• La ligne de commande bromure-cli — une CLI de style Docker/kubectl pour créer des espaces de travail, démarrer des VM, attacher des terminaux, exécuter des commandes et lire les traces.
• L'API d'automatisation — le même plan de contrôle exposé en JSON-sur-HTTP sur l'interface loopback, pour le scripting depuis n'importe quel langage.
• Les serveurs MCP — un serveur stdio qui permet à un agent IA (Claude Code, Claude Desktop) de gérer l'application, et un serveur browser qui permet à un agent de piloter le Chromium intégré de son espace de travail.
• AppleScript — le dictionnaire Bromure AC Suite, pour le scripting macOS et l'outillage de capture d'écran.

Les automatisations planifiées — des exécutions d'agent récurrentes et sans surveillance — s'appuient sur le même plan de contrôle et sont traitées à la fin du chapitre.

Le plan de contrôle : socket et API

Chacune de ces surfaces parle en fin de compte HTTP à l'application en cours d'exécution via l'un de deux transports :

La CLI ne parle jamais directement à une VM. Chaque sous-commande est un client HTTP léger sur le socket de contrôle, de sorte que les mêmes commandes fonctionnent localement et — lorsque le socket est tunnelé via SSH — sur une instance distante depuis un client riche. Si aucun agent ne s'exécute lorsque vous invoquez une commande qui en nécessite un, la CLI démarre automatiquement un agent d'arrière-plan sans fenêtre (bromure-cli run --headless) et attend jusqu'à 40 secondes qu'il réponde à /health. Les commandes en lecture seule (vm ls, describe, trace …) ne déclenchent pas de démarrage automatique ; elles affichent No bromure-cli agent running. à la place.

Remarque : Le socket de contrôle est toujours disponible tant que l'application s'exécute et est indépendant du commutateur Activer le serveur d'automatisation. Ce commutateur ne régit que l'écouteur TCP sur le port 9223. Vous n'avez pas besoin d'activer l'API d'automatisation pour utiliser la CLI bromure-cli.

La ligne de commande bromure-cli

Vous pouvez appeler le binaire par son chemin de bundle complet, mais l'application propose une installation unique d'un alias court. Au lancement, elle affiche une alerte — Installer l'outil en ligne de commande « bromure-cli » ? — avec les boutons Installer / Pas maintenant / Ne plus demander. Choisir Installer crée un lien symbolique de /usr/local/bin/bromure-cli vers le binaire de l'application (une seule invite d'administrateur). Sous le nom bromure-cli, le binaire masque les commandes internes à l'application — la gestion des images, le serveur mcp et le run par défaut de l'interface graphique — et n'expose que les groupes destinés au terminal (Espaces de travail, Traçage, Inférence locale, Entreprise, remote) ; un bromure-cli seul affiche l'aide au lieu de lancer l'application. Invoqué en tant que bromure-cli, tout est disponible et la sous-commande par défaut est run (l'interface graphique). Les exemples ci-dessous utilisent bromure-cli ; substituez librement bromure-cli pour les commandes qu'il expose.

Les commandes acceptent un id d'espace de travail, un préfixe de short-id ou son nom partout où un argument d'espace de travail est indiqué. Les espaces de travail sont les configurations de VM persistantes décrites dans Espaces de travail ; les groupes de commandes vm et workspaces sont des alias l'un de l'autre.

L'application et l'agent d'arrière-plan

Gestion des images

L'image de base est installée une seule fois. Ces commandes sont masquées sous l'alias bromure-cli.

Remarque : Il n'existe pas de sous-commande setup — celle-ci appartient au produit frère Bromure (navigateur). La commande d'installation de l'image d'Agentic Coding est init. Si aucune image de base n'existe, le lancement de l'interface graphique vous dirige plutôt vers le flux de configuration intégré.

Contrôle des espaces de travail et des VM

C'est le groupe principal. vm run est délibérément calqué sur Docker : il démarre un espace de travail et confie votre terminal à la session tmux bromure partagée de l'invité.

Quelques détails opérationnels utiles à connaître :

• Options de vm run. --tool est claude, codex ou grok ; --auth est token, subscription ou bedrock. -v/--volume <hostdir> monte un dossier de l'hôte à ~/<basename> dans l'invité (répétable, jusqu'à 8). -d/--detach démarre la VM et rend la main au lieu de s'attacher. --rm supprime l'espace de travail et son disque à l'arrêt de la VM. Détachez-vous d'un tmux attaché avec Ctrl-b d — cela laisse la VM en cours d'exécution.
• Sensible au TTY. Le comportement par défaut de style Docker consistant à confier le terminal à tmux ne s'applique que sur un terminal réel ; les invocations redirigées ou scriptées se comportent silencieusement comme si vous aviez passé -d.
• Auth de workspaces create. Pour create, --auth accepte aussi local. Les couleurs sont blue, red, green, orange, purple, pink, teal ou gray.
• Conservation via champ vide à l'édition. workspaces edit exporte toute la configuration avec les secrets vidés ; un document réenregistré avec un secret vide conserve la valeur stockée, de sorte qu'un aller-retour ne peut jamais effacer vos clés. Un tampon inchangé n'enregistre rien ; un JSON invalide interrompt l'opération.
• Attentes de exec. vm exec attend jusqu'à 10 secondes l'agent shell de l'invité ; un 502 signifie que la VM n'est peut-être pas en cours d'exécution ou que le nom ne correspondait pas. Les invites d'approbation qui se déclenchent pendant une session attachée sont affichées sur votre terminal (voir Consentement sur les terminaux attachés), jamais à l'intérieur de l'invité.

Modèles, routage et Fusion

L'inférence locale est traitée en profondeur dans Modèles locaux et la synthèse multi-modèles dans Fusion ; les commutateurs de la CLI sont :

fusion accepte également on/engage et off/disengage comme synonymes.

Inspection des traces

Celles-ci lisent les traces de session MITM par espace de travail. Elles ne renvoient rien tant que le traçage n'est pas activé pour l'espace de travail — voir Paramètres de traçage — et le détail complet figure dans Traçage.

Accès à distance

La porte d'entrée SSH optionnelle est désactivée par défaut et entièrement documentée dans Accès à distance. Toutes les opérations passent par l'application en cours d'exécution via le socket de contrôle.

Inscription en entreprise

Contreparties CLI de la feuille S'inscrire dans bromure.io…, pour le provisionnement scripté d'appareils. Voir Entreprise.

Commandes d'intégration et internes

L'interface TUI distante (__remote-menu)

Lorsque l'accès distant SSH est activé, chaque connexion distante est forcée (via ForceCommand) vers une interface terminal ANSI artisanale plutôt qu'un shell — un mini-shell en écran alternatif, 256 couleurs, piloté par les touches fléchées et les chiffres, qui fonctionne sur n'importe quel PTY SSH (utilisez ssh -t). Elle reflète toute la CLI sous forme de menus :

• Espaces de travail — création via un formulaire sur un seul écran (Nom, Outil, Auth, Clé API, Mémoire, Couleur, Dossiers, Générer SSH, Paramètres complets…, Créer), actions par espace de travail (Attacher, Nouvel onglet, Décrire, Configurer…, Fusion, Routage, Worktrees…, Redémarrer…, Suspendre, Tuer pour les espaces de travail en cours d'exécution ; Démarrer, Décrire, Configurer…, Supprimer pour ceux à l'arrêt) et une vue en tableau brut. Configurer… reproduit nativement chaque volet d'éditeur de l'interface graphique.
• Modèles — les modèles installés et le catalogue de téléchargement ; sélectionner un modèle non installé propose de le récupérer via model pull en ligne avec progression en direct.
• Trace — Résumé / Noms d'hôtes / Fuites / Récentes / Effacer.

Pendant que vous êtes attaché au tmux d'un espace de travail, un raccourci magique (par défaut Ctrl-], indiqué dans la bannière) fait apparaître une superposition de contrôle dessinée par l'hôte : une arborescence d'onglets, Nouvel onglet, Worktrees…, Fusion, Routage, Modifier les paramètres…, Redémarrer…, Suspendre, Déconnecter. L'invité ne voit jamais la touche de déclenchement — remplacez-la avec le fichier remote/overlay-key ou $BROMURE_OVERLAY_KEY. Ctrl-b d déconnecte de tmux et revient au menu. Le récit complet du distant et du client riche, y compris la superposition et la configuration de la connexion, figure dans Accès à distance.

L'API d'automatisation en loopback

Le plan de contrôle est également exposable en JSON-sur-HTTP sur TCP pour le scripting depuis n'importe quel langage. Il est désactivé par défaut.

L'activer

Ouvrez Bromure → Préférences → Automatisation — le volet Serveur d'automatisation et serveur MCP.

1. Activez Activer le serveur d'automatisation. Lorsqu'il est activé, le volet affiche Écoute sur 127.0.0.1:9223 ; le désactiver arrête le serveur immédiatement.
2. Définissez éventuellement le Port (le champ est légendé (défaut : 9223)) et l'Adresse de liaison (défaut 127.0.0.1). Le port et l'adresse de liaison prennent effet au prochain démarrage du serveur — désactivez puis réactivez le commutateur pour les appliquer maintenant.

Vous pouvez aussi actionner le commutateur sans l'interface graphique :

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

Avertissement : Définir l'Adresse de liaison sur autre chose que 127.0.0.1 expose l'API — et le serveur MCP qu'elle soutient — au réseau, et le volet avertit Une liaison non-loopback expose l'API au réseau. Le serveur MCP n'a pas d'authentification. Il n'y a aucune authentification sur l'écouteur TCP au-delà de la frontière loopback et du contrôle BROMURE_DEBUG_CLAUDE ci-dessous. Laissez l'adresse de liaison sur loopback à moins d'avoir une raison spécifique et de confiance de ne pas le faire.

Modèle d'authentification

L'écouteur TCP et le socket de contrôle servent les mêmes routes, mais avec des accès différents :

Autrement dit : le socket de contrôle est la voie à accès complet, réservée au propriétaire ; l'API TCP ouvre le sous-ensemble sûr sur loopback et protège les routes puissantes derrière l'indicateur de débogage. Les segments de chemin sont encodés une seule fois en pourcentage (pour que les noms d'espaces de travail avec espaces fonctionnent) et les corps de requête jusqu'à 8 Mo sont acceptés.

Points de terminaison pour le scripting

Les routes les plus utiles :

Comme le chemin du socket de contrôle contient des espaces, capturez-le d'abord dans une 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"}'

Le sous-ensemble sûr fonctionne sur l'API TCP une fois que vous l'avez activée — par exemple, lister et ouvrir des sessions ne nécessite aucun indicateur de débogage :

# 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"}'

Remarque : GET /vms (liste des VM en cours d'exécution) est disponible sur l'API d'automatisation TCP sans aucun indicateur de débogage. Les routes de mutation des VM — POST /vms (démarrer une VM) et POST /vms/<id>/exec — nécessitent BROMURE_DEBUG_CLAUDE sur TCP ; pilotez-les via le socket de contrôle (comme ci-dessus) lorsque vous ne voulez pas exécuter l'application en mode débogage. La surface complète des points de terminaison — y compris les actions de worktree et d'onglet, /trace, /remote et les routes miroir du client riche — est résumée dans l'Annexe.

Le serveur MCP d'AC (bromure-cli mcp)

bromure-cli mcp exécute un serveur MCP JSON-RPC sur stdio (nom du serveur bromure-cli) qui permet à un outil IA de gérer l'application. Il enveloppe l'API HTTP d'automatisation et AppleScript, alors activez d'abord le serveur d'automatisation — les outils de liste de sessions et de profils appellent l'API HTTP à --api-url (défaut http://127.0.0.1:9223).

Les outils qu'il expose :

• bromure_ac_list_profiles, bromure_ac_list_sessions
• bromure_ac_open_session (attend jusqu'à 30 secondes la fenêtre), bromure_ac_close_session
• bromure_ac_get_profile, bromure_ac_set_profile (remplacement JSON atomique, id préservé)
• bromure_ac_get_profile_setting, bromure_ac_set_profile_setting (les clés incluent name, color, comments, tool, authMode, apiKey, closeAction, memoryGB, folderPathsCount, mcpServerCount, keyboardLayoutOverride, keyRepeatDelayMs, keyRepeatRateHz)

Avec --debug (et BROMURE_DEBUG_CLAUDE défini sur l'application), il ajoute bromure_ac_app_state, bromure_ac_vm_exec, bromure_ac_vm_read_file et bromure_ac_vm_write_file.

Pour le connecter à Claude Code, ajoutez ce qui suit à ~/.config/claude-code/.mcp.json (ou l'équivalent de votre client). C'est l'extrait exact que la section Configuration du client MCP du volet des Préférences propose de copier :

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

Remarque : Les outils de profil get/set appellent osascript (AppleScript contre l'application en cours d'exécution), donc l'application graphique doit être en cours d'exécution et macOS peut demander une fois l'autorisation d'Automatisation. Le JSON de profil circule avec les secrets vidés sauf si BROMURE_DEBUG_CLAUDE est défini.

Le serveur MCP de navigateur intégré à l'espace de travail

Distinct du serveur MCP d'AC, chaque agent d'espace de travail reçoit automatiquement un serveur MCP browser — sans configuration. Il pilote le Chromium intégré de l'espace de travail, qui s'exécute dans sa propre VM jetable. Le volet MCP de l'éditeur d'espace de travail décrit les serveurs MCP propres à l'espace de travail ; le serveur de navigateur intégré est toujours présent en plus de ce que vous y ajoutez.

Le serveur expose 23 outils pour la navigation et l'inspection — browser_navigate, browser_new_tab, browser_list_tabs, browser_activate_tab, browser_close_tab, browser_back, browser_forward, browser_reload, browser_screenshot (avec une option de page complète), 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 et browser_pick_element (un sélecteur d'élément interactif de 60 secondes).

Le transport est un shim stdio Python généré, bromure-browser-mcp.py, déployé en lecture seule dans l'invité à /mnt/bromure-meta/. Il appelle l'hôte via le port vsock 5830 et se reconnecte indéfiniment en cas de coupure, de sorte que le client MCP ne retire jamais les outils. Un appel d'outil contre un navigateur fermé l'ouvre et attend le démarrage à froid. Comme le navigateur est une VM distincte, les instructions du serveur avertissent les agents d'atteindre le serveur de développement d'un espace de travail par l'IP LAN de l'espace de travail (hostname -I), jamais localhost.

Remarque : Sur un client riche, le flux browser-MCP de l'agent peut être raccordé sur un canal SSH afin qu'un agent distant pilote le volet de navigateur que vous voyez localement. Un seul relais est actif à la fois. Voir Accès à distance.

Les serveurs MCP HTTP que vous ajoutez dans l'éditeur peuvent s'authentifier via le courtier OAuth côté hôte : il effectue la découverte RFC 8414 et l'enregistrement dynamique de client RFC 7591 (en tant que Bromure AC), exécute un flux de code d'autorisation PKCE dans votre navigateur système et sert le rappel sur un écouteur loopback (ports 28500–28599). La page de succès indique Authorized — You can close this tab and return to Bromure AC. Tout le flux s'exécute sur l'hôte, de sorte que la VM ne voit jamais les véritables identifiants OAuth.

AppleScript (Bromure AC Suite)

Un dictionnaire de scripting, le Bromure AC Suite, est une troisième surface d'automatisation — utile pour l'orchestration et pour l'outillage de capture d'écran qui nécessite des ID de fenêtre. Ciblez application "Bromure Agentic Coding" depuis Script Editor ou osascript. Il couvre :

• Profils — list profiles, create ac profile <name> [color <c>] (renvoie un UUID), delete ac profile <name|uuid>, et aller-retour de document complet via get profile json / set profile json (l'ensemble du profil Codable ; id préservé ; secrets stockés fusionnés sous les champs vides).
• Paramètres par champ — get profile setting … key … / set profile setting … key … to value ….
• Fenêtres d'éditeur — open profile manager, open ac profile editor, close ac profile editor, select editor category <key>, et get editor window id / get main window id (un CGWindowID pour screencapture -l).
• Sessions — open ac session, close ac session, list ac sessions.
• État et paramètres de l'application — get app state (JSON), plus get ac app setting / set ac app setting pour les clés automation.enabled, automation.port, automation.bindAddress, remoteAccess.enabled, remoteAccess.port, remoteAccess.bindAddress, managed.serverURL et managed.acIngestURL. Définir automation.enabled actionne le serveur HTTP en direct.

Par exemple, pour ouvrir une session :

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

Remarque : Le JSON de profil circule avec les secrets nettoyés sauf si BROMURE_DEBUG_CLAUDE est défini. Définir apiKey sur une chaîne vide via set profile setting efface la clé au lieu de la conserver — contrairement au comportement de conservation par champ vide des ponts d'aller-retour JSON. Le changement de langue n'est délibérément pas scriptable ; relancez plutôt l'application avec, par exemple, -AppleLanguages "(fr)".

Automatisations planifiées

Une automatisation planifiée est une exécution d'agent récurrente et sans surveillance liée à un espace de travail : lorsqu'elle se déclenche, elle crée un nouveau worktree git et y lance l'agent choisi avec votre prompt, et l'exécution apparaît comme un onglet de worktree ordinaire. Les automatisations sont créées et gérées depuis le tableau des automatisations (⇧⌘A, ou la section AUTOMATISATIONS de la barre latérale), et l'ensemble de la fonctionnalité — déclencheurs, syntaxe de planification, chaînage, l'écran d'injection obligatoire, l'historique des exécutions et l'endroit où les automatisations persistent — est documenté dans Automatisations. Cette section ne couvre que la surface du plan de contrôle exposée par la fonctionnalité : piloter les automatisations via l'API, répondre aux invites de décision qu'une exécution sans surveillance peut soulever, et comment le consentement fonctionne sur un terminal attaché.

Contrôler les automatisations via l'API

L'ensemble de la fonctionnalité est reflété sur le socket de contrôle pour le client riche :

Répondre aux invites en attente

Certaines décisions de cycle de vie — une mise à niveau de stockage, une réinitialisation de dérive, un effacement en cas de compromission — apparaissent normalement sous forme d'alerte locale. Lorsqu'elles sont déclenchées par un client riche distant, elles sont mises en file d'attente plutôt qu'affichées sur l'hôte : elles apparaissent dans GET /state sous pendingPrompts (chacune avec un id, un profileID, un title, un message et des libellés de boutons) et on y répond avec 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"}'

Passez l'un des libellés de boutons de l'invite comme choice. Si aucun client ne répond dans les 180 secondes, l'invite se résout sur son repli sûr (annuler / pas maintenant — jamais l'option destructrice) ; si aucun client n'a interrogé /state dans les 10 secondes, elle se replie immédiatement. Ces routes sont réservées au socket de contrôle. Un client riche affiche ces invites comme des alertes locales ordinaires.

Consentement sur les terminaux attachés

Pendant qu'un terminal est attaché de manière interactive à une session — via vm exec -it, vm attach ou une attache SSH — les invites d'approbation côté hôte (utilisation d'identifiants, et similaires) sont affichées sur votre terminal, pas à l'intérieur de l'invité. L'invite indique 🔒 Bromure — approbation requise avec des choix numérotés et Choix [1-N] (Entrée ou expiration = refus). Entrée, expiration, EOF ou détachement signifient tous refus, de sorte qu'un invité compromis ne peut jamais falsifier une approbation. Le tmux de l'invité est ensuite redessiné.

Points de terminaison de débogage (BROMURE_DEBUG_CLAUDE)

Lancer l'application avec BROMURE_DEBUG_CLAUDE défini déverrouille des routes supplémentaires sur l'API d'automatisation TCP et lève le contrôle de débogage sur le contrôle des VM :

• POST /sessions/<id>/exec et les routes de contrôle /vms/… sans le socket de contrôle.
• GET /app/state.
• GET /debug/ui-shot?path=…&which=unified|picker|editor — l'application rend sa propre fenêtre en PNG (aucune autorisation d'Enregistrement de l'écran nécessaire) et renvoie un vidage des cadres de sous-vues ; la sortie par défaut est /tmp/bromure-ui-shot.png.
• POST /debug/editor — pilote l'éditeur de paramètres pour l'outil de capture d'écran.
• POST /detect/prompt-injection — exécute les véritables détecteurs et renvoie leur verdict (cette route nécessite l'indicateur de débogage même sur le socket de contrôle).

L'indicateur permet également aux secrets de circuler tels quels à travers les ponts de JSON de profil AppleScript et MCP, et est requis par les outils de VM de bromure-cli mcp --debug. GET /health signale debugEnabled pour que vous puissiez savoir dans quel mode se trouve l'application.

Avertissement : BROMURE_DEBUG_CLAUDE supprime le contrôle de sécurité qui maintient normalement exec, le contrôle des VM et les secrets bruts de profil hors de l'API TCP loopback. N'exécutez l'application avec cet indicateur que sur une machine que vous contrôlez, et ne le combinez jamais avec une adresse de liaison non-loopback — cela exposerait un accès shell complet aux VM, des secrets non expurgés et des captures de fenêtre à quiconque peut atteindre le port. Il est distinct de BROMURE_AC_DEBUG (journalisation d'événements sur stderr) et de BROMURE_CLI_DEBUG (diagnostics de socket de la CLI), qui sont des commutateurs de journalisation inoffensifs. Les points de terminaison de débogage, toutes les variables d'environnement et chaque emplacement de fichier abordé dans ce chapitre sont catalogués dans l'Annexe.