Pourquoi le code Claude semble si stable : Plongée en profondeur d'un développeur dans la conception de son stockage local

Le code Claude est omniprésent ces derniers temps. Les développeurs l'utilisent pour livrer des fonctionnalités plus rapidement, automatiser les flux de travail et prototyper des agents qui fonctionnent réellement dans des projets réels. Ce qui est encore plus surprenant, c'est le nombre de non-codeurs qui s'y sont mis aussi - construisant des outils, câblant des tâches, et obtenant des résultats utiles avec presque aucune configuration. Il est rare de voir un outil de codage de l'IA se répandre aussi rapidement à travers autant de niveaux de compétences différents.

Ce qui ressort vraiment, cependant, c'est la stabilité de l'outil. Claude Code se souvient de ce qui s'est passé d'une session à l'autre, survit aux plantages sans perdre de progrès et se comporte plus comme un outil de développement local que comme une interface de chat. Cette fiabilité vient de la façon dont il gère le stockage local.

Au lieu de traiter votre session de codage comme un chat temporaire, Claude Code lit et écrit de vrais fichiers, stocke l'état du projet sur le disque et enregistre chaque étape du travail de l'agent. Les sessions peuvent être reprises, inspectées, ou annulées sans avoir à se poser de questions, et chaque projet reste proprement isolé - évitant ainsi les problèmes de contamination croisée que rencontrent beaucoup d'outils d'agent.

Dans cet article, nous allons examiner de plus près l'architecture de stockage qui sous-tend cette stabilité, et pourquoi elle joue un rôle si important dans le fait que Claude Code semble pratique pour le développement quotidien.

Défis auxquels chaque assistant de codage d'IA locale est confronté

Avant d'expliquer comment Claude Code aborde le stockage, jetons un coup d'œil aux problèmes courants que les outils de codage d'IA locale ont tendance à rencontrer. Ces problèmes apparaissent naturellement lorsqu'un assistant travaille directement sur votre système de fichiers et conserve l'état des données au fil du temps.

1. Les données du projet sont mélangées entre les espaces de travail.

La plupart des développeurs passent d'un dépôt à l'autre tout au long de la journée. Si un assistant conserve l'état d'un projet à l'autre, il devient plus difficile de comprendre son comportement et plus facile pour lui de faire des suppositions erronées. Chaque projet a besoin d'un espace propre et isolé pour son état et son historique.

2. Les pannes peuvent entraîner une perte de données.

Au cours d'une session de codage, un assistant produit un flux constant de données utiles - modifications de fichiers, appels d'outils, étapes intermédiaires. Si ces données ne sont pas sauvegardées immédiatement, un crash ou un redémarrage forcé peut les effacer. Un système fiable écrit les données importantes sur le disque dès qu'elles sont créées, de sorte que le travail n'est pas perdu de manière inattendue.

3. Il n'est pas toujours évident de savoir ce que l'agent a réellement fait.

Une session typique implique de nombreuses petites actions. Sans un enregistrement clair et ordonné de ces actions, il est difficile de retracer comment l'assistant est arrivé à un certain résultat ou de localiser l'étape où quelque chose s'est mal passé. Un historique complet rend le débogage et la révision beaucoup plus faciles à gérer.

4. L'annulation des erreurs demande trop d'efforts.

Il arrive que l'assistant apporte des modifications qui ne fonctionnent pas tout à fait. Si vous n'avez pas de moyen intégré pour annuler ces changements, vous finissez par rechercher manuellement les modifications dans le repo. Le système devrait automatiquement suivre ce qui a été modifié afin que vous puissiez l'annuler proprement sans travail supplémentaire.

5. Des projets différents nécessitent des paramètres différents.

Les environnements locaux varient. Certains projets nécessitent des autorisations, des outils ou des règles de répertoire spécifiques ; d'autres ont des scripts ou des flux de travail personnalisés. Un assistant doit respecter ces différences et permettre des paramétrages par projet tout en gardant son comportement principal cohérent.

Les principes de conception du stockage derrière Claude Code

La conception du stockage de Claude Code s'articule autour de quatre idées simples. Elles peuvent sembler simples, mais ensemble, elles répondent aux problèmes pratiques qui se posent lorsqu'un assistant IA travaille directement sur votre machine et sur plusieurs projets.

1. Chaque projet dispose de son propre espace de stockage.

Claude Code lie toutes les données de session au répertoire du projet auquel elles appartiennent. Cela signifie que les conversations, les modifications et les journaux restent dans le projet d'où ils proviennent et ne fuient pas dans les autres. Le fait de garder le stockage séparé rend le comportement de l'assistant plus facile à comprendre et permet d'inspecter ou d'effacer facilement les données d'un répertoire spécifique.

2. Les données sont immédiatement enregistrées sur le disque.

Au lieu de garder les données d'interaction en mémoire, Claude Code les écrit sur le disque dès qu'elles sont créées. Chaque événement - message, appel d'outil ou mise à jour d'état - est ajouté comme une nouvelle entrée. Si le programme se plante ou est fermé de manière inattendue, presque tout est encore là. Cette approche assure la durabilité des sessions sans ajouter beaucoup de complexité.

3. Chaque action a une place claire dans l'histoire.

Claude Code relie chaque message et chaque action d'outil à celui qui le précède, formant ainsi une séquence complète. Cet historique ordonné permet de revoir le déroulement d'une session et de retracer les étapes qui ont conduit à un résultat spécifique. Pour les développeurs, ce type de trace facilite grandement le débogage et la compréhension du comportement de l'agent.

4. Les modifications de code sont faciles à annuler.

Avant que l'assistant ne mette à jour un fichier, Claude Code enregistre un instantané de son état précédent. Si la modification s'avère erronée, vous pouvez rétablir la version précédente sans avoir à fouiller dans le répertoire ou à deviner ce qui a changé. Ce simple filet de sécurité rend les modifications effectuées par l'IA beaucoup moins risquées.

Disposition du stockage local de Claude Code

Claude Code stocke toutes ses données locales dans un seul endroit : votre répertoire personnel. Cela permet au système de rester prévisible et facilite l'inspection, le débogage ou le nettoyage en cas de besoin. La structure de stockage est construite autour de deux composants principaux : un petit fichier de configuration global et un répertoire de données plus grand où se trouve tout l'état du projet.

Deux composants principaux :

• ~/.claude.jsonStocke la configuration globale et les raccourcis, y compris les mappages de projets, les paramètres du serveur MCP et les invites récemment utilisées.

• ~/.claude/Le répertoire de données principal, où Claude Code stocke les conversations, les sessions de projet, les permissions, les plugins, les compétences, l'historique et les données d'exécution connexes.

Ensuite, regardons de plus près ces deux composants principaux.

(1) Configuration globale: ~/.claude.json

Ce fichier agit comme un index plutôt que comme un magasin de données. Il enregistre les projets sur lesquels vous avez travaillé, les outils associés à chaque projet et les invites que vous avez récemment utilisées. Les données de conversation elles-mêmes ne sont pas stockées dans ce fichier.

{
  "projects": {
    "/Users/xxx/my-project": {
      "mcpServers": {
        "jarvis-tasks": {
          "type": "stdio",
          "command": "python",
          "args": ["/path/to/run_mcp.py"]
        }
      }
    }
  },
  "recentPrompts": [
    "Fix the bug in auth module",
    "Add unit tests"
  ]
}

(2) Répertoire de données principal: ~/.claude/

Le répertoire ~/.claude/ contient la plupart des données locales de Claude Code. Sa structure reflète quelques idées fondamentales de conception : l'isolation du projet, la persistance immédiate, et la récupération sûre des erreurs.

~/.claude/
├── settings.json                    # Global settings (permissions, plugins, cleanup intervals)
├── settings.local.json              # Local settings (machine-specific, not committed to Git)
├── history.jsonl                    # Command history
│
├── projects/                        # 📁 Session data (organized by project, core directory)
│   └── -Users-xxx-project/          # Path-encoded project directory
│       ├── {session-id}.jsonl       # Primary session data (JSONL format)
│       └── agent-{agentId}.jsonl    # Sub-agent session data
│
├── session-env/                     # Session environment variables
│   └── {session-id}/                # Isolated by session ID
│
├── skills/                          # 📁 User-level skills (globally available)
│   └── mac-mail/
│       └── SKILL.md
│
├── plugins/                         # 📁 Plugin management
│   ├── config.json                  # Global plugin configuration
│   ├── installed_plugins.json       # List of installed plugins
│   ├── known_marketplaces.json      # Marketplace source configuration
│   ├── cache/                       # Plugin cache
│   └── marketplaces/
│       └── anthropic-agent-skills/
│           ├── .claude-plugin/
│           │   └── marketplace.json
│           └── skills/
│               ├── pdf/
│               ├── docx/
│               └── frontend-design/
│
├── todos/                           # Task list storage
│   └── {session-id}-*.json          # Session-linked task files
│
├── file-history/                    # File edit history (stored by content hash)
│   └── {content-hash}/              # Hash-named backup directory
│
├── shell-snapshots/                 # Shell state snapshots
├── plans/                           # Plan Mode storage
├── local/                           # Local tools / node_modules
│   └── claude                       # Claude CLI executable
│   └── node_modules/                # Local dependencies
│
├── statsig/                         # Feature flag cache
├── telemetry/                       # Telemetry data
└── debug/                           # Debug logs

Cette structure est intentionnellement simple : tout ce que Claude Code génère se trouve dans un seul répertoire, organisé par projet et par session. Il n'y a pas d'état caché éparpillé dans votre système, et il est facile de l'inspecter ou de le nettoyer quand c'est nécessaire.

Comment Claude Code gère la configuration

Le système de configuration de Claude Code est conçu autour d'une idée simple : garder le comportement par défaut cohérent sur toutes les machines, tout en laissant les environnements individuels et les projets personnaliser ce dont ils ont besoin. Pour ce faire, Claude Code utilise un modèle de configuration à trois niveaux. Lorsqu'un même paramètre apparaît à plusieurs endroits, c'est toujours la couche la plus spécifique qui l'emporte.

Les trois niveaux de configuration

Claude Code charge la configuration dans l'ordre suivant, de la priorité la plus basse à la plus haute :

┌─────────────────────────────────────────┐
│    Project-level configuration          │  Highest priority
│    project/.claude/settings.json        │  Project-specific, overrides other configs
├─────────────────────────────────────────┤
│    Local configuration                  │  Machine-specific, not version-controlled
│    ~/.claude/settings.local.json        │  Overrides global configuration
├─────────────────────────────────────────┤
│    Global configuration                 │  Lowest priority
│    ~/.claude/settings.json              │  Base default configuration
└─────────────────────────────────────────┘

On peut considérer que l'on commence par les valeurs par défaut globales, que l'on applique ensuite les ajustements spécifiques à la machine et que l'on applique enfin les règles spécifiques au projet.

Nous allons maintenant examiner chaque niveau de configuration en détail.

(1) Configuration globale: ~/.claude/settings.json

La configuration globale définit le comportement par défaut de Claude Code dans tous les projets. C'est ici que vous définissez les permissions de base, que vous activez les plugins et que vous configurez le comportement de nettoyage.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Read(**)", "Bash(npm:*)"],
    "deny": ["Bash(rm -rf:*)"],
    "ask": ["Edit", "Write"]
  },
  "enabledPlugins": {
    "document-skills@anthropic-agent-skills": true
  },
  "cleanupPeriodDays": 30
}

(2) Configuration locale: ~/.claude/settings.local.json

La configuration locale est spécifique à une seule machine. Elle n'est pas destinée à être partagée ou vérifiée dans le contrôle de version. C'est donc un bon endroit pour les clés d'API, les outils locaux ou les autorisations spécifiques à l'environnement.

{
  "permissions": {
    "allow": ["Bash(git:*)", "Bash(docker:*)"]
  },
  "env": {
    "ANTHROPIC_API_KEY": "sk-ant-xxx"
  }
}

(3) Configuration au niveau du projet: project/.claude/settings.json

La configuration au niveau du projet ne s'applique qu'à un seul projet et a la priorité la plus élevée. C'est ici que vous définissez les règles qui doivent toujours s'appliquer lorsque vous travaillez dans ce référentiel.

{
  "permissions": {
    "allow": ["Bash(pytest:*)"]
  }
}

Une fois les couches de configuration définies, la question suivante est de savoir comment Claude Code résout la configuration et les permissions au moment de l'exécution.

Claude Code applique la configuration en trois couches : il commence avec les valeurs par défaut globales, puis applique les dérogations spécifiques à la machine, et enfin applique les règles spécifiques au projet. Lorsque le même paramètre apparaît à plusieurs endroits, la configuration la plus spécifique est prioritaire.

Les autorisations suivent un ordre d'évaluation fixe :

1. deny - bloque toujours

2. ask - demande une confirmation

3. allow - s'exécute automatiquement

4. default - s'applique uniquement lorsqu'aucune règle ne correspond

Le système reste ainsi sûr par défaut, tout en offrant aux projets et aux machines individuelles la flexibilité dont ils ont besoin.

Stockage des sessions : Comment Claude Code conserve les données d'interaction essentielles

Dans Claude Code, les sessions sont l'unité centrale des données. Une session capture l'ensemble de l'interaction entre l'utilisateur et l'IA, y compris la conversation elle-même, les appels d'outils, les changements de fichiers et le contexte associé. La façon dont les sessions sont stockées a un impact direct sur la fiabilité, la débogage et la sécurité globale du système.

Conserver les données de session séparément pour chaque projet

Une fois les sessions définies, la question suivante est de savoir comment Claude Code les stocke de manière à garder les données organisées et isolées.

Claude Code isole les données de session par projet. Les sessions de chaque projet sont stockées dans un répertoire dérivé du chemin de fichier du projet.

Le chemin de stockage suit ce modèle :

~/.claude/projects/ + path-encoded project directory

Pour créer un nom de répertoire valide, les caractères spéciaux tels que /, les espaces et ~ sont remplacés par -.

Par exemple :

/Users/bill/My Project → -Users-bill-My-Project

Cette approche garantit que les données de session de différents projets ne se mélangent jamais et qu'elles peuvent être gérées ou supprimées pour chaque projet.

Pourquoi les sessions sont stockées au format JSONL

Claude Code stocke les données de session en utilisant JSONL (JSON Lines) au lieu de JSON standard.

Dans un fichier JSON traditionnel, tous les messages sont regroupés dans une grande structure, ce qui signifie que le fichier entier doit être lu et réécrit chaque fois qu'il change. En revanche, JSONL stocke chaque message sur sa propre ligne dans le fichier. Une ligne équivaut à un message, sans enveloppe extérieure.

Aspect	JSON standard	JSONL (lignes JSON)
Comment les données sont-elles stockées ?	Une grande structure	Un message par ligne
Quand les données sont sauvegardées	Généralement à la fin	Immédiatement, par message
Impact du crash	Le fichier entier peut se briser	Seule la dernière ligne est affectée
Écriture de nouvelles données	Réécriture du fichier entier	Ajouter une ligne
Utilisation de la mémoire	Charger tout	Lecture ligne par ligne

JSONL est plus efficace à plusieurs égards :

• Enregistrement immédiat : Chaque message est écrit sur le disque dès qu'il est généré, au lieu d'attendre la fin de la session.

• Résistance aux pannes : en cas de panne du programme, seul le dernier message non terminé peut être perdu. Tout ce qui a été écrit avant reste intact.

• Apposition rapide : Les nouveaux messages sont ajoutés à la fin du fichier sans lecture ni réécriture des données existantes.

• Faible utilisation de la mémoire : Les fichiers de session peuvent être lus une ligne à la fois, de sorte qu'il n'est pas nécessaire de charger l'ensemble du fichier en mémoire.

Un fichier de session JSONL simplifié ressemble à ceci :

{"type":"user","message":{"role":"user","content":"Hello"},"timestamp":"2026-01-05T10:00:00Z"}
{"type":"assistant","message":{"role":"assistant","content":[{"type":"text","text":"Hi!"}]}}
{"type":"user","message":{"role":"user","content":"Help me fix this bug"}}

Types de messages de session

Un fichier de session enregistre tout ce qui se passe lors d'une interaction avec le code Claude. Pour le faire clairement, il utilise différents types de messages pour différents types d'événements.

• Lesmessages de l'utilisateur représentent les nouvelles entrées dans le système. Cela inclut non seulement ce que l'utilisateur tape, mais aussi les résultats renvoyés par les outils, tels que la sortie d'une commande shell. Du point de vue de l'IA, il s'agit d'entrées auxquelles elle doit répondre.

• Lesmessages de l'assistant décrivent ce que Claude fait en réponse. Ces messages comprennent le raisonnement de l'IA, le texte qu'elle génère et tous les outils qu'elle décide d'utiliser. Ils enregistrent également les détails de l'utilisation, tels que le nombre de jetons, afin de fournir une image complète de l'interaction.

• Lesinstantanés de l'historique des fichiers sont des points de contrôle de sécurité créés avant que Claude ne modifie des fichiers. En sauvegardant d'abord l'état original du fichier, Claude Code permet d'annuler les modifications en cas de problème.

• Les résumés fournissent un aperçu concis de la session et sont liés au résultat final. Ils facilitent la compréhension du contenu d'une session sans avoir à en rejouer chaque étape.

Ensemble, ces types de messages enregistrent non seulement la conversation, mais aussi la séquence complète des actions et des effets qui se produisent au cours d'une session.

Pour rendre cela plus concret, examinons des exemples spécifiques de messages d'utilisateur et de messages d'assistant.

(1) Exemple de messages d'utilisateur :

{
  "type": "user",
  "uuid": "7d90e1c9-e727-4291-8eb9-0e7b844c4348",
  "parentUuid": null,
  "sessionId": "e5d52290-e2c1-41d6-8e97-371401502fdf",
  "timestamp": "2026-01-05T10:00:00.000Z",
  "message": {
    "role": "user",
    "content": "Analyze the architecture of this project"
  },
  "cwd": "/Users/xxx/project",
  "gitBranch": "main",
  "version": "2.0.76"
}

(2) Exemple de messages d'assistant :

{
  "type": "assistant",
  "uuid": "e684816e-f476-424d-92e3-1fe404f13212",
  "parentUuid": "7d90e1c9-e727-4291-8eb9-0e7b844c4348",
  "message": {
    "role": "assistant",
    "model": "claude-opus-4-5-20251101",
    "content": [
      {
        "type": "thinking",
        "thinking": "The user wants to understand the project architecture, so I need to check the directory structure first..."
      },
      {
        "type": "text",
        "text": "Let me take a look at the project structure first."
      },
      {
        "type": "tool_use",
        "id": "toolu_01ABC",
        "name": "Bash",
        "input": {"command": "ls -la"}
      }
    ],
    "usage": {
      "input_tokens": 1500,
      "output_tokens": 200,
      "cache_read_input_tokens": 50000
    }
  }
}

Comment les messages de session sont liés

Claude Code ne stocke pas les messages de session en tant qu'entrées isolées. Au contraire, il les relie entre eux pour former une chaîne d'événements claire. Chaque message comprend un identifiant unique (uuid) et une référence au message qui le précède (parentUuid). Cela permet de voir non seulement ce qui s'est passé, mais aussi pourquoi cela s'est passé.

Une session commence par un message d'utilisateur, qui lance la chaîne. Chaque réponse de Claude renvoie au message qui l'a provoquée. Les appels d'outils et leurs résultats sont ajoutés de la même manière, chaque étape étant liée à la précédente. Lorsque la session se termine, un résumé est joint au message final.

Comme chaque étape est liée, Claude Code peut rejouer la séquence complète des actions et comprendre comment un résultat a été produit, ce qui facilite grandement le débogage et l'analyse.

Faciliter l'annulation des modifications du code grâce aux instantanés de fichiers

Les modifications générées par l'IA ne sont pas toujours correctes, et parfois elles vont dans la mauvaise direction. Pour rendre ces modifications sûres, Claude Code utilise un simple système d'instantanés qui vous permet d'annuler les modifications sans avoir à fouiller dans les différences ou à nettoyer manuellement les fichiers.

L'idée est simple : avant que Claude Code ne modifie un fichier, il enregistre une copie du contenu original. Si la modification s'avère être une erreur, le système peut restaurer instantanément la version précédente.

Qu'est-ce qu'un instantané de l'historique d'un fichier?

Un instantané de l'historique des fichiers est un point de contrôle créé avant que les fichiers ne soient modifiés. Il enregistre le contenu original de chaque fichier que Claude s'apprête à modifier. Ces instantanés servent de source de données pour les opérations d'annulation et de retour en arrière.

Lorsqu'un utilisateur envoie un message susceptible de modifier des fichiers, Claude Code crée un instantané vide pour ce message. Avant l'édition, le système sauvegarde le contenu original de chaque fichier cible dans l'instantané, puis applique les modifications directement sur le disque. Si l'utilisateur déclenche l'annulation, Claude Code restaure le contenu sauvegardé et écrase les fichiers modifiés.

En pratique, le cycle de vie d'une modification annulable se déroule comme suit :

1. L'utilisateur envoie un messageClaudeCode crée un nouvel enregistrement vide file-history-snapshot.

2. Claude se prépare à modifier les fichiersLesystème identifie les fichiers à modifier et sauvegarde leur contenu original sur trackedFileBackups.

3. Claude exécute la modificationLesopérations demodificationet d'écriture sont effectuées et le contenu modifié est écrit sur le disque.

4. L'utilisateurdéclenche l'annulationL'utilisateur appuie sur Esc + Esc, signalant que les modifications doivent être annulées.

5. Le contenu original est restauréClaudeCode lit le contenu sauvegardé sur trackedFileBackups et écrase les fichiers actuels, achevant ainsi l'annulation.

Pourquoi l'annulation fonctionne-t-elle ? Les instantanés sauvegardent l'ancienne version

L'annulation dans Claude Code fonctionne parce que le système enregistre le contenu original du fichier avant toute modification.

Au lieu d'essayer d'annuler les modifications après coup, Claude Code adopte une approche plus simple : il copie le fichier tel qu'il existait avant la modification et stocke cette copie dans trackedFileBackups. Lorsque l'utilisateur déclenche l'annulation, le système restaure cette version sauvegardée et écrase le fichier modifié.

Le diagramme ci-dessous illustre ce flux étape par étape :

┌─────────────────────────┐
│    before edit,  app.py │
│    print("old")         │───────→  Backed up into snapshot trackedFileBackups
└─────────────────────────┘
↓
┌──────────────────────────┐
│   After Claude edits     │
│    print(“new”)          │───────→  Written to disk (overwrites the original file)
└──────────────────────────┘
↓
┌──────────────────────────┐
│    User triggers undo    │
│    Press   Esc + Esc     │───────→ Restore “old” content to disk from snapshot
└──────────────────────────┘

A quoi ressemble un instantané de l'historique des fichiers en interne

L'instantané lui-même est stocké sous la forme d'un enregistrement structuré. Il contient des métadonnées sur le message de l'utilisateur, l'heure de l'instantané et, surtout, une correspondance entre les fichiers et leur contenu d'origine.

L'exemple ci-dessous montre un seul enregistrement file-history-snapshot créé avant que Claude ne modifie des fichiers. Chaque entrée de trackedFileBackups stocke le contenu d'un fichier avant sa modification, qui est ensuite utilisé pour restaurer le fichier lors d'une annulation.

{
  "type": "file-history-snapshot",
  "messageId": "7d90e1c9-e727-4291-8eb9-0e7b844c4348",
  "snapshot": {
    "messageId": "7d90e1c9-e727-4291-8eb9-0e7b844c4348",
    "trackedFileBackups": {
      "/path/to/file1.py": "Original file content\ndef hello():\n    print('old')",
      "/path/to/file2.js": "// Original content..."
    },
    "timestamp": "2026-01-05T10:00:00.000Z"
  },
  "isSnapshotUpdate": false
}

Où sont stockés les instantanés et combien de temps ils sont conservés

• Où sont stockées les métadonnées des instantanés: Les enregistrements d'instantanés sont liés à une session spécifique et sauvegardés sous forme de fichiers JSONL à l'adresse~/.claude/projects/-path-to-project/{session-id}.jsonl.

• Où le contenu original des fichiers est sauvegardé: Le contenu de chaque fichier avant édition est stocké séparément par hachage de contenu sous~/.claude/file-history/{content-hash}/.

• Durée de conservation des instantanés par défaut: Les données des instantanés sont conservées pendant 30 jours, conformément au paramètre global cleanupPeriodDays.

• Comment modifier la durée de conservation: Le nombre de jours de conservation peut être ajusté via le champ cleanupPeriodDays dans ~/.claude/settings.json.

Commandes associées

Commande / Action	Description de la commande
Esc + Esc	Annule la dernière série d'éditions de fichiers (la plus couramment utilisée)
/rewind	Revenir à un point de contrôle spécifié précédemment (snapshot)
/diff	Affiche les différences entre le fichier actuel et la sauvegarde instantanée.

Autres répertoires importants

(1) plugins/ - Gestion des plugins

Le répertoire plugins/ stocke les modules complémentaires qui donnent à Claude Code des capacités supplémentaires.

Ce répertoire stocke les plugins installés, leur provenance et les compétences supplémentaires qu'ils apportent. Il conserve également des copies locales des plugins téléchargés afin qu'ils n'aient pas besoin d'être récupérés à nouveau.

~/.claude/plugins/
├── config.json
│   Global plugin configuration (e.g., enable/disable rules)
├── installed_plugins.json
│   List of installed plugins (including version and status)
├── known_marketplaces.json
│   Plugin marketplace source configuration (e.g., Anthropic official marketplace)
├── cache/
│   Plugin download cache (avoids repeated downloads)
└── marketplaces/
    Marketplace source storage
    └── anthropic-agent-skills/
        Official plugin marketplace
        ├── .claude-plugin/
        │   └── marketplace.json
        │       Marketplace metadata
        └── skills/
            Skills provided by the marketplace
            ├── pdf/
            │   PDF-related skills
            ├── docx/
            │   Word document processing skills
            └── frontend-design/
                Frontend design skills

(2) skills/ - Où les compétences sont stockées et appliquées

Dans Claude Code, une compétence est une petite capacité réutilisable qui aide Claude à effectuer une tâche spécifique, comme travailler avec des PDF, éditer des documents, ou suivre un flux de travail de codage.

Toutes les compétences ne sont pas disponibles partout. Certaines s'appliquent globalement, tandis que d'autres sont limitées à un seul projet ou fournies par un plugin. Claude Code stocke les compétences à différents endroits pour contrôler où chaque compétence peut être utilisée.

La hiérarchie ci-dessous montre comment les compétences sont superposées en fonction de leur portée, depuis les compétences disponibles globalement jusqu'aux compétences spécifiques à un projet ou fournies par un plugin.

Niveau	Emplacement de stockage	Description des compétences
Utilisateur	~/.claude/skills/	Disponible globalement, accessible par tous les projets
Projet	projet/.claude/compétences/	Disponible uniquement pour le projet en cours, personnalisation spécifique au projet
Plugin	~/.claude/plugins/marketplaces/*/skills/	Installé avec les plugins, dépend de l'état d'activation des plugins

(3) todos/ - Stockage des listes de tâches

Le répertoire todos/ stocke les listes de tâches que Claude crée pour faire le suivi du travail au cours d'une conversation, comme les étapes à franchir, les éléments en cours et les tâches terminées.

Les listes de tâches sont enregistrées sous forme de fichiers JSON dans le répertoire~/.claude/todos/{session-id}-*.json. Chaque nom de fichier comprend l'identifiant de la session, qui lie la liste de tâches à une conversation spécifique.

Le contenu de ces fichiers provient de l'outil TodoWrite et comprend des informations de base sur les tâches telles que la description de la tâche, l'état actuel, la priorité et les métadonnées connexes.

(4) local/ - Exécution locale et outils

Le répertoire local/ contient les fichiers principaux dont Claude Code a besoin pour fonctionner sur votre machine.

Cela inclut l'exécutable en ligne de commande claude et le répertoire node_modules/ qui contient ses dépendances d'exécution. En gardant ces composants locaux, Claude Code peut fonctionner de manière indépendante, sans dépendre de services externes ou d'installations sur l'ensemble du système.

（5）Additional Supporting Directories

• shell-snapshots/ : Stocke des instantanés de l'état de la session shell (comme le répertoire courant et les variables d'environnement), ce qui permet de revenir en arrière dans les opérations shell.

• plans/ : Stocke les plans d'exécution générés par le mode Plan (par exemple, la décomposition étape par étape des tâches de programmation à plusieurs étapes).

• statsig/ : Met en cache les configurations des indicateurs de fonctionnalités (par exemple, si de nouvelles fonctionnalités sont activées) afin de réduire le nombre de requêtes répétées.

• telemetry/ : Stocke des données télémétriques anonymes (telles que la fréquence d'utilisation des fonctionnalités) afin d'optimiser le produit.

• debug/ : Stocke les journaux de débogage (y compris les piles d'erreurs et les traces d'exécution) pour faciliter le dépannage.

Conclusion

Après avoir creusé la façon dont Claude Code stocke et gère tout localement, l'image devient assez claire : l'outil semble stable parce que les fondations sont solides. Rien d'extravagant - juste une ingénierie réfléchie. Chaque projet a son propre espace, chaque action est notée et les modifications de fichiers sont sauvegardées avant que quoi que ce soit ne change. C'est le genre de conception qui fait tranquillement son travail et vous permet de vous concentrer sur le vôtre.

Ce que j'aime le plus, c'est qu'il n'y a rien de mystique ici. Claude Code fonctionne bien parce que les bases sont bien faites. Si vous avez déjà essayé de construire un agent qui touche de vrais fichiers, vous savez à quel point il est facile pour les choses de s'effondrer - les états se mélangent, les crashs effacent les progrès, et l'annulation devient une devinette. Claude Code évite tout cela grâce à un modèle de stockage simple, cohérent et difficile à casser.

Pour les équipes qui développent des agents d'intelligence artificielle locaux ou sur site, en particulier dans des environnements sécurisés, cette approche montre comment un stockage et une persistance solides rendent les outils d'intelligence artificielle fiables et pratiques pour le développement quotidien.

Si vous concevez des agents d'IA locaux ou sur site et souhaitez discuter plus en détail de l'architecture de stockage, de la conception des sessions ou du rollback sécurisé, n'hésitez pas à rejoindre notre canal Slack. Vous pouvez également réserver un entretien individuel de 20 minutes dans le cadre des Milvus Office Hours pour obtenir des conseils personnalisés.