Règles
La vraie crainte n'est pas l'espace perdu, c'est le travail perdu. C'est à cela que servent les règles de Devbroom, et aucune n'est un réglage.
L'analyse ne fait que lire
L'analyse ne modifie aucun fichier. Sauf si vous réglez une règle sur « Agir seul » dans l'Entretien automatique, rien n'est touché que vous n'ayez vu dans l'aperçu et confirmé.
Chaque verdict a une raison
Aucun élément n'est Prêt ou Bloqué sans raison. Les raisons de chaque verdict sont affichées à côté de l'élément, et en ligne de commande avec --details.
Bloqué et Inconnu ne peuvent pas être sélectionnés
C'est une limite, pas une préférence. Les éléments À vérifier ne sont nettoyés qu'avec « Inclure quand même » ; en ligne de commande, c'est --include-review, qui demande une confirmation dans le terminal.
Revérifié juste avant la suppression
Quand vous appuyez sur Nettoyer, chaque élément est revérifié par rapport aux processus en cours à ce moment-là. Un élément dont le verdict ou le contenu a changé depuis l'analyse est laissé tel quel, et on vous dit pourquoi il a été ignoré.
La Corbeille d'abord
La Corbeille est le choix par défaut, et chaque élément peut être remis depuis l'Historique. Supprimer définitivement est un choix à part, que vous confirmez en maintenant son bouton ; votre organisation peut le désactiver. L'espace placé dans la Corbeille n'est pas compté comme libéré tant que vous ne l'avez pas vidée.
Worktrees : jamais --force
- Un worktree avec des modifications non commitées, ou des fichiers non suivis ou indexés, est Bloqué. Git ne le supprime pas sans
--force; Devbroom n'utilise jamais--force. - Des fichiers ignorés le rendent À vérifier, car
git worktree removeles supprime sans demander. - Les commits non poussés sur une branche restent quand le worktree est retiré ; sur un HEAD détaché, ils seraient perdus. Avant de retirer, Devbroom sauvegarde donc le HEAD sous
refs/devbroom/removed; s'il n'y arrive pas, il ne retire rien. - Il n'existe que trois actions sur les worktrees : retirer (
remove), élaguer (prune) et réparer (repair).
On ne touche pas au travail en cours
Si une session d'agent tourne dans ce dossier ou dans son parent, si un processus s'en exécute, ou si un de ses fichiers est ouvert, l'élément est Bloqué. Pour les dossiers de build, une session qui tourne dans le dossier parent le rend À vérifier.
Devbroom ne touche jamais aux processus d'une session d'agent en cours. Il demande aux processus laissés par les agents de quitter seulement si vous le demandez, et seulement après une nouvelle vérification ; jamais aux processus système ni à ceux d'autres utilisateurs.
Un nom ne suffit pas
Le nom d'un dossier, à lui seul, ne prouve rien :
| Dossier | Pour être Prêt |
|---|---|
node_modules |
Un package.json à côté |
.next |
Une configuration Next.js ou un package.json à côté |
.turbo |
Un turbo.json ou un package.json à côté |
target |
Le marqueur de Cargo à l'intérieur (CACHEDIR.TAG) |
.venv |
Un pyvenv.cfg à l'intérieur |
DerivedData |
Des fichiers Xcode à l'intérieur |
dist, build, vendor |
Un fichier de projet à côté, et un script de build qui le produit |
Sans marqueur, le dossier reste À vérifier. Il doit aussi être ignoré par git et ne contenir aucun fichier suivi par git.
La taille réelle
L'espace partagé avec d'autres dossiers par liens physiques et clones APFS (comme le fait pnpm) n'est pas compté. Le chiffre affiché est ce que la suppression libère. Les liens symboliques ne sont pas suivis, et les volumes montés sont ignorés.
La méthode de l'agent
Les bases de données et identifiants des agents ne sont jamais touchés. Quand un agent a sa propre commande de nettoyage, c'est elle qui est utilisée ou qui vous est indiquée. L'historique de Claude Code est soit supprimé avec claude purge, soit archivé : les conversations sont d'abord écrites dans une archive du dossier de Devbroom et vérifiées par rapport aux originaux, puis seulement placées dans la Corbeille ; la mémoire du projet (memory/) reste en place, et l'archive peut être rouverte depuis l'Historique. Pour les sessions Codex, c'est codex delete qui est indiqué. Les sessions des autres agents sont seulement lues.
Tout sur votre Mac
Sans compte, sans télémétrie ; rien sur vous n'est envoyé. L'app cherche les mises à jour ; si vous saisissez une licence Pro, elle l'active une fois puis la revérifie discrètement environ une fois par mois (seulement la clé de licence et le nom de votre Mac). Sans licence, la recherche de mises à jour est la seule requête réseau. Des journaux de session, elle ne retient que le nombre de tokens et le nom des modèles ; la recherche dans les sessions lit les journaux à ce moment-là, ne garde ni index ni journal, et masque dans les extraits les chaînes qui ressemblent à des secrets. Détails sur la page Confidentialité.
Dernière mise à jour : 7 octobre 2026