Dropstone CLI

Guide de dépannage

Diagnostiquez les problèmes de Dropstone CLI de manière systématique. Collectez les bonnes informations, trouvez les journaux et isolez la cause avant de contacter le support.

La plupart des problèmes se réduisent à l'une de quatre choses : une version obsolète, un cache périmé, des identifiants invalides ou le réseau. Cette page indique l'ordre dans lequel les vérifier, et ce qu'il faut collecter quand aucun d'entre eux n'est en cause.

Pour un message d'erreur spécifique, commencez plutôt par Problèmes courants. Pour le comportement à l'exécution et le débogage par fonctionnalité, consultez Dépannage CLI.

Trois premières choses à essayer

Exécutez ces commandes avant toute autre chose. Elles résolvent une part surprenante des signalements.

# 1. Mettez à jour
dropstone update

# 2. Voyez ce que Dropstone fait réellement
dropstone --log-level DEBUG --print-logs
  1. Si l'échec survient en cours de session et que la cause n'est pas claire, videz le cache et redémarrez :
rm -rf ~/.cache/dropstone

Sous Windows, appuyez sur WIN+R et supprimez %USERPROFILE%\.cache\dropstone.

Avant de supprimer autre chose

Les trois commandes ci-dessus sont sûres. Supprimer ~/.local/share/dropstone ne l'est pas — c'est là que se trouvent vos identifiants et l'historique de vos sessions. Consultez Où sont stockées les données avant de supprimer ce répertoire.

Où sont stockées les données

Tout ce que Dropstone conserve sur le disque se trouve dans deux répertoires.

QuoimacOS / LinuxWindows
Identifiants et sessions~/.local/share/dropstone/%USERPROFILE%\.local\share\dropstone
Journaux~/.local/share/dropstone/log/%USERPROFILE%\.local\share\dropstone\log
Cache~/.cache/dropstone/%USERPROFILE%\.cache\dropstone

Dans le répertoire de données :

  • auth.json — vos identifiants. Supprimez-le uniquement pour forcer une nouvelle connexion propre.
  • log/ — journaux horodatés. Les dix plus récents sont conservés.
  • project/ — historique des sessions, limité à chaque projet.

Un fichier de journal est nommé d'après le moment où il a été écrit, par exemple 2026-05-23T123456.log. Le plus récent est celui dont vous avez besoin.

Obtenir un journal qui vaut la peine d'être lu

Par défaut, le niveau de journalisation est discret. Deux options le modifient :

# Sortie détaillée écrite dans le fichier de journal
dropstone --log-level DEBUG

# La même sortie diffusée sur votre terminal en temps réel
dropstone --print-logs

Utilisez les deux ensemble lorsque vous voulez observer l'échec se produire tout en conservant le fichier ensuite.

Si le problème est un plantage au démarrage, --print-logs est celui qui aide : le fichier de journal peut ne pas être écrit du tout avant que le processus ne meure, mais stderr l'est toujours.

Que inclure dans un rapport

Un rapport contenant ces cinq éléments nécessite généralement une seule réponse pour être résolu. Un rapport sans eux en nécessite généralement quatre.

  1. La commande exacte que vous avez exécutée. Pas une paraphrase — la ligne littérale, options comprises.

  2. Ce que vous attendiez, et ce qui s'est passé. Les deux parties. « Ça a échoué » ne réduit en rien le champ des possibles.

  3. Votre version et votre plateforme.

    dropstone --version
    

    Plus votre système d'exploitation et sa version, et si vous êtes sous Windows natif ou dans WSL.

  4. L'extrait de journal pertinent. Quelques lignes de part et d'autre de l'erreur, pas tout le fichier. Masquez tout ce qui est sensible — les journaux de session peuvent contenir des chemins de fichiers et du code.

  5. Si le problème est reproductible. Toujours, parfois, ou une seule fois. « Parfois » vaut la peine d'être dit ; cela indique un problème de timing ou d'état plutôt qu'une mauvaise entrée.

Envoyez-le à dropstone.io/contact.

Réduire le champ des possibles

Si la cause n'est toujours pas évidente, éliminez les variables une à une. Chacune de ces étapes supprime toute une catégorie.

Est-ce le projet ? Exécutez Dropstone dans un répertoire vide. Si cela fonctionne là-bas, le problème est limité au projet — probablement un fichier de configuration, un fichier de règles, ou quelque chose dans le dépôt que l'agent lit.

Est-ce votre configuration ? Déplacez temporairement dropstone.json de côté et relancez. Consultez Configuration pour savoir où se trouvent les fichiers de configuration globaux et de projet.

Est-ce un serveur MCP ? Un serveur qui bloque au démarrage peut paralyser toute la session. Listez-les et désactivez-les, puis réactivez-les un par un :

dropstone mcp list

Est-ce le réseau ? Les proxys d'entreprise sont la cause la plus courante d'échecs qui ressemblent à autre chose. Vérifiez :

curl -I https://dropstone.io

Si cela échoue ou renvoie quelque chose d'inattendu, consultez Réseau et proxy. La solution habituelle consiste à définir HTTPS_PROXY et, surtout, NO_PROXY=localhost,127.0.0.1 — Dropstone utilise une boucle locale pendant les sessions interactives, et router cela via un proxy provoque une boucle.

Est-ce vos identifiants ? Déconnectez-vous puis reconnectez-vous :

dropstone auth logout
dropstone auth login

Est-ce le terminal ? Sous Linux, copier et coller nécessite un utilitaire de presse-papiers installé. Consultez Dépannage CLI.

Est-ce Windows ? Les accès fichiers lents, les problèmes de terminal et les problèmes de chemins sous Windows natif disparaissent généralement sous WSL. Consultez Windows et WSL.

Avant de contacter le support

Rubriques connexes

Ctrl+I