Isoler Claude Code dans Docker : Sandbox & Devcontainer (2026)

Sommaire

Pourquoi isoler Claude Code dans un container Docker ? {#pourquoi-isoler}

Isoler Claude Code dans Docker est devenu en 2026 la pratique standard pour les développeurs qui veulent exploiter pleinement les capacités agentiques de l'outil sans risquer leur machine hôte. La raison est simple : Claude Code est un agent autonome avec un accès large au système, capable d'écrire des fichiers, d'exécuter des commandes shell, d'installer des paquets et de faire des appels réseau. Sans isolation, une mauvaise interprétation d'instruction ou une prompt injection peut causer des dégâts irréversibles.

L'incident de référence date de décembre 2025 : un utilisateur a demandé à Claude Code de nettoyer des paquets, et l'agent a généré une commande avec un ~/ mal interprété par le shell qui a supprimé tout son répertoire home — Desktop, Keychain, configs applicatives. Tout disparu en quelques secondes. Cet épisode a déclenché un mouvement de fond vers la containerisation systématique des agents IA de coding.

En isolant Claude Code dans Docker, vous obtenez trois bénéfices immédiats :

C'est aussi le seul moyen d'utiliser sereinement le flag --dangerously-skip-permissions (ou "Safe YOLO mode"), indispensable pour les workflows autonomes longs comme [les workflows long-running de Claude Code](/blog/workflows-autonomes-long-running-claude-code).

Docker Sandbox vs Devcontainer : quelle différence ? {#sandbox-vs-devcontainer}

Deux approches dominent en 2026 pour isoler Claude Code dans Docker, et choisir la bonne dépend de votre usage. Voici comment trancher.

Docker Sandboxes (Docker Desktop 4.58+)

Les Docker Sandboxes s'exécutent sur des microVMs dédiées plutôt que des conteneurs standard. La microVM ajoute une frontière de sécurité matérielle (hyperviseur) au-dessus du namespace Linux classique, ce qui rend l'évasion conteneur quasi impossible. C'est l'option à privilégier si vous traitez du code non audité ou si vous exécutez l'agent en mode totalement autonome.

Devcontainer

Le devcontainer est l'option recommandée par la documentation officielle Anthropic pour les workflows quotidiens. C'est un conteneur Docker décrit par un devcontainer.json versionné dans votre repo, qui se monte automatiquement dans VS Code (ou Cursor, JetBrains). Vous codez dans le conteneur sans même vous en rendre compte, avec votre extension et vos volumes montés.

Verdict pratique : commencez par un devcontainer pour le dev de tous les jours. Passez au Docker Sandbox pour les sessions sensibles (audit sécu, refactoring sur code legacy non audité, mode complètement autonome).

Comment créer un devcontainer Claude Code pas à pas ? {#creer-devcontainer}

Voici la configuration minimale qui marche en 2026 sur VS Code, Cursor et Claude Code Desktop. L'objectif : un environnement reproductible que vous pouvez committer dans n'importe quel repo.

Étape 1 — Créer la structure de fichiers

À la racine de votre projet, créez :

.devcontainer/
├── devcontainer.json
├── Dockerfile
└── init-firewall.sh

Étape 2 — Écrire le Dockerfile

FROM node:22-bookworm

RUN apt-get update && apt-get install -y \
    git curl jq iptables ipset sudo \
    && rm -rf /var/lib/apt/lists/*

ARG USERNAME=node
RUN echo "$USERNAME ALL=(root) NOPASSWD: /usr/local/bin/init-firewall.sh" \
    > /etc/sudoers.d/firewall

RUN npm install -g @anthropic-ai/claude-code

USER $USERNAME
WORKDIR /workspace

L'image base node:22-bookworm est suffisante pour la plupart des projets modernes. Si vous travaillez en Python, ajoutez python3 python3-pip uv aux paquets installés.

Étape 3 — Configurer le devcontainer.json

{
  "name": "claude-code-sandbox",
  "build": { "dockerfile": "Dockerfile" },
  "runArgs": [
    "--cap-add=NET_ADMIN",
    "--cap-add=NET_RAW"
  ],
  "mounts": [
    "source=claude-code-bashhistory,target=/commandhistory,type=volume",
    "source=${localEnv:HOME}/.claude,target=/home/node/.claude,type=bind"
  ],
  "remoteUser": "node",
  "postCreateCommand": "sudo /usr/local/bin/init-firewall.sh",
  "customizations": {
    "vscode": {
      "extensions": ["anthropic.claude-code"]
    }
  }
}

Les runArgs NET_ADMIN et NET_RAW sont nécessaires pour que le script de firewall puisse appliquer ses règles iptables. Le mount de ~/.claude réutilise votre auth Claude Code existante, ce qui évite de devoir reconnecter à chaque rebuild.

Étape 4 — Lancer le devcontainer

Dans VS Code :

Une fois dans le conteneur, lancez Claude Code normalement :

claude

Pour aller plus loin sur la configuration globale du projet, consultez notre [guide du fichier CLAUDE.md](/blog/claude-md-fichier-configuration-guide-complet-2026) — un CLAUDE.md bien écrit décuple l'efficacité de l'agent dans un environnement isolé.

Isolation réseau avancée : firewall, allowlist et proxy {#isolation-reseau}

L'isolation système de fichiers ne suffit pas. Si Claude Code peut appeler n'importe quelle URL, une prompt injection peut exfiltrer vos secrets vers un serveur tiers. La couche réseau est donc tout aussi critique. Voici le script init-firewall.sh qui implémente une allowlist stricte des domaines accessibles depuis le conteneur.

#!/bin/bash
set -euo pipefail

# Domaines autorisés (allowlist par défaut deny)
ALLOWED_DOMAINS=(
  "registry.npmjs.org"
  "github.com"
  "api.github.com"
  "raw.githubusercontent.com"
  "api.anthropic.com"
  "code.claude.com"
  "pypi.org"
  "files.pythonhosted.org"
)

# Politique par défaut : tout bloquer
iptables -P OUTPUT DROP
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT  # DNS

ipset create allowed-domains hash:ip

for domain in "${ALLOWED_DOMAINS[@]}"; do
  for ip in $(dig +short "$domain"); do
    ipset add allowed-domains "$ip" || true
  done
done

iptables -A OUTPUT -m set --match-set allowed-domains dst -j ACCEPT
iptables -A OUTPUT -j REJECT

echo "Firewall configuré : ${#ALLOWED_DOMAINS[@]} domaines autorisés"

Cette politique default deny est la bonne base de référence en 2026. Tout trafic sortant non whitelisté est bloqué, ce qui transforme une éventuelle prompt injection en simple erreur réseau plutôt qu'une fuite de données.

Mode avancé : proxy HTTP filtrant

Pour les environnements d'entreprise où vous voulez du filtrage URL (et pas juste par IP), routez tout le trafic via un proxy Squid avec une dstdomain whitelist. Ce pattern est notamment utilisé chez les éditeurs SaaS comme [smartbtp.ai pour sécuriser leurs workflows IA en entreprise](https://smartbtp.ai) où le filtrage par domaine est obligatoire pour des raisons de conformité métier.

Pour les développeurs qui exposent des APIs internes via MCP au sein de leur sandbox, c'est aussi le pattern à appliquer — voir [comment créer un serveur MCP pour Claude Code](/blog/creer-serveur-mcp-claude-code-python-typescript-2026) pour ajouter vos outils métier à l'intérieur du conteneur.

Utiliser --dangerously-skip-permissions sans risque {#dangerously-skip-permissions}

Le flag --dangerously-skip-permissions (souvent appelé "Safe YOLO mode") supprime toutes les confirmations utilisateur avant chaque écriture de fichier, exécution de commande shell ou appel réseau. Sans isolation, c'est suicidaire. Avec un devcontainer correctement configuré, c'est la combinaison la plus productive de 2026.

La règle d'or est claire : YOLO mode uniquement dans un conteneur, jamais sur l'hôte.

Configuration recommandée

# À l'intérieur du devcontainer uniquement
claude --dangerously-skip-permissions

Vous pouvez aussi l'activer par défaut via une variable d'environnement dans le devcontainer.json :

"containerEnv": {
  "CLAUDE_SKIP_PERMISSIONS": "true"
}

Cas d'usage où YOLO mode brille

Cas d'usage où YOLO mode est risqué (même en sandbox)

Pour comprendre la philosophie alternative d'Anthropic qui essaie de réconcilier sécurité et autonomie sans flag dangereux, lisez notre article sur [Claude Code Auto Mode et les permissions intelligentes](/blog/claude-code-auto-mode-permissions-intelligentes).

Erreurs fréquentes et bonnes pratiques {#erreurs}

Sept pièges récurrents observés sur les projets qui adoptent l'isolation Docker pour Claude Code :

Vérifier l'efficacité de l'isolation

Quatre tests rapides à exécuter dans le conteneur après build :

# 1. Le firewall bloque les domaines non autorisés
curl -m 5 https://example.com  # doit échouer (timeout/refusé)

# 2. Le firewall laisse passer les domaines autorisés
curl -m 5 https://api.anthropic.com  # doit répondre (4xx attendu)

# 3. Pas d'accès à l'hôte
ls /host  # doit échouer

# 4. L'utilisateur n'est pas root
whoami  # doit afficher "node", pas "root"

Si les quatre tests passent, votre sandbox est opérationnelle. Pour pousser plus loin la sécurité du code lui-même, combinez avec le [plugin Security-Guidance de Claude Code](/blog/security-guidance-plugin-claude-code-detecter-vulnerabilites-2026) qui détecte les vulnérabilités dans le code produit par l'agent.

FAQ — Isoler Claude Code dans Docker {#faq}

Pourquoi faut-il isoler Claude Code dans Docker ?

Claude Code est un agent autonome avec un accès large à votre système : il peut écrire des fichiers, exécuter des commandes shell, installer des paquets et appeler des APIs. Sans isolation, une mauvaise interprétation d'instruction ou une prompt injection peut détruire des données. Docker fournit une frontière de sécurité (filesystem, réseau, processus) qui transforme un incident potentiellement catastrophique en simple reset de conteneur.

Quelle est la différence entre Docker Sandbox et un devcontainer ?

Un Docker Sandbox (Docker Desktop 4.58+) tourne sur une microVM dédiée et offre une isolation matérielle via hyperviseur. Un devcontainer est un conteneur Linux classique, plus léger et mieux intégré à VS Code via le fichier devcontainer.json. Pour le dev quotidien : devcontainer. Pour traiter du code non audité ou un mode 100% autonome : Docker Sandbox.

Peut-on utiliser --dangerously-skip-permissions en toute sécurité ?

Oui, mais uniquement dans un conteneur isolé avec firewall réseau (allowlist par défaut deny). Le flag supprime toutes les confirmations utilisateur ; si l'agent est dans un conteneur sans accès à l'hôte ni à internet sauvage, le pire scénario est de casser le conteneur — récupérable en quelques secondes. Sur l'hôte, le même flag est suicidaire.

Le devcontainer Claude Code marche-t-il avec Cursor et JetBrains ?

Oui. Le standard devcontainer.json est supporté par VS Code, Cursor (basé sur VS Code), GitHub Codespaces et JetBrains Gateway. La configuration que vous écrivez fonctionne donc à travers les IDE sans modification. C'est l'un des arguments forts du devcontainer face aux solutions propriétaires.

Comment éviter que Claude Code n'exfiltre des secrets via le réseau ?

Trois couches à empiler : (1) une allowlist iptables par défaut deny qui ne laisse passer que les domaines techniques nécessaires (api.anthropic.com, registry.npmjs.org, github.com), (2) un proxy HTTP filtrant type Squid pour valider même les domaines autorisés au niveau URL, (3) ne jamais monter de secrets dans le conteneur (pas de ~/.ssh, pas de .env de prod).

Quel est l'impact performance d'un devcontainer Claude Code ?

Quasi nul sur Linux natif et macOS Apple Silicon avec Virtualization.framework. Sur Windows avec WSL2, comptez 5-10% d'overhead par rapport au natif. Le facteur dominant reste la latence API Anthropic, qui pèse plus que la couche conteneur. Pour les workflows lourds en I/O fichier, utilisez un volume nommé pour le node_modules plutôt qu'un bind mount.

Comment partager mon devcontainer Claude Code avec mon équipe ?

Committez les fichiers .devcontainer/devcontainer.json, .devcontainer/Dockerfile et .devcontainer/init-firewall.sh à la racine du repo. Toute personne qui clone le projet et l'ouvre dans VS Code se voit proposer "Reopen in Container". Combiné à un CLAUDE.md versionné, vous obtenez un environnement Claude Code 100% reproductible pour toute l'équipe.

Aller plus loin : ressources liées