HAPI : piloter Claude Code, Codex et Gemini localement depuis le web, mobile et Telegram

https://hapi.run/

https://github.com/tiann/hapi

📌 HAPI transforme une session d’agent IA locale en espace de travail accessible à distance sans casser les habitudes de terminal, avec continuité de contexte entre desktop, navigateur et smartphone. L’outil sert à démarrer une session sur la machine principale, la reprendre en déplacement, valider des actions sensibles depuis le téléphone et revenir au poste initial sans redémarrer la boucle de travail.

Le point fort de HAPI est d’encapsuler les agents existants au lieu d’imposer une nouvelle interface fermée. Une session Claude Code, Codex, Gemini, Cursor Agent ou OpenCode peut rester dans son environnement natif, puis être exposée via un hub qui relaie l’accès en web app, PWA ou mini-app Telegram. Cette approche évite la fragmentation entre plusieurs fronts et limite les pertes de temps liées aux migrations de contexte. Concrètement, un prompt lancé en local peut être suivi à distance, approuvé sur mobile, puis repris dans le même flux terminal.

Dans un usage quotidien, HAPI répond à un problème fréquent: les sessions longues ne coïncident pas avec la présence continue devant l’ordinateur. Quand une commande, un diff ou une action d’édition attend une validation, la session reste active et l’autorisation peut partir depuis le téléphone. Cette continuité réduit les interruptions et accélère les itérations, surtout sur les tâches où l’agent alterne exécution automatique et confirmations manuelles.

L’architecture met l’accent sur un modèle local-first. La machine qui exécute l’agent reste la source principale, et l’accès distant repose sur un relais chiffré de bout en bout. Le relais combine WireGuard et TLS pour sécuriser les échanges entre appareil client et machine hôte. Pour les contextes qui demandent un contrôle réseau différent, HAPI peut aussi fonctionner avec des options d’auto-hébergement comme Cloudflare Tunnel ou Tailscale. Cette flexibilité permet de l’adapter aussi bien à un setup personnel qu’à un environnement plus strict en matière d’accès.

Le démarrage est rapide: une commande lance le hub avec relais, une autre démarre l’agent via le wrapper HAPI. Le terminal renvoie ensuite une URL et un QR code à scanner pour ouvrir l’interface distante. Le mécanisme est pratique parce qu’il n’exige pas de reconstruire son workflow autour d’un nouveau produit. Les raccourcis terminal, les habitudes de session et les commandes restent identiques, avec une couche d’accès à distance ajoutée au-dessus.

HAPI ne se limite pas au contrôle texte. Le produit intègre aussi une commande vocale, utile quand il faut piloter une session sans clavier disponible. Le mode voix peut servir à déclencher des actions courtes, demander un statut d’exécution ou valider un enchaînement pendant un déplacement. Ce n’est pas un gadget isolé, mais un complément pour maintenir le rythme d’exécution de l’agent dans des moments où l’interaction clavier/souris est impossible.

points clés

• 📱 Continuité desktop-mobile: une session locale peut être suivie et approuvée depuis le téléphone sans redémarrage.
• 🔒 Local-first chiffré: relais E2E avec WireGuard + TLS pour transporter les interactions de manière sécurisée.
• 🤖 Multi-agents: compatibilité avec plusieurs agents (Claude Code, Codex, Gemini, Cursor Agent, OpenCode) dans un flux unique.
• 🌐 Interfaces multiples: accès via web, PWA et Telegram Mini App selon le contexte d’usage.
• 🎤 Contrôle vocal: pilotage mains libres pour garder une session active hors poste fixe.

Sur la partie exécution, HAPI se place comme une couche d’orchestration et de transport plutôt qu’un remplacement du runtime agent. Cela a deux conséquences utiles. D’abord, l’outil reste proche des comportements attendus par les utilisateurs de CLI avancés, ce qui réduit fortement le coût d’adoption. Ensuite, il devient plus simple de faire cohabiter plusieurs moteurs IA, chaque moteur conservant ses forces, tout en unifiant l’accès distant et les validations.

Pour un usage individuel, HAPI convient bien aux cycles où la valeur vient de l’enchaînement rapide: prototypage d’outils, correction de bugs, itérations sur prompts système, génération de scripts d’automatisation, revue de sorties longues, ou suivi de jobs qui durent. Pour un usage collaboratif, la logique de handoff facilite la passation entre moments synchrones et asynchrones, sans reconstruire l’état de la session à chaque reprise.

Les prérequis techniques sont raisonnables: environnement Node/Bun selon la cible d’exécution, machine locale capable d’exécuter l’agent choisi, et connectivité réseau pour le relais distant. HAPI ne pousse pas un modèle IA propriétaire, donc les contraintes matérielles dépendent surtout du moteur utilisé en dessous. Avec des agents cloud, la machine locale agit surtout comme point de contrôle; avec des agents locaux, la capacité CPU/GPU/VRAM reste conditionnée par le modèle sélectionné.

Le projet est open source et propose aussi un chemin de build depuis le code source avec Bun (bun install puis bun run build:single-exe). Ce mode intéresse les profils qui veulent auditer la chaîne d’exécution, personnaliser le binaire ou intégrer HAPI dans un environnement interne. L’ouverture du code améliore la lisibilité des choix techniques et aide à fiabiliser les déploiements sur la durée.

Côté confidentialité, HAPI reste cohérent avec une approche où les données de travail demeurent pilotées depuis la machine d’origine. Le chiffrement de transport protège le flux d’accès distant, mais la discipline opérationnelle reste importante: verrouillage du poste, rotation des accès, contrôle des appareils autorisés et surveillance des sessions ouvertes. En pratique, HAPI réduit la surface d’improvisation et donne un cadre plus propre que des solutions bricolées de prise en main distante.

Au final, HAPI se distingue par une proposition très concrète: garder la puissance des agents CLI natifs, ajouter une mobilité réelle, et préserver le contexte de bout en bout. Pour toute personne qui alterne entre bureau et mobilité sans vouloir sacrifier son workflow terminal, c’est un levier direct pour augmenter la continuité d’exécution et la vitesse de décision.