Paseo : piloter Claude Code, Codex et vos agents IA à distance

Faire tourner un agent n'est plus le problème

Lancer Claude Code ou Codex dans un terminal, c'est facile. Le laisser travailler pendant vingt minutes, répondre à une demande de permission, vérifier son diff puis lui confier la suite depuis un autre appareil, nettement moins.

On finit donc avec plusieurs terminaux ouverts, des sessions qu'on n'ose plus fermer et un téléphone qui ne sert qu'à vérifier si le train a encore du retard. Un grand progrès technique.

Paseo s'attaque précisément à cette couche oubliée. Ce n'est ni un nouveau modèle, ni un agent supplémentaire. C'est un plan de contrôle pour les agents de code qui tournent déjà sur vos machines. Claude Code, Codex, Copilot, OpenCode et Pi passent par la même interface, accessible depuis le bureau, le web, le terminal ou un téléphone.

La promesse est séduisante. Mais le vrai intérêt de Paseo ne tient pas à son application mobile. Il tient à son architecture locale, à l'isolation des tâches et à la façon dont le réseau reste optionnel.

Ce que Paseo ajoute réellement

Paseo sépare le lieu où l'agent s'exécute de celui où vous le pilotez.

Le daemonService local exécuté en arrière-plan. Il reçoit les commandes des clients et gère le cycle de vie des agents est la pièce centrale. L'application desktop le démarre automatiquement. Sur une machine sans interface graphique, le CLI suffit :

npm install -g @getpaseo/cli
paseo

Le daemon lance ensuite chaque fournisseur comme un sous-processus. Paseo ne remplace pas l'authentification de Claude Code ou de Codex et ne récupère pas leurs clés API. Les agents continuent à parler à leurs propres services comme ils le feraient depuis un terminal classique.

Cette nuance compte. « Local-first » ne signifie pas que le modèle d'IA tourne chez vous. Cela signifie que le code, les processus et le contrôle restent sur la machine où vous avez installé les agents. Les appels aux modèles suivent toujours la configuration du fournisseur choisi.

Une interface, plusieurs agents

Le premier bénéfice est assez évident : les sessions ne dépendent plus d'une fenêtre de terminal. On peut lancer une tâche, consulter sa progression, répondre à l'agent puis reprendre la conversation depuis un autre client.

Le CLI permet aussi d'automatiser ce cycle :

paseo run --provider codex/gpt-5.5 --worktree feature-x "implémente la fonctionnalité X"
paseo ls
paseo attach abc123
paseo send abc123 "ajoute aussi les tests"

L'unification va plus loin que l'affichage. Les profils d'agents permettent de réutiliser un fournisseur, un modèle, un mode de raisonnement et un ensemble de fonctions. Le SDK TypeScript @getpaseo/client, officiellement pris en charge depuis la version 0.4.0, ouvre la même API aux intégrations maison.

Vous voulez déclencher une revue depuis un gestionnaire de tickets, suivre dix tâches dans un tableau de bord ou demander un second avis à un autre modèle ? Le daemon devient le point de couture. Pas besoin de réécrire une intégration pour chaque CLI.

Trois façons de relier le téléphone à la machine

Piloter un agent à distance implique de joindre le daemon. C'est ici que le choix d'architecture devient intéressant.

Le relay est désactivé au départ. Si vous l'activez, le daemon ouvre une connexion sortante et le téléphone le rejoint par son intermédiaire. D'après la documentation de sécurité, le trafic est chiffré de bout en bout après un échange de clés Curve25519, avec XSalsa20-Poly1305 pour les messages. Le relay voit encore les adresses IP, les horaires, la taille des messages et les identifiants de session. Il ne voit pas leur contenu.

Le QR code devient alors l'ancre de confiance. Quelqu'un qui récupère l'offre d'appairage peut tenter de rejoindre le daemon. Il faut le traiter comme un mot de passe, pas comme une jolie décoration à partager dans un canal public.

Avec Tailscale, le daemon écoute sur l'adresse du réseau privé et le téléphone s'y connecte directement. C'est un bon compromis pour qui dispose déjà d'un tailnet. Sur la machine elle-même, un socket Unix permet même de supprimer complètement l'accès réseau, au prix d'un usage limité au CLI local.

Une règle ne souffre pas vraiment de débat : ne publiez pas le daemon sur 0.0.0.0 sans mot de passe, pare-feu et chiffrement du transport. Le mot de passe empêche un client non autorisé de prendre le contrôle. Il ne chiffre pas le trafic. Ce sont deux problèmes différents.

Les worktrees sont la vraie fonction de production

Contrôler plusieurs agents depuis une belle interface, c'est agréable. Les empêcher de modifier le même répertoire au même moment, c'est utile.

Paseo peut créer un worktreeRépertoire de travail Git associé à une branche distincte, tout en partageant le même dépôt et son historique par tâche. Chaque agent reçoit son propre dossier et sa propre branche. Les modifications restent séparées jusqu'à la revue ou à la fusion. La documentation des worktrees détaille leur cycle de vie et les scripts disponibles.

Le déroulé devient propre :

1. Paseo crée un workspace isolé depuis une branche de référence.
2. Les commandes de préparation installent les dépendances ou copient les fichiers locaux nécessaires.
3. Un ou plusieurs agents travaillent dans ce workspace.
4. Vous consultez le diff, exécutez les tests et décidez de fusionner.
5. L'archivage lance le nettoyage puis retire le worktree.

Un fichier paseo.json versionné avec le projet peut déclarer le setup, le teardown et les commandes habituelles :

{
  "worktree": {
    "setup": "npm ci"
  },
  "scripts": {
    "test": { "command": "npm test" },
    "web": { "command": "npm run dev", "type": "service", "port": 3000 }
  }
}

Les services peuvent recevoir un port propre à chaque worktree et passer par le proxy du daemon. Deux agents peuvent lancer deux versions de la même application sans se battre pour le port 3000. Voilà une fonction nettement plus importante que la dictée vocale, même si elle fait moins bien sur une capture d'écran.

Le piège reste classique : un worktree neuf ne contient ni dépendances ignorées, ni .env, ni cache local. Le script de setup doit reconstruire cet environnement sans distribuer plus de secrets que nécessaire. L'isolation Git ne remplace pas l'isolation du système.

La sécurité suit les permissions de l'agent

Paseo ne réduit pas les droits de Claude Code ou de Codex. Il les rend accessibles à distance.

C'est toute la différence.

Si un agent peut lire votre dossier personnel, appeler Docker ou utiliser les identifiants présents sur la machine, un client Paseo autorisé peut lui demander de le faire. L'application ajoute un plan de contrôle, pas une frontière de sécurité autour du processus.

Quelques règles deviennent obligatoires :

• limiter les volumes montés dans le conteneur aux dépôts nécessaires ;
• protéger $PASEO_HOME, qui contient l'état du daemon et peut contenir des informations sensibles ;
• utiliser un mot de passe dès que le daemon écoute ailleurs que sur localhost ;
• préférer le relay chiffré ou un VPN sur un réseau non fiable ;
• vérifier les demandes de permission au lieu de les transformer en formalité ;
• mettre le daemon à jour, surtout lorsqu'il devient un accès distant à vos outils de développement.

L'image Docker officielle exécute le daemon et les agents avec un utilisateur non root. C'est bien. Cet utilisateur peut pourtant modifier tous les dépôts présents dans ses volumes. Les montages restent la vraie limite.

Ce que la version 0.4.0 raconte du projet

La version 0.4.0, publiée le 13 août 2026, ajoute les profils d'agents, le SDK TypeScript, la recherche de fichiers, le suivi de progression et plusieurs actions sur les fichiers et dossiers. Elle corrige aussi des problèmes concrets liés au réveil de la machine, aux worktrees et au stockage mobile.

Ce n'est pas anodin. Ces corrections montrent que Paseo a dépassé la simple démonstration. Le projet rencontre désormais les problèmes d'un vrai environnement de travail : reprise après veille, état distribué entre plusieurs clients, branches périmées, caches trop gros et processus qui ne terminent pas proprement.

La version reste jeune. La 0.4.0 supprime par exemple les commandes paseo chat et paseo loop. L'interface et les conventions peuvent encore bouger. Pour un usage personnel ou une petite équipe technique, c'est acceptable. Pour un déploiement encadré dans une grande organisation, il faut versionner la configuration, tester les mises à jour et prévoir le retour arrière.

Le projet est publié sous licence AGPL-3.0. C'est favorable à l'auto-hébergement. Une organisation qui modifie le service et l'expose sur un réseau doit néanmoins comprendre les obligations de cette licence. « Open source » n'est pas synonyme de « aucune question juridique ».

Faut-il installer Paseo ?

Le test est simple : si votre problème est la qualité du code produit par l'agent, Paseo ne le résout pas. Si votre problème est de lancer, isoler, suivre et reprendre plusieurs agents sans vivre dans six terminaux, il vise exactement la bonne couche.

Pour conclure

Paseo transforme les agents de code en processus pilotables, sans déplacer leur environnement vers un service central. Le daemon reste près des dépôts, les fournisseurs gardent leur propre authentification et les clients viennent simplement prendre le contrôle.

Son meilleur argument n'est pas « codez depuis votre téléphone ». C'est la séparation entre l'exécution, le contrôle et le transport. Ajoutez les worktrees, les scripts de projet et le SDK, et vous obtenez une base crédible pour orchestrer des agents sur vos propres machines.

Le coût réel se trouve ailleurs : sécuriser l'accès, limiter les permissions, préparer des worktrees reproductibles et accepter le rythme d'un projet encore jeune. Paseo facilite l'orchestration. Il ne supprime pas l'exploitation.

Et c'est probablement une bonne chose. Un outil qui pilote des agents capables de modifier votre code ne devrait jamais faire oublier la machine sur laquelle ils tournent.

Vous cherchez à organiser vos agents IA sans abandonner votre infrastructure ? Parlons-en.