xsh est une CLI Go qui donne accès à X depuis le terminal. Elle lit une session déjà ouverte dans le navigateur, stocke les cookies dans sa configuration locale et évite la création d'une clé API pour démarrer. Les scripts, les exports et les agents peuvent ensuite consommer ses sorties structurées.
Le projet dépend de l'interface web de X. Les identifiants GraphQL et certains comportements peuvent changer sans préavis. xsh découvre ces endpoints, les conserve en cache et propose des commandes de diagnostic. Une automatisation qui dépend de xsh doit prévoir ce rafraîchissement.
La CLI reste utile seule. Avec un agent, le SKILL.md ajoute les règles de manipulation des données et le serveur MCP expose les outils au client compatible. Les opérations de lecture et les mutations du compte doivent rester deux chemins distincts.
Lire et exporter les données de X
Les commandes de lecture couvrent le fil, les recherches, les profils, les conversations, les signets, les listes, les messages, les tendances, les offres d'emploi et les médias. Les trois commandes suivantes donnent déjà une vue du compte et de son contenu :
xsh feed xsh search "golang" --type Latest xsh user benoitpetit --json
Le rendu du terminal convient à une lecture ponctuelle. Les formats --json, --yaml et --compact servent aux pipelines et aux agents. --compact réduit la réponse aux champs importants et évite de gonfler le contexte d'une session.
xsh feed --json | jq -r '.[].text' xsh search "golang" --type Latest --count 20 --json xsh export search "golang" --format jsonl --output results.jsonl
Les réponses paginées peuvent contenir items et un curseur. Inspecte la première sortie avant d'écrire un filtre jq qui attend un tableau. Une recherche exportée en JSONL peut ensuite alimenter une veille, une note ou un fichier de travail sans donner le moindre droit d'écriture à l'automatisation.
Installer xsh et isoler les comptes
L'installation recommandée passe par Go 1.24 ou une version plus récente :
go install github.com/benoitpetit/xsh@latest
Un script d'installation existe aussi pour Linux et macOS :
curl -fsSL https://xsh.devbyben.fr/install | bash
Les releases GitHub proposent des binaires précompilés. Le script télécharge et exécute du code distant. Consulte son contenu avant de l'utiliser dans un environnement de travail.
La première connexion cherche les cookies de session dans les navigateurs installés :
xsh auth login xsh auth status --json xsh auth whoami --json
Un navigateur précis ou un export Cookie Editor peuvent être ciblés :
xsh auth login --browser firefox xsh auth import cookies.json --account work xsh auth switch work
Les cookies donnent accès au compte. Ils ne doivent jamais finir dans un dépôt, un prompt, un export partagé ou un rapport de bug. xsh auth status et xsh auth whoami vérifient la session sans afficher ces données.
XSH_CONFIG_DIR permet d'isoler une configuration personnelle, de travail ou de test. Les commandes suivantes affichent le chemin choisi et la configuration active :
xsh config path xsh config show
Cette séparation évite de charger le mauvais compte dans un script ou dans un client MCP.
Encadrer les commandes qui modifient un compte
xsh sait publier, programmer, répondre, liker, retweeter, suivre, envoyer un message direct et modifier des listes. Ces commandes produisent un effet distant. Elles demandent un traitement différent d'une recherche ou d'un export.
xsh tweet post "Message relu avant publication"
compose prépare un fil à partir d'un fichier ou de l'entrée standard. --dry-run rend le résultat visible avant toute publication. schedule planifie une publication avec une date au format ISO ou YYYY-MM-DD HH:MM :
xsh compose --file thread.txt --dry-run xsh schedule "Un message préparé" --at "2026-04-01 09:00"
Le guide du projet qualifie ces commandes de mutations. Une confirmation explicite doit précéder une publication, un message direct, une action sociale ou une modification de liste. Le texte peut être préparé, relu et enregistré dans un fichier. La commande qui envoie l'action doit rester visible et volontaire.
Donner un cadre précis à un agent
Un agent qui voit une liste d'outils ne connaît pas forcément leurs conséquences. Le SKILL.md du projet lui indique de commencer par la lecture, d'utiliser JSON ou le format compact lorsque la sortie doit être filtrée, puis de vérifier handles, curseurs et identifiants.
Cette consigne bloque les mutations dans une session de veille :
Utilise xsh uniquement pour lire et analyser le compte demandé. Commence par xsh auth status --json et xsh status --json. Utilise --json ou --compact pour toutes les sorties que tu dois filtrer. Ne publie rien, ne like rien, ne suis aucun compte et n'envoie aucun message. Présente les actions qui modifieraient le compte avant de les exécuter.
Le skill évite de répéter les mêmes garde-fous dans chaque prompt. La CLI reste disponible pour les flux longs, la composition, la maintenance des endpoints et les scénarios multi-comptes.
Exposer xsh via MCP
Le serveur MCP utilise le transport stdio. Un client compatible le démarre avec la commande suivante :
xsh mcp
Dans Claude Desktop, la configuration minimale ressemble à ceci :
{ "mcpServers": { "xsh": { "command": "xsh", "args": ["mcp"] } } }
Pour un compte nommé, l'option vient après la sous-commande :
{ "mcpServers": { "xsh": { "command": "xsh", "args": ["mcp", "--account", "work"] } } }
Le serveur expose les domaines de la CLI : fils, recherche, profils, signets, listes, messages, tendances, offres d'emploi, médias et certaines actions sociales. Cette liste dépend de la version installée. Un client MCP doit interroger les outils disponibles au démarrage au lieu de réutiliser un inventaire figé.
L'état local du compte et des endpoints se vérifie avec :
xsh auth status --json xsh status --json xsh doctor --json
Un agent peut ensuite rechercher, exporter et classer les résultats. Un fichier JSONL, une liste de liens ou un brouillon restent des artefacts locaux. Les commandes xsh tweet post, xsh dm send et xsh schedule ne doivent être construites qu'après la validation du contenu et de la cible.
Maintenir les endpoints de X
xsh utilise les endpoints GraphQL du client web de X. Il découvre leurs identifiants, les met en cache et isole les opérations qui échouent de façon définitive. Une commande qui fonctionnait la veille peut demander un rafraîchissement :
xsh endpoints status --json xsh endpoints list --json xsh endpoints refresh --json xsh auto-update --dry-run
Si la découverte échoue, vérifie la session puis lance le rafraîchissement en mode verbeux :
xsh auth status xsh endpoints refresh --verbose
Le rafraîchissement sert à maintenir la CLI. Il ne publie rien, n'exécute aucune action sociale et ne rejoue pas automatiquement une opération d'écriture après un endpoint périmé.
La stabilité de xsh reste liée à l'interface web de X. Pour un usage commercial ou soumis à des conditions strictes de la plateforme, l'API officielle doit être évaluée. xsh répond à un autre besoin : travailler à partir d'une session locale, de scripts et de sorties structurées sans créer une clé API pour chaque expérimentation.
Une CLI utilisable par un humain et un agent
feed, search, export et compose couvrent le travail quotidien dans le terminal. Le skill fournit les règles à un agent, puis MCP donne accès aux fonctions disponibles dans une session compatible. Les commandes de lecture peuvent être automatisées, tandis que les mutations restent soumises à une validation explicite.
Le code est disponible sur GitHub. La documentation et les binaires sont regroupés sur xsh.devbyben.fr. xsh feed --json reste une bonne première commande pour observer la structure des réponses avant de connecter une automatisation.
Article co-écrit avec l'IA · Images générées avec l'IA.