Dépannage

Ce chapitre est organisé par symptôme. Chaque entrée indique la cause probable et les étapes pour y remédier. Commencez par Premier réflexe : la Chronologie, le journal et la santé — presque tous les diagnostics ci-dessous s'appuient sur l'une de ces sources — puis passez à la section qui correspond à ce que vous observez.

Deux faits sous-tendent l'essentiel de ce qui suit. D'abord, une machine (un espace de travail, dans l'éditeur de réglages) est un bac à sable persistant : son disque système (disk.img) et son dossier personnel Linux (home.img) survivent d'un lancement à l'autre, si bien qu'un problème dans l'un d'eux ne se règle pas par un simple relancement. Ensuite, Bromure Agentic Coding applique sa politique de sécurité sur l'hôte, avant que le trafic n'atteigne la VM — les blocages et erreurs qui semblent venir « de l'intérieur » de l'invité sont donc généralement le fait du proxy de l'hôte, et se résolvent dans l'application, pas dans la VM.

Premier réflexe : la Chronologie, le journal et la santé

Avant de changer quoi que ce soit, découvrez ce que l'application elle-même signale.

La Chronologie de sécurité

Ouvrez Fenêtre › Sécurité… (ou cherchez-la avec ⌘K). Elle consigne chaque décision prise par les moteurs de sécurité de Bromure pour vos agents — intermédiation et utilisation des identifiants, verdicts du pare-feu et d'OpenShell, refus du bac à sable invité, garde-fous, vérifications de chaîne d'approvisionnement, analyses d'injection de prompt, remplacements de données personnelles, messages de délégation entre agents et problèmes TLS en amont. L'enregistrement est toujours actif, survit aux redémarrages, et les événements de chaque jour sont conservés 90 jours.

La fenêtre Sécurité sur son onglet Vue d'ensemble : tuiles Dernières 24 heures pour Bloqué, Autorisés, Courtage d'identifiants, Chaîne d'approvisionnement et Protection des données personnelles, un tableau des protections de chaque machine et une liste des Derniers blocages
  • L'onglet Vue d’ensemble résume une période récente (les dernières 24 heures par défaut) — Bloqué, Autorisés, Courtage d'identifiants, Chaîne d'approvisionnement, Protection des données personnelles —, affiche les protections de chaque machine et liste les Derniers blocages. Un blocage est généralement la réponse la plus rapide à « pourquoi la requête de l'agent a-t-elle échoué ? » ; cliquez dessus pour retrouver chaque fois que c'est arrivé.
  • L'onglet Chronologie liste chaque événement. Affinez-le avec le champ Filtrer les événements… (un nom de paquet, un hôte, une machine), les filtres d'espace de travail, de période et de moteur et, lorsque vous reflétez des hôtes distants, le filtre de machine (Toutes les machines / Ce Mac / un hôte).
  • Sur une machine dotée de la sentinelle du noyau, double-cliquez sur une ligne Réseau pour voir quel prompt, quel appel d'outil et quel processus ont fait la connexion (lignée réseau).
  • Exporter… enregistre les événements — avec le filtre appliqué — dans un fichier CSV. Joignez-le à un rapport de bogue ou transmettez-le à votre équipe de sécurité.
  • Effacer ne fait que masquer les événements dans la fenêtre ; les fichiers quotidiens sur le disque sont conservés.
L'onglet Chronologie de la fenêtre Sécurité : un champ de filtre, des filtres d'espace de travail, de période et de moteur, les boutons Exporter… et Effacer, et des lignes des moteurs Protection des données personnelles, Injection de prompt, Chaîne d'approvisionnement, Pare-feu et Intermédiation d'identifiants

La fenêtre est décrite en détail dans Vue d'ensemble et chronologie de sécurité.

Le journal de l'application

L'application garde une copie de tout ce qu'elle écrit sur la sortie d'erreur standard dans ~/Library/Logs/BromureAC/bromure-ac.log, que vous l'ayez lancée depuis un terminal ou non. Chaque exécution commence par une ligne === … launch pid … qui indique le build et la version de macOS, et se termine par une ligne exit ; un plantage laisse une ligne nommant le signal fatal. Quand le fichier dépasse 8 Mo, il est renouvelé au lancement suivant, et un fichier précédent est conservé sous bromure-ac.log.1.

C'est là qu'il faut regarder quand :

  • l'état enregistré d'une machine n'a pas pu être restauré (la ligne indique ce qui a changé depuis la suspension — voir Une machine suspendue ne reprend pas là où elle s'était arrêtée) ;
  • un démarrage sans surveillance a été refusé, ou une réparation du système de fichiers a eu lieu ;
  • l'application s'est fermée de façon inattendue. Si macOS n'affiche aucun rapport de plantage, les dernières lignes du journal sont le meilleur témoignage de ce qui s'est passé. Le moteur de terminal intégré peut aussi avoir conservé des détails du plantage dans ~/Library/Caches/com.mitchellh.ghostty/sentry.

Pour voir le journal en direct, ou ajouter une sortie de débogage, lancez l'application depuis un terminal :

"/Applications/Bromure Agentic Coding.app/Contents/MacOS/bromure-ac"

Pour plus de détails, définissez une variable de débogage avant la commande (voir l'Annexe) :

  • BROMURE_AC_DEBUG=1 — débogage horodaté pour le moteur d'automatisation, les classificateurs d'injection et le pipeline de traces.
  • BROMURE_CLI_DEBUG=1 — diagnostics de connexion au socket de contrôle pour les commandes CLI.
  • BROMURE_REPAIR_DEBUG=1 — diagnostics du proxy de réparation d'inférence locale, ajoutés à /tmp/bromure-repair.log.

Le contrôle de santé

Pendant qu'elle s'exécute, l'application sert un socket de contrôle réservé au propriétaire à ~/Library/Application Support/BromureAC/control.sock. Interrogez sa santé pour confirmer que l'application est vivante et répond :

curl --unix-socket "$HOME/Library/Application Support/BromureAC/control.sock" http://localhost/health
{ "status": "ok", "service": "bromure-ac-automation", "debugEnabled": false }

Si vous avez activé le serveur d'automatisation loopback (Préférences › Automatisation, désactivé par défaut), le même point de terminaison répond sur TCP au port configuré — 9223 par défaut :

curl http://127.0.0.1:9223/health

Une connexion refusée signifie que l'application (ou son agent sans interface) ne s'exécute pas ; bromure-cli vm ls démarre l'agent d'arrière-plan à la demande et constitue un autre contrôle rapide. Voir CLI, API et MCP pour installer bromure-cli.

La console d'installation

Pendant l'installation de l'image de base — à l'étape Installation de l'assistant d'accueil, ou après Reconstruire l'image de base… — la vue de progression comporte une section repliée Sortie console qui diffuse le journal brut de l'installateur, avec un bouton Copier. Seules les 100 dernières lignes restent à l'écran : copiez le journal avant que la fenêtre ne se ferme si vous devez le joindre à un rapport.

Configuration et installation de l'image de base

Aucune machine ne peut fonctionner tant qu'il n'existe pas d'image de base Linux. Au premier lancement, l'assistant d'accueil s'ouvre sur Bienvenue dans Bromure ; cliquer sur Commencer passe à l'étape Installation, qui exécute la même installation que bromure-ac init. Le parcours complet se trouve dans Installation et premier lancement ; cette section explique quoi faire en cas d'échec.

L'étape d'accueil de l'assistant : Bienvenue dans Bromure, un bouton Commencer, et la barre d'étapes Bienvenue, Installation, Identifiants, Choix, Modèles, Terminé

Le téléchargement préconstruit échoue ou se bloque

Cause. Le chemin privilégié télécharge une image signée et compressée en gzip depuis https://dl.bromure.io, vérifie son SHA-256 et la décompresse. Une interruption réseau, un raté du CDN ou une somme de contrôle erronée l'interrompent. Le téléchargement réessaie déjà, en récupérant à nouveau le catalogue entre les tentatives (la publication hebdomadaire peut remplacer le build précédent en plein téléchargement).

Solution. Surveillez le statut et la Sortie console. En cas d'échec côté téléchargement, l'application affiche une alerte Échec du téléchargement de l’image proposant Construire localement ou Annuler :

  1. Si vous êtes en ligne et que l'échec était passager, réessayez depuis le menu de l'application : Reconstruire l'image de base… → Télécharger l'image préconstruite.
  2. Si le téléchargement ne peut pas aboutir (réseau restrictif, CDN bloqué), choisissez Construire localement pour construire l'image sur votre Mac (environ 10 minutes). Le résultat est la même image.
  3. En ligne de commande, bromure-ac init se rabat automatiquement sur la construction locale.

« Problème réseau pendant la construction de l'image de base »

Cause. La construction locale démarre une VM installateur Alpine jetable qui a besoin d'un bail DHCP et d'un accès sortant. Sur certains VPN et réseaux verrouillés, elle n'obtient aucun bail, ou ses téléchargements disparaissent dans un trou noir à cause d'une incompatibilité de MTU.

Solution. La construction s'arrête avec une alerte Problème réseau pendant la construction de l’image de base proposant Réparer et réessayer (redémarre les démons réseau de macOS — demande votre mot de passe administrateur) ou Annuler. Si l'échec persiste sur un VPN, réduisez la MTU de la carte réseau de l'invité avant de réessayer :

defaults write io.bromure.agentic-coding vm.mtu -int 1280

La MTU est déjà à 1280 par défaut ; ne l'abaissez davantage que si un chemin PMTU d'entreprise l'exige.

L'installation manque d'espace disque

Cause. Toute installation d'image exige au départ au moins 8 Go libres sur le volume qui contient le répertoire de support, et un moniteur interrompt la construction si l'espace libre vient à manquer, pour qu'elle ne se fige pas jusqu'à un délai d'expiration inexpliqué.

Correction. Libérez de l'espace et réessayez. Voir Espace disque pour savoir ce qui en consomme le plus.

L'image de base reste dans un état partiel

Cause. Annuler en cours d'installation, ou une construction échouée, laisse des fichiers transitoires : base.img.partial, base.img.gz.partial, stock.img.partial et efivars.partial dans le répertoire de support. Leur présence signifie qu'une installation est en cours ou a été interrompue. La véritable image n'est jamais remplacée qu'atomiquement, si bien qu'une image fonctionnelle existante reste utilisable tout du long.

Solution. Relancez l'installation jusqu'au bout (Reconstruire l'image de base… ou bromure-ac init). Pour repartir de zéro, bromure-ac reset supprime les fichiers de l'image de base (base.img, efivars.bin, base.version, image-state.json, ainsi que le téléchargement conservé stock.img / stock-state.json) après confirmation — il ne touche pas à vos machines. Vérifiez à tout moment ce qui est installé avec bromure-ac info.

Une image de base plus récente est disponible

Deux invites différentes peuvent apparaître :

  • Mise à jour de l’image de base disponible (au lancement) — l'application embarque, ou le catalogue publie, une image de base plus récente que celle sur le disque. Mettre à jour maintenant la télécharge (avec reconstruction locale en repli) ; Plus tard redemande au prochain lancement. L'image actuelle continue de fonctionner entre-temps.
  • Une image de base plus récente est disponible. (au démarrage d'une machine) — la base sur le disque est plus récente que celle à partir de laquelle le disque système de cette machine a été cloné. Oui, mettre à jour réinitialise le disque système de la machine sur la nouvelle base : tout ce qui a été installé dans la VM avec apt est effacé, tandis que le dossier personnel est conservé. Non garde la base actuelle jusqu'à la prochaine ; Me le rappeler plus tard redemande au premier démarrage après demain. La réponse est mémorisée par machine.

Mettre à jour l'image de base ne modifie jamais à lui seul le disque d'une machine existante ; chaque machine ne se met à niveau que lorsque vous répondez Oui, mettre à jour.

Une machine ne démarre pas, ne s'amorce pas ou ne reprend pas

Les machines sont listées sous Machines virtuelles dans la barre latérale. Le bouton ⋯ de la ligne d'une machine propose Démarrer (ou Reprendre, ou Éteindre / Suspendre / Redémarrer pendant qu'elle tourne). Avec une session sur la scène, le menu de la machine dans la barre d'outils — la pastille au nom de la machine — propose Détails de la machine : le tableau de bord avec les cartes CPU, Mémoire, Disque et Durée de fonctionnement, le résumé de la configuration et les boutons d'alimentation. Les machines sont traitées dans Machines.

Le démarrage n'aboutit jamais (« ÉCHEC DE LA PLONGÉE »)

Cause. Les machines ne sont pas préchauffées — elles démarrent à froid depuis leur disque en copie sur écriture (ou restaurent un instantané de suspension), ce qui prend quelques secondes. Si aucun terminal ne répond au bout de 30 secondes, l'écran de démarrage passe à ÉCHEC DE LA PLONGÉE : « La VM est peut-être bloquée, ou son disque système est peut-être endommagé. »

Correction.

  1. Cliquez une fois sur Continuer d’attendre — un premier démarrage après une mise à jour de l'image, ou un Mac lent, peut prendre plus de temps.
  2. Si elle ne démarre toujours pas, redémarrez la machine depuis son menu ⋯ (Redémarrer).
  3. Si un fichier défectueux sur le disque système est en cause, voir Récupérer une machine qu'un fichier défectueux empêche de démarrer, ou cliquez sur Réinitialiser le disque système… pour recloner le disque système à partir de l'image de base. Votre dossier personnel — projets, dotfiles, clés .ssh, historique du shell — est conservé ; tout ce que vous avez installé avec apt et les modifications sous /etc sont perdus.

Le démarrage d'une machine s'arrête sur une erreur de disque

Cause. Le disque système a échoué à sa vérification du système de fichiers au démarrage — généralement parce que la VM a été arrêtée en pleine écriture (fermeture forcée, plantage, coupure de courant). L'invité ne peut pas aller plus loin par lui-même.

Solution. La scène de la machine affiche ERREUR DE DISQUE — « Le disque système a échoué à la vérification du système de fichiers au démarrage, et le démarrage ne peut pas continuer. » — avec la ligne de console qui l'a déclenchée :

  1. Cliquez sur Réparer le disque. Bromure arrête la VM, rejoue le journal du disque sur le Mac avec son vérificateur intégré, puis redémarre. Rien n'est supprimé.
  2. Si le démarrage échoue de nouveau après une réparation, cliquez sur Réinitialiser le disque système… et confirmez Reset to base. Le dossier personnel est conservé.

Sur un client riche, le même choix arrive sous forme d'invite : « “‹machine›” can't boot — disk error », avec Réparer le disque / Plus tard d'abord, puis Reset System Disk / Plus tard une fois qu'une réparation a été tentée. Vous pouvez aussi lancer la réparation vous-même, machine arrêtée : bromure-cli vm fsck <machine> --repair. Voir Avancé.

Une machine suspendue ne reprend pas là où elle s'était arrêtée

Cause. La reprise restaure la RAM enregistrée (vm.state) sur le matériel virtuel exact de la machine. Lorsque la configuration a changé depuis la suspension — plus ou moins de mémoire, d'autres dossiers partagés, un nouveau build de l'application ou de l'image de base — l'état enregistré ne peut plus être restauré.

Ce qui se passe. Bromure ne laisse pas la machine coincée : quand une restauration échoue, il abandonne l'état enregistré et démarre la machine à neuf, sur le même disque et le même dossier personnel. Tous vos fichiers sont là ; seuls les programmes en cours et les terminaux ouverts de la session suspendue sont perdus. Le journal de l'application en consigne la raison, en nommant ce qui a changé — par exemple configuration changed since the suspend: memoryGB: 8 → 6 — booting fresh. Les automatisations et délégations qui démarrent une machine suspendue se comportent de la même façon.

Quelques cas voisins :

  • Dossiers partagés modifiés pendant la suspension. L'enregistrement des réglages de la machine demande Abandonner la VM suspendue pour « ‹machine› » ? — choisissez Abandonner et enregistrer ; le lancement suivant démarre à froid. Les fichiers du dossier personnel et des dossiers partagés ne sont pas touchés.
  • Réinitialiser ou effacer un disque supprime toujours l'état enregistré : un disque neuf associé à une ancienne RAM serait instantanément corrompu.
  • Builds de développement. Un état enregistré par un build de l'application ne peut souvent pas être restauré par un autre build local. Éteignez les machines, plutôt que de les suspendre, avant de changer de build.

La machine est marquée « Compromis »

Cause. Le proxy a vu l'identifiant de substitution d'une machine partir vers un hôte pour lequel il n'a pas été émis — la signature d'une exfiltration. La requête est bloquée, la VM mise en pause, et l'alerte Cet environnement est peut-être compromis liste les fuites avec quatre choix :

BoutonCe qui se passeMachine marquée comme compromise ?
Éteindre (par défaut)La VM est éteinte.Oui
BloquerSeule cette requête est refusée ; la VM reprend. Si elle réessaie, l'alerte revient.Non
AutoriserVous vous portez garant de la destination : pour le reste de cette session, l'identifiant y est substitué et envoyé, et les requêtes suivantes vers elle ne sont plus signalées.Non
Sauvegarder pour analyseVous choisissez un dossier ; Bromure y copie l'image disque et des archives du dossier personnel et des dossiers partagés, puis éteint la VM.Oui

Sur un client riche ou un Mac sans interface, l'invite propose Éteindre / Bloquer / Autoriser, et se rabat sur Éteindre si personne ne répond. Si vous avez activé Ne pas alerter en cas d'exfiltration d'identifiants dans le volet Garde-fous de la machine, aucune alerte n'apparaît : la fuite est tout de même bloquée et consignée dans la Chronologie.

Solution. Une machine marquée comme compromise affiche « Compromis — un lancement demandera l’effacement du disque et du répertoire personnel » et refuse de démarrer tant que vous n'avez pas confirmé l'effacement dans ⛔ « ‹machine› » est marqué comme compromis. Effacer et lancer supprime le disque, le dossier personnel et l'état enregistré, puis démarre une VM neuve — vos identifiants, clés SSH et réglages de la machine sont conservés. Les dossiers de projet partagés vivent hors du stockage de Bromure et ne sont pas effacés : passez-les en revue à la main pour repérer les fichiers contaminés. Une automatisation ou une délégation ne peut pas confirmer l'effacement : son démarrage est refusé avec « The workspace is marked compromised — start it yourself to confirm the wipe. ». Le modèle de détection est décrit dans Identifiants et la frontière du fil.

« The workspace did not boot in time » / « did not start in time »

Cause. Une session, une automatisation ou une tâche de code a attendu que sa machine démarre, puis a abandonné. Raisons courantes :

  • La machine n'a réellement pas réussi à démarrer — cherchez ÉCHEC DE LA PLONGÉE ou ERREUR DE DISQUE sur sa scène (voir plus haut).
  • Un démarrage sans surveillance a été refusé parce qu'il avait besoin d'une réponse de votre part. L'historique des exécutions d'automatisation affiche la raison au lieu du délai dépassé : « The workspace is marked compromised — start it yourself to confirm the wipe. » ou « “‹model›” is still downloading — the workspace can't start until it has. ».
  • Le Mac était en veille ou surchargé.

Solution. Démarrez vous-même la machine depuis son menu ⋯ et surveillez sa scène, répondez à toute invite qu'elle affiche, puis relancez la session ou l'exécution. Les invites de démarrage (mises à jour d'image, nouveaux paquets recommandés) apparaissent sous forme de feuilles sur la fenêtre principale et ne bloquent jamais le démarrage des machines.

Si une nouvelle session indique plutôt « L’agent ne s’est jamais manifesté… », la machine utilise peut-être un agent intégré plus ancien : Redémarrez-la depuis son menu ⋯ et réessayez.

Espace disque libre insuffisant

Cause. La création de tout clone en copie sur écriture ou de toute image de répertoire personnel refuse de se poursuivre avec moins de 1 Go libre sur le volume, échouant rapidement avec une erreur de disque plein plutôt que de se coincer en pleine session.

Solution. Libérez de l'espace (voir Espace disque) et redémarrez la machine.

Récupérer une machine qu'un fichier défectueux empêche de démarrer

Cause. Une mauvaise configuration écrite dans l'invité — un /etc/fstab cassé, un fichier de configuration corrompu — peut empêcher la VM de démarrer avant que vous puissiez vous connecter pour la réparer. Comme macOS ne peut pas monter l'ext4, vous ne pouvez pas simplement ouvrir le disque dans le Finder.

Solution. Utilisez le navigateur ext4 intégré, machine arrêtée :

  1. Espaces de travail › Ouvrir un fichier ext4…, puis choisissez le disk.img ou le home.img de la machine sous ~/Library/Application Support/BromureAC/profiles/<uuid>/.
  2. Parcourez jusqu'au fichier fautif. Faites un clic droit pour le Prévisualiser ou l'Extraire… vers votre Mac.
  3. Pour le corriger sur place, cliquez sur Activer la modification… (ne modifiez jamais une image qu'une VM en cours d'exécution a ouverte), puis clic droit → Remplacer… avec une copie corrigée depuis votre Mac.
  4. Si le navigateur signale que le journal doit être récupéré, cliquez d'abord sur Exécuter fsck…. Le vérificateur est intégré ; rien n'est à installer.

Si les dégâts concernent le dossier personnel — un agent a supprimé ou cassé quelque chose —, Rembobiner le dossier personnel… dans le menu ⋯ de la machine ramène le dossier personnel à l'état qu'il avait lors d'un démarrage antérieur. Voir Avancé.

Avertissement : Le remplacement sur place ne fonctionne que lorsque le nouveau contenu tient dans les blocs déjà alloués au fichier — agrandir un fichier est refusé (« That file would need to grow »). Utilisez-le pour corriger des configurations et extraire des fichiers, non pour ajouter des données.

« Réinitialiser le disque » / « Effacer le répertoire personnel… » sont grisés

Cause. Ces actions destructrices sont refusées tant que la machine tourne.

Solution. Éteignez d'abord la machine (l'info-bulle indique « Close the session window first. »), puis réessayez.

Nœuds et registres Kubernetes

Les clusters et les registres s'exécutent dans leurs propres machines, listées sous Machines virtuelles › Kubernetes et Registres. Voir Clusters Kubernetes et registres.

Un nœud ou un registre ne revient pas après une fermeture ou un Arrêt

Ce que fait Bromure. Quitter l'application suspend les nœuds de cluster et les registres, et le démarrage suivant les reprend ; un instantané qui ne se restaure pas se rabat sur un démarrage à neuf, comme pour toute machine. Un Arrêter explicite les éteint proprement, avec jusqu'à 60 secondes de délai de grâce.

Si le démarrage d'un nœud s'arrête malgré tout sur une vérification du système de fichiers, Bromure l'intercepte sur la console, arrête la VM, exécute son vérificateur intégré sur les disques système et de données du nœud et — quand cela ne suffit pas — lance le e2fsck de Linux sur eux depuis une machine jetable. Il retente le démarrage une fois ; si cela échoue aussi, le cluster affiche une erreur claire.

Solution. Consultez l'onglet Journal du cluster pour voir ce qui s'est passé. Si la réparation automatique a abandonné, redémarrez le cluster depuis son menu Actions du cluster ; en dernier recours, supprimez-le et recréez-le.

Un espace de travail ne voit pas un cluster ou un registre

Cause. L'accès se règle par machine. Une machine absente de la liste d'accès d'un cluster ou d'un registre n'obtient ni contexte ~/.kube/config ni $BROMURE_REGISTRY.

Solution. Ouvrez l'onglet Accès du cluster ou du registre (pour un cluster, aussi Actions du cluster › Accès des espaces de travail…) et ajoutez la machine. Le contexte d'un cluster est poussé dans le ~/.kube/config des machines en cours d'exécution dès que vous modifiez son accès.

Problèmes de connexion et de modèles

La conception garde les vrais identifiants hors de la VM : l'invité fonctionne avec des jetons de substitution (« factices »), et le proxy de l'hôte substitue les vrais secrets à la volée. La plupart des symptômes d'« authentification » remontent à cette frontière. Voir Identifiants et la frontière du fil et Modèles et fournisseurs.

L'agent — ou vous — voit une fausse clé d'API

Cause. C'est attendu. Les variables d'environnement telles que ANTHROPIC_API_KEY, OPENAI_API_KEY, XAI_API_KEY, GH_TOKEN, et les variables AWS à l'intérieur de la VM sont des leurres délibérés. Le proxy substitue la véritable valeur côté hôte pour les destinations autorisées, de sorte qu'un faux qui fuit ne vaut rien.

Solution. Rien — n'essayez pas de « corriger » la clé à l'intérieur de la VM. Si de vraies requêtes échouent avec une erreur d'authentification chez le fournisseur, le problème est le vrai secret sur l'hôte : saisissez à nouveau la clé d'API du fournisseur dans Préférences › Modèles (ou dans le volet Modèles propre à la machine si elle a des réglages de modèles personnalisés). Un jeton factice qui apparaît dans une requête vers le mauvais hôte déclenche la détection de compromission au lieu de s'authentifier.

Un abonnement a cessé de fonctionner (« Connexion expirée »)

Cause. Les connexions par abonnement (Claude, ChatGPT, Grok, Kimi) sont stockées chiffrées sur l'hôte, qui se charge aussi de les rafraîchir. Si le fournisseur révoque le jeton de rafraîchissement, ou si la session du compte prend fin, l'hôte ne peut plus émettre de jeton valide et toutes les sessions qui utilisent cette connexion échouent.

Correction.

  1. Ouvrez Préférences… › Modèles (⌘,). Le fournisseur affiche Connexion expirée et « ‹fournisseur› a refusé la connexion enregistrée (enregistrée ‹date›). Les sessions ne peuvent plus l’utiliser tant que vous ne vous reconnectez pas. »
  2. Cliquez sur Se reconnecter et terminez la connexion dans votre navigateur. La clé de substitution à l'intérieur des machines ne change jamais, si bien que les agents en cours récupèrent la nouvelle connexion.
  3. Si une machine échoue encore alors que les autres fonctionnent, elle a probablement sa propre connexion. Une connexion lancée depuis une machine demande Partager avec tous les espaces de travail ? — choisir Cet espace de travail uniquement donne à cette machine une connexion privée qui masque la connexion partagée. Vérifiez le volet Modèles de la machine : reconnectez-vous là, ou cliquez sur Utiliser le fournisseur global pour que la machine hérite de la connexion partagée.

Dans une conversation, un agent qui ne parvient pas à s'authentifier affiche une carte : Se connecter à ‹agent›, avec Ouvrir la page de connexion et un champ Coller le code. La ligne de la barre latérale indique « Connexion requise ». Se connecter depuis la carte capture l'identifiant sur l'hôte, exactement comme le volet Modèles.

Un agent a besoin d'un fournisseur de modèle

Cause. L'agent choisi n'a rien sur quoi tourner pour cette machine — pas de clé d'API, pas de connexion, pas de serveur personnalisé ni de modèle sur l'appareil. La conversation affiche « ‹agent› a besoin d’un fournisseur de modèle » et « ‹agent› n’a pas encore de fournisseur de modèle sur cette machine. Ajoutez une clé d’API ou un modèle local dans les réglages de la machine, puis relancez la session. »

Solution. Cliquez sur Réglages de la machine… dans la carte, ou configurez un fournisseur dans Préférences › Modèles, puis relancez la session. Sur l'écran de nouvelle session, un agent dans cet état est marqué « Se connecter au démarrage » ou « Choisir un fournisseur de modèle au démarrage ».

Un agent est bloqué sur un écran de premier lancement, de confiance ou de connexion

Cause. Les agents de codage ont leurs propres écrans de premier lancement — choix de thème, questions de confiance envers le dossier, menus de connexion — que la conversation ne peut pas afficher tels quels. Bromure répond aux écrans d'accueil avant le démarrage de l'agent et transforme le reste en cartes dans la conversation :

  • une carte de connexion pour un menu de connexion (le « Not logged in » de Claude, le choix ChatGPT de Codex, le code d'appareil de Grok, la connexion de Kimi) ;
  • Faire confiance à ce dossier et continuer quand l'agent attend que vous fassiez confiance au dossier ;
  • des cartes rouges quand l'agent n'a pas pu s'authentifier, a atteint une limite d'utilisation ou s'est arrêté sur une erreur ;
  • pour Oh My Pi, qui n'a pas de connexion propre, une carte de fournisseur qui renvoie aux réglages de la machine.

Solution. Répondez à la carte. Si la conversation semble toujours bloquée — « Réflexion… » sans que rien ne se passe —, appuyez sur Linux dans la barre d'outils (⌥⌘U) pour voir le vrai terminal de l'agent, réglez ce qui s'y affiche, puis appuyez sur Session pour revenir. « Passez dans le terminal pour régler le problème, puis renvoyez. » sur une carte signifie la même chose.

Pour Kimi Code, Bromure se connecte au service international de Kimi (kimi.ai). Une connexion Kimi faite avant ce changement peut cesser de fonctionner et afficher une carte de connexion ; reconnectez-vous.

« Échanger le jeton d'abonnement ? » continue d'apparaître, ou a été refusé par erreur

Cause. Lorsqu'un agent se connecte avec un vrai jeton à l'intérieur de la VM, le proxy le détecte et propose de le déplacer vers l'hôte pour que le vrai secret quitte l'invité. Le choix est mémorisé par machine et par fournisseur.

Solution. Dans le volet Traçage de la machine, les lignes Échange du jeton d’abonnement Claude et Échange du jeton d’abonnement Codex montrent l'état actuel avec une commande de réinitialisation — Forget swap (re-prompt next session) ou Re-enable prompt.

Réseau à l'intérieur de la VM

IPv6 ne fonctionne pas dans l'invité

Cause. C'est voulu. Le chemin réseau de l'hôte Bromure est uniquement IPv4, et un LAN qui annonce IPv6 sans sortie IPv6 fonctionnelle fait bloquer chaque résolution AAAA. Les images de base récentes désactivent IPv6 dans l'invité, et apt est forcé en IPv4 à chaque démarrage.

Solution. Utilisez des adresses IPv4 et des noms d'hôte. localhost dans l'invité se résout uniquement en 127.0.0.1.

Le sous-réseau des machines entre en conflit avec un réseau que vous utilisez

Cause. Les nouvelles installations placent leurs machines sur un /24 privé aléatoire au sein de 172.16.0.0/12 (en évitant les 172.17–172.20 habituels de Docker et toute plage sur laquelle se trouve déjà le Mac). Les installations plus anciennes peuvent encore utiliser 192.168.64.0/24. L'un comme l'autre peut entrer en conflit avec un VPN ou un réseau de bureau.

Solution. Ouvrez Préférences… › Ressources. Sous Sous-réseau de l’espace de travail, Utiliser un sous-réseau privé (évite les conflits entre instances distantes) bascule sur un sous-réseau 172.16/12 aléatoire, et Tirer au hasard en choisit un nouveau. Les changements s'appliquent au prochain démarrage de vos machines.

Le trafic d'une machine échoue sur un VPN

Cause. Les tunnels VPN réduisent la taille utile des paquets ; une MTU trop grande fait disparaître les téléchargements dans un trou noir.

Solution. La carte réseau de l'invité est déjà limitée à 1280 octets. Si un chemin d'entreprise exige moins, abaissez vm.mtu comme indiqué dans Problème réseau pendant la construction de l'image de base.

Erreurs TLS et de certificat à l'intérieur de la VM

« self-signed certificate » ou « unable to get local issuer certificate »

Cause. Tout le trafic HTTPS de l'invité est intercepté par le proxy MITM de l'hôte, qui resigne le trafic avec une autorité de certification racine propre à l'installation. Les outils à l'intérieur de la VM lui font confiance grâce aux variables d'environnement de bundle CA que Bromure définit pour node, python, go, rust, curl, deno et le SDK AWS, ainsi qu'au fichier CA installé dans le partage meta (bromure-ca.pem). Un outil qui ignore ces variables — ou un conteneur qui apporte son propre magasin de confiance — rejettera le certificat du proxy.

Correction.

  1. Pour la plupart des outils, aucune action n'est nécessaire. Si un outil précis échoue, pointez-le vers le bundle de CA exporté plutôt que de désactiver la vérification ; le fichier de CA est disponible dans l'invité et les variables standard de type *_CA_BUNDLE / SSL_CERT_FILE sont déjà exportées.
  2. Pour un conteneur Docker qui doit accéder au réseau, utilisez le commutateur Hériter des réglages du proxy HTTP de la feuille Exécuter un nouveau conteneur afin que http_proxy/https_proxy (le proxy dans l'invité à 127.0.0.1:65534) se propagent, et montez ou installez la CA là où les outils du conteneur la cherchent.
  3. Si les erreurs de certificat n'apparaissent qu'après avoir supprimé ou renouvelé la CA (ci-dessous), redémarrez les machines concernées pour que la nouvelle CA soit redéployée.

Pour un hôte qui épingle son certificat, le volet Garde-fous de la machine peut contourner l'interception pour une seule requête (X-bromure-insecure) — voir Réglages des garde-fous.

Renouveler l'autorité de certification racine

Cause / quand le faire. La clé privée du CA racine se trouve à ~/Library/Application Support/BromureAC/ca/key.pem (mode 0600) avec son certificat dans cert.pem. Vous pouvez vouloir la renouveler si vous soupçonnez que la clé a été exposée.

Solution. Quittez l'application, supprimez le répertoire ca/ et relancez — une nouvelle CA est générée et redéployée dans les machines à leur prochain démarrage. Les corps de trace déjà capturés ne sont pas affectés, mais tout invité qui avait épinglé l'ancien certificat devra faire confiance au nouveau.

Blocages de chaîne d'approvisionnement

Lorsque le npm install, le pip install ou une commande similaire d'un agent échoue avec une erreur caractéristique, c'est très probablement le pipeline de chaîne d'approvisionnement de l'hôte qui est intervenu. La politique et ses couches sont documentées dans Protection de la chaîne d'approvisionnement et dans la référence Réglages de la chaîne d'approvisionnement.

Une installation a échoué avec un HTTP 451

Cause. Un 451 (« Unavailable For Legal Reasons ») est le blocage de chaîne d'approvisionnement de Bromure — choisi pour se distinguer d'un coup d'œil du 403 qu'utilisent les Garde-fous. Le gestionnaire de paquets affiche la raison telle quelle dans sa sortie d'erreur, par exemple :

Bromure Supply-Chain Security blocked this request: npm package [email protected]
published 4 hours ago — policy requires 2 days minimum

Correction. Lisez la raison. Les déclencheurs courants et leurs remèdes :

Raison dans le messageCoucheComment procéder
« published … ago — policy requires N days »Barrière d'anciennetéÉpinglez une version plus ancienne, ou ajoutez le paquet aux paquets exemptés dans le volet Chaîne d’approvisionnement de la machine.
Une CVE / alerte au niveau de votre seuil ou au-dessusOSV ou socket.devChoisissez une version corrigée, ou augmentez le seuil Bloquer à la gravité.
Signalé comme compromis / malware / typosquatsocket.devTraitez-le comme un signal réel — vérifiez le nom du paquet avant de passer outre.

Trouver la raison dans la Chronologie

Ouvrez la Chronologie de sécurité, choisissez le moteur Chaîne d’approvisionnement et relancez l'installation. Chaque paquet vérifié apparaît sur une ligne : en vert s'il est passé, en rouge s'il a été bloqué ou retiré. Une Chronologie silencieuse pendant une installation signifie généralement que tout venait du cache — la tuile Paquets vérifiés de l'onglet Vue d'ensemble montre que des vérifications ont bien lieu.

Passer outre un blocage

Solution. Les couches de chaîne d'approvisionnement sont des commutateurs par machine, appliqués à chaud (aucun redémarrage de VM nécessaire). Pour laisser passer un paquet précis, ajoutez une exemption ou une entrée de liste d'autorisation dans le volet Chaîne d’approvisionnement, ou abaissez ou désactivez la couche concernée pour cette machine.

Chaque installation demande un consentement (hors ligne, ou socket.dev + Cargo)

Cause. Lorsque OSV ou socket.dev est activé mais ne peut produire de verdict — le réseau est coupé, ou l'écosystème n'est pas pris en charge — Bromure échoue en position fermée, retenant chaque paquet pour votre consentement plutôt que de l'autoriser silencieusement. Deux situations produisent une invite par paquet :

  • Travail hors ligne avec OSV ou socket.dev activé : chaque paquet non mis en cache est retenu.
  • socket.dev avec Cargo : socket.dev ne prend pas en charge Cargo, de sorte que chaque artefact crates.io ne donne aucun verdict.

Correction. Pour les périodes hors ligne, désactivez OSV et socket.dev — la barrière d'âge continue de fonctionner à partir des métadonnées déjà mises en cache, sans connectivité. Pour un travail Rust intensif, désactivez soit socket.dev, soit répondez aux invites (les autorisations sont indexées par package@version). Le filet de sécurité fondé sur l'heure de publication de PyPI est le seul contrôle qui échoue en position ouverte en cas de simple erreur réseau.

Faux positifs d'injection de prompt

Le détecteur d'injection de prompt analyse le contenu renvoyé à l'agent et peut journaliser, demander ou bloquer. Son comportement et son réglage sont décrits dans Détection d'injection de prompt et garde-fous et dans la référence Réglages d'injection de prompt.

Une requête légitime a été signalée ou bloquée

Cause. Le classificateur a attribué à un fragment entrant un score supérieur au seuil de la machine — une documentation de sécurité, une page qui cite une attaque ou un extrait qui ressemble à une instruction adressée à l'agent peuvent tous avoir l'allure d'une injection.

Correction.

  1. Consultez les lignes Injection de prompt de la Chronologie pour juger s'il s'agissait d'une vraie tentative.
  2. S'il s'agissait d'un faux positif et que les blocages vous gênent, passez le mode d'injection de prompt de la machine de Bloquer à Demander (vous décidez à chaque détection) ou Journal (consigner seulement, ne jamais bloquer) dans le volet Injection de prompt.
  3. Les réglages sont par machine : une machine de recherche bruyante peut tourner en mode Journal pendant qu'une machine de production reste sur Bloquer.

Les messages entre agents sont aussi analysés : un message de délégation signalé affiche « retenu — injection de prompt » et est consigné sous Délégation entre agents.

Les automatisations déclenchées par événement sont toutes bloquées

Cause. Les automatisations déclenchées par événement nécessitent le modèle PromptGuard. Sans lui, chaque exécution d'événement est bloquée avec « PromptGuard model not installed — event triggers require it (download in Settings). » C'est voulu, non un bogue.

Solution. Installez le modèle PromptGuard depuis le volet Injection de prompt. Si un commutateur de détection est activé mais que le modèle n'a pas pu être téléchargé — par exemple parce que le disque était plein —, la machine tourne sans protection et l'échec est journalisé ; téléchargez-le à nouveau une fois l'espace disponible.

Espace disque : où il passe et comment le récupérer

Ce qui consomme de l'espace

Le stockage se trouve sous ~/Library/Application Support/BromureAC/ (voir l'Annexe pour la carte complète). Les gros consommateurs :

QuoiOùTaille typique
L'image de base Ubuntubase.img24 Go logiques, quelques Go physiques
Disques système par machineprofiles/<uuid>/disk.imgClone en copie sur écriture de la base ; ne grossit qu'au fil des écritures de l'invité
Dossiers personnels par machineprofiles/<uuid>/home.imgext4 creux, 16 Go apparents par défaut, alloués à la demande
Instantanés RAM des VM suspenduesprofiles/<uuid>/vm.stateJusqu'à la RAM allouée à la machine, par machine suspendue
Points de contrôle du disque et du dossier personnelprofiles/<uuid>/checkpoints/Espace réel seulement à mesure qu'ils divergent des disques actifs
Nœuds Kubernetes, registres, connecteur de messageriekube/<id>/nodes/<uuid>/Un disque système chacun, plus un disque de données par nœud avec Longhorn (40 Go apparents par défaut) ou le Stockage des images du registre
Modèles sur l'appareilmodels/<org>--<name>/Plusieurs Go par modèle
Modèles de détectionModels/prompt-injection/, Models/claudemd-guard/Des centaines de Mo chacun
Corps de tracetraces/Plafonné : 100 Mo par session, 5 Go au total
Copies des conversationstranscripts/, task-transcripts/, runs/Grossit avec vos sessions, tâches et exécutions d'automatisation
Enregistrements des sessions, salles et délégationssessions.json, rooms.json, delegations.jsonPetits
Chronologie de sécuritésecurity-timeline/<date>.jsonlPetite ; conservée 90 jours par défaut (Préférences › Traçage › Security history)
Journal de l'application~/Library/Logs/BromureAC/Au plus environ 16 Mo (8 Mo plus un fichier renouvelé)

Remarque : La carte Disque du tableau de bord privilégie les propres chiffres df de l'invité plutôt que l'allocation du clone de l'hôte, car un clone en copie sur écriture surestime l'utilisation — les blocs libérés à l'intérieur de l'invité restent matérialisés dans le clone.

Récupérer de l'espace

  • Éteignez les machines suspendues que vous n'utilisez pas. Un arrêt complet efface vm.state ; la machine démarrera à froid la fois suivante.
  • Supprimez les modèles sur l'appareil que vous n'utilisez plus, depuis Préférences › Modèles ou avec bromure-cli model rm <id>.
  • Réinitialisez un disque système gonflé avec Réinitialiser le disque dans le menu ⋯ de la machine (reclone depuis la base, conserve le dossier personnel).
  • Effacez les traces avec bromure-cli trace clear — efface à la fois l'anneau en mémoire et les corps sur disque.
  • Supprimez les sessions dont vous n'avez plus besoin (Supprimer la session dans le menu de la ligne), et supprimez les conversations dont la machine ou le dossier a disparu avec la ligne de nettoyage de la barre latérale.
  • Supprimez une machine entière dont vous n'avez plus besoin (⋯ › Supprimer l’espace de travail, ou bromure-cli workspaces rm <workspace>), ce qui supprime son disque et son dossier personnel.
  • Supprimez les clusters et registres inutilisés depuis leurs tableaux de bord.
  • Récupérez l'image de base avec bromure-ac reset si vous voulez repartir de zéro (les machines ne sont pas touchées ; relancez init ensuite).

Accès à distance et client riche

La porte d'entrée SSH optionnelle d'accès à distance et le miroir du client riche sont traités dans Accès à distance et clients. Les symptômes ci-dessous sont ceux qui empêchent une connexion.

Impossible de se connecter via SSH (port 2222)

Cause. La porte d'entrée distante est désactivée par défaut. C'est aussi un serveur intégré (pas le sshd du système) : activer la Session à distance de macOS n'a donc aucun effet sur elle, et elle est mise en pause pendant toute installation de l'image de base.

Correction.

  1. Vérifiez l'état avec bromure-cli remote status — il indique si le serveur est activé et en cours d'exécution, l'adresse et le port d'écoute, les méthodes d'authentification, l'empreinte de la clé d'hôte, une chaîne de connexion ssh -p <port> <user>@<host> prête à l'emploi et la liste des clés autorisées.
  2. Activez-le avec bromure-cli remote enable (par défaut : port 2222, liaison 0.0.0.0, les deux méthodes d'authentification activées). Il génère une erreur si les deux méthodes d'authentification sont désactivées, si le port est inférieur à 1024, ou tant que l'image de base est absente ou en cours d'installation.
  3. Ajoutez votre clé publique avec bromure-cli remote key add <path-or-key>. Ajouter ou supprimer une clé redémarre l'écouteur et coupe les connexions actives — comportement attendu.

Non-concordance de clé d'hôte ou d'empreinte (TOFU)

Cause. Le client riche épingle la clé d'hôte de chaque hôte distant à la première connexion (confiance à la première utilisation), stockée dans ~/Library/Application Support/BromureAC/remote-client/known_hosts. L'épinglage se fait par point de terminaison (address:port), si bien que modifier l'adresse ou le port d'un hôte enregistré redéclenche à juste titre l'invite de confiance. Une non-concordance sur un point de terminaison inchangé signifie que la clé de l'hôte distant a changé — ou que quelque chose intercepte la connexion.

Correction. Si vous avez légitimement reconstruit l'hôte distant, supprimez son épinglage et reconnectez-vous pour lui refaire confiance. Si vous ne vous attendiez pas à ce que la clé change, arrêtez-vous et enquêtez avant de l'accepter.

Les Préférences distantes ne se chargent pas

Cause. Lorsqu'une fenêtre miroir est ouverte, Préférences… peut modifier les réglages d'un hôte distant (le sélecteur Réglages pour :). Il affiche « Chargement des préférences depuis ‹hôte›… » pendant la récupération, et « Impossible de charger les préférences du serveur distant » lorsque la connexion tombe ou que l'hôte distant est d'une version plus ancienne.

Solution. Vérifiez que la fenêtre miroir est connectée, puis cliquez sur Réessayer. Choisissez Ce Mac dans Réglages pour : pour modifier vos propres réglages en attendant.

Le tunnel à l'échelle du système nécessite une approbation

Cause. Le tunnel optionnel à l'échelle du système du client riche utilise un démon launchd privilégié enregistré via SMAppService. Son premier enregistrement fait apparaître une bascule d'approbation d'élément en arrière-plan.

Solution. Approuvez Bromure Agentic Coding dans Réglages Système › Général › Ouverture et extensions (l'application peut ouvrir ce volet pour vous). À travers le tunnel, un ping ICMP vers un invité distant reçoit une réponse locale et confirme le routage, pas la vivacité de l'invité.

Signaler un bogue

Lorsque vous déposez un rapport sur bromure.io, incluez suffisamment d'éléments pour qu'un mainteneur puisse reproduire le problème :

  1. Versions de l'application et de l'image — la version de l'application (depuis About Bromure Agentic Coding) et la sortie de bromure-ac info (le marqueur de version de l'image de base, les tailles et le chemin).
  2. Le journal de l'application — ~/Library/Logs/BromureAC/bromure-ac.log (et bromure-ac.log.1 si le problème a commencé avant le dernier lancement). Relancez avec BROMURE_AC_DEBUG=1 depuis un terminal si le mainteneur demande plus de détails.
  3. L'enregistrement pertinent — pour les échecs d'installation, la Sortie console copiée ; pour un comportement lié à la sécurité, un CSV filtré obtenu avec Exporter… depuis la Chronologie de sécurité.
  4. Ce que vous attendiez et ce qui s'est passé, et si la machine était éteinte, suspendue ou en cours d'exécution.

N'incluez pas de vrais secrets — les enregistrements de trace et les lignes de journal les réduisent déjà à de courts aperçus, et l'application est conçue pour que les vrais identifiants n'entrent jamais dans une VM. Si votre Mac est inscrit auprès d'un espace de travail bromure.io, faites passer vos rapports par l'administrateur de votre organisation. L'inscription est traitée dans Enterprise.