Votre journée ressemble probablement à ceci : vous éditez un module dans Codex, et au milieu d’une réflexion vous vous demandez si le cron job de Hermes s’est déclenché aujourd’hui et ce que cette session a réellement lu cette nuit — alors vous passez à un terminal et lancez hermes --continue, ou vous ouvrez simplement une seconde fenêtre. Deux agents, deux interfaces, deux contextes, et ce qui se perd dans ce va-et-vient, c’est en général la phrase que vous alliez poser.

Un projet communautaire, hermes-chatgpt-extension, s’attaque exactement à ce coût de changement : il intègre Hermes comme un panneau dans Codex (et dans l’application de bureau Codex pour ChatGPT), de sorte que les chats, les profiles, le choix du modèle et les tâches planifiées sont visibles depuis la barre latérale de Codex.

Ce que c’est, et ce que ce n’est pas

C’est un plugin MCP : un serveur MCP stdio local (le bridge) enveloppe l’API JSON-RPC/WebSocket de bureau de Hermes et les routes REST de gestion dans une surface de plugin pour Codex. Écrit en TypeScript, sous licence MIT, créé le 30 septembre et encore mis à jour le 1er octobre.

Trois limites valent la peine d’être posées d’emblée, pour ne pas attendre la mauvaise chose :

• Cela ne transforme pas Hermes en outil de Codex. L’interface suit les conventions de chat et de barre latérale de Codex, mais Hermes fait toujours tourner son propre agent, ses outils, sa mémoire et son ordonnanceur ; la conversation Codex qui l’entoure reste distincte.
• Cela ne fournit pas d’endpoint MCP hébergé. Le serveur est en stdio local : c’est donc « utiliser Hermes dans l’application de bureau Codex », pas « atteindre votre Hermes depuis ChatGPT dans le cloud ».
• Cela ne prend pas la garde de vos identifiants. Les identifiants du fournisseur upstream restent dans le processus bridge local ; l’interface intégrée reçoit des libellés de connexion et des données de chat, pas des tokens ni des clés d’API.

Installation : deux chemins, Node 22+ dans tous les cas

Trois prérequis : Node.js 22 ou plus récent (disponible pour Codex sous le nom node), une version de bureau de Codex qui prend en charge les plugins locaux et les MCP Apps, et un backend Hermes installé et configuré qui expose l’API JSON-RPC/WebSocket de bureau ainsi que les routes REST de gestion.

Depuis le ZIP précompilé (pas de npm install, pas de build) :

# télécharger hermes-chatgpt-extension-VERSION.zip depuis la page des releases et l'extraire
cd <extracted-directory>
node scripts/verify-plugin.mjs

Le ZIP contient le serveur compilé et une interface autonome, et chaque release fournit aussi un -source.zip et un fichier SHA256SUMS pour que vous puissiez vérifier les deux. À noter : le téléchargement Source code généré automatiquement par GitHub est le build depuis les sources, pas ce paquet.

Depuis les sources :

git clone https://github.com/intellectronica/hermes-chatgpt-extension.git
cd hermes-chatgpt-extension
npm ci
npm run build
node scripts/verify-plugin.mjs

Ensuite, enregistrez-le dans le marketplace local de Codex :

node scripts/install-plugin.mjs

L’installeur copie le plugin dans ~/.codex/plugins/hermes-chatgpt-extension et ajoute une entrée dans ~/.agents/plugins/marketplace.json, en préservant un nom de marketplace existant et les entrées sans rapport. Ouvrez le lien de détail du plugin qu’il affiche et choisissez Enable dans Codex : le script n’active pas le plugin et ne redémarre pas l’application à votre place. Pour les mises à jour, lancez d’abord --replace --dry-run, puis --replace --apply.

Configuration : un seul tableau connections, quatre façons de se connecter

Gardez la configuration en dehors du répertoire du plugin pour que les mises à jour ne l’écrasent pas ; le chemin par défaut est ~/.config/hermes-chatgpt-extension/hermes.config.json :

mkdir -p "$HOME/.config/hermes-chatgpt-extension"
cp examples/config.ssh.json "$HOME/.config/hermes-chatgpt-extension/hermes.config.json"

La configuration est chargée dans un ordre fixe : l’argument --config, puis HERMES_EXTENSION_CONFIG, puis hermes.config.json dans le répertoire de travail du bridge, puis $XDG_CONFIG_HOME/hermes-chatgpt-extension/hermes.config.json (ou ~/.config/...). Une décision de conception mérite d’être saluée : un fichier explicitement sélectionné qui manque ou est invalide est une erreur, pas un élément ignoré — vous ne finissez donc jamais par croire que vous êtes sur un profile alors que vous êtes en réalité sur un autre.

Un seul tableau connections peut contenir plusieurs instances Hermes, que l’on bascule via un sélecteur dans le pied de page. Quatre modes de connexion sont pris en charge :

Mode	Quand l’utiliser	Champs clés
SSH géré	Hermes tourne sur un hôte distant ; laissez l’extension démarrer son propre backend temporaire	ssh.mode: "managed", ssh.host
Attach via SSH	Un backend compatible tourne déjà à distance ; il suffit de se connecter	ssh.mode: "attach", remotePort, tokenFile
HTTP	Un backend de bureau hermes serve compatible	baseUrl, tokenEnv
HTTPS	Un gateway derrière un reverse proxy	Idem, et les URL distantes doivent être en HTTPS

SSH géré démarre un backend loopback protégé par token sur un port alloué dynamiquement et possède ce processus ainsi que son tunnel, en arrêtant le backend à la fermeture du bridge. Il utilise votre installation Hermes existante — il n’installe aucun logiciel, ne modifie aucun profile, ne redémarre aucun service. Comme il génère son propre identifiant, ce mode interdit tokenEnv, tokenFile, remoteHost et remotePort.

Attach et HTTP/HTTPS exigent chacun exactement une source d’identifiant : tokenEnv (le nom d’une variable d’environnement) ou tokenFile (un petit fichier local). Sous POSIX, ce fichier doit appartenir à l’utilisateur courant et être réservé à son propriétaire :

chmod 600 /path/to/hermes.token

Voici le piège qui mérite son propre paragraphe : une application de bureau peut ne pas hériter des variables que vous avez exportées dans un shell interactif. Quand Codex lance le plugin, tokenEnv peut tout simplement ne pas avoir de valeur — un tokenFile aux permissions strictes est le choix le plus fiable. Les URL distantes doivent utiliser HTTPS ; le HTTP en clair n’est accepté que pour les hôtes loopback comme http://127.0.0.1:9119.

Ce que vous pouvez faire une fois activé

Après l’activation, ouvrez Explore → Hermes dans Codex :

• Chat : réponses en streaming, rendu Markdown et du code, activité des outils visible, plus Stop, approbations et questions de clarification ;
• Regroupement par profile : conversations regroupées sous des sections de profile dépliables, les brouillons restant avec l’instance et le profile auxquels ils appartiennent ;
• Modèles et effort : le vrai catalogue de modèles et les valeurs par défaut de chaque profile, avec un sélecteur de modèle et un contrôle Power pour l’effort de raisonnement ;
• Tâches planifiées : consulter les jobs et les exécutions enregistrées pour un profile ou pour tous, avec le statut de planification, d’exécution et de livraison affiché séparément — bien plus utile qu’un simple succès/échec ;
• Archivage : l’archivage passe par Hermes, avec un bref Undo, et conserve les messages stockés.

Les conversations automatisées marquées par Hermes sont masquées par défaut ; ajoutez "sidebar": { "showAutomatedChats": true } à côté de connections pour les voir. Le propre réglage de visibilité des sous-agents de Hermes s’applique toujours.

Quand c’est le bon outil

Si votre flux de travail est « Codex pour le code, Hermes pour l’automatisation », cette extension supprime les changements de fenêtre et le contexte perdu — au prix d’accepter un plugin MCP tiers installé via un marketplace local. Traitez-le comme n’importe quel plugin local : lisez le script d’installation, gardez vos fichiers de configuration et de token hors du contrôle de version et hors du paquet distribuable, et utilisez HTTPS ou SSH pour tout ce qui est distant.

Si l’OAuth distant a été votre blocage, commencez par le guide OAuth via SSH ; pour bien lire vos propres données de session et de planification, le guide de suivi des coûts et les notes sur le fuseau horaire et l’heure d’été de cron sont de bons compagnons. Pour le volet MCP de la mécanique, la référence des commandes MCP est la lecture systématique.

La version courte

Mettre deux agents dans une seule fenêtre vaut plus qu’un changement évité : cela signifie que vous voyez le côté automatisation pendant que vous êtes encore dans le code — le job a-t-il tourné, que s’est-il passé dans la session, quel modèle ce profile utilise. Cette extension relie les choses plutôt que de les réinventer ; elle ne change pas le comportement de Hermes, elle ne fait qu’exposer des interfaces qui existent déjà. Pour les utilisateurs multi-instance et multi-profile, elle rend en plus explicite la question « à laquelle suis-je réellement connecté ? » : une connexion par instance, un groupe par profile. L’isolation visible l’emporte sur une convention qu’il faut retenir.