Configuration

Toute la configuration se trouve dans le fichier .env à la racine du projet. Ce fichier est ignoré par git — il n’est jamais commité.

Variables d’environnement

Fournisseur d’IA

Le conteneur prend en charge deux modes d’authentification mutuellement exclusifs (par ordre de priorité) :

• Proxy LiteLLM — définissez LITELLM_BASE_URL et LITELLM_API_KEY pour router via un proxy LiteLLM (voir ci-dessous).
• Mode OAuth — définissez uniquement CLAUDE_CODE_OAUTH_TOKEN (voir ci-dessous).

Ne combinez pas les modes — utilisez exactement un seul.

Claude Max (OAuth)

Variable	Description	Exemple
CLAUDE_CODE_OAUTH_TOKEN	Jeton OAuth provenant d’un abonnement Claude Max	sk-ant-oat01-...

Lorsqu’il est défini, Claude Code s’authentifie directement auprès d’Anthropic via OAuth — aucune clé API ni proxy nécessaire. Obtenez votre jeton depuis les paramètres de Claude Code ou la console Anthropic.

Proxy LiteLLM

Si votre proxy LiteLLM (ou autre) prend déjà en charge nativement l’API Anthropic Messages — y compris web_search, le streaming et l’utilisation d’outils — définissez LITELLM_BASE_URL avec le domaine du proxy. Le conteneur dérive automatiquement les URLs spécifiques au fournisseur :

• Point de terminaison Anthropic → ${LITELLM_BASE_URL}/anthropic (utilisé par Claude Code)
• Point de terminaison compatible OpenAI → ${LITELLM_BASE_URL}/openai/v1

Variable	Description	Exemple
LITELLM_BASE_URL	Domaine de votre proxy LiteLLM (sans suffixe de chemin)	https://litellm.example.com
LITELLM_API_KEY	Clé API pour l’authentification au proxy	your-api-key ou par défaut litellm-proxy

Les utilisateurs n’ont besoin de définir que le domaine — les suffixes de chemin du fournisseur sont ajoutés automatiquement. Au démarrage, le point d’entrée dérive ANTHROPIC_API_KEY à partir de LITELLM_API_KEY afin que Claude Code puisse utiliser les identifiants du proxy sans nécessiter une variable séparée exposée à l’utilisateur.

Les noms de modèles ne sont pas remappés dans ce mode. Claude Code envoie ses identifiants de modèles standard (par ex. claude-sonnet-4-6) et LiteLLM les route vers votre backend configuré.

Validation des certificats TLS

Par défaut, Node.js valide les certificats TLS pour toutes les connexions HTTPS. Si votre fournisseur d’API en amont utilise un certificat auto-signé (courant avec les proxys internes Open WebUI ou LiteLLM), vous pouvez désactiver la validation en ajoutant ceci à votre fichier .env :

NODE_TLS_REJECT_UNAUTHORIZED=0

Ceci n’est pas recommandé pour un usage en production. Ne définissez cette variable que lorsque vous faites confiance au chemin réseau entre le conteneur et votre point de terminaison API.

Agents de codage IA

Le conteneur inclut plusieurs agents de codage IA en plus de Claude Code :

Agent	Commande	Fournisseur
Codex	codex	Compatible OpenAI
Pi	pi	Multi-fournisseur (configurer au démarrage)
Oh-My-Pi	omp	Multi-fournisseur (configurer au démarrage)

Pi et Oh-My-Pi sont installés en tant que packages npm globaux. Codex est un binaire autonome qui se met à jour automatiquement au démarrage.

Affichage distant (noVNC)

Le conteneur exécute une pile d’affichage virtuel pour observer et interagir avec les navigateurs en mode graphique. Voir Affichage distant (noVNC) pour les instructions de connexion et les variables d’environnement (ENABLE_VNC, VNC_RESOLUTION, DISPLAY, NOVNC_HOST_PORT).

Chrome DevTools MCP

Le conteneur inclut un serveur Chrome DevTools MCP pré-configuré pour l’automatisation de navigateur headless. Claude Code peut naviguer sur des pages web, prendre des captures d’écran et inspecter le DOM sans aucune configuration supplémentaire. Voir Chrome DevTools MCP pour les détails.

Git

Variable	Description	Comment définir
GIT_AUTHOR_NAME	Nom pour les commits git	git config user.name
GIT_AUTHOR_EMAIL	Email pour les commits git	git config user.email

Si git est configuré sur votre hôte, remplissez automatiquement les deux valeurs :

echo "GIT_AUTHOR_EMAIL=$(git config user.email)" >> .env
echo "GIT_AUTHOR_NAME=\"$(git config user.name)\"" >> .env

SSH

Variable	Description	Comment définir
SSH_PRIVATE_KEY	Clé privée encodée en Base64	base64 < ~/.ssh/id_ed25519

GitHub CLI

Variable	Description	Comment définir
GH_TOKEN	Jeton d’accès personnel GitHub pour le CLI gh et git HTTPS	gh auth token (si gh est installé localement)

Lorsque GH_TOKEN est défini dans .env, le CLI gh s’authentifie automatiquement — pas besoin d’exécuter gh auth login. Le point d’entrée exécute également gh auth setup-git, qui configure le gestionnaire d’identifiants git pour que git clone et git push en HTTPS fonctionnent sans clés SSH.

Si gh est installé et authentifié sur votre machine hôte, extrayez le jeton directement :

echo "GH_TOKEN=$(gh auth token)" >> .env

Sinon, créez un jeton d’accès personnel et ajoutez-le manuellement. Les jetons à portée fine (recommandés) et les jetons classiques fonctionnent tous les deux. Les jetons à portée fine vous permettent de limiter l’accès à des dépôts spécifiques. Les jetons classiques nécessitent la portée repo pour l’accès aux dépôts privés.

Pour vérifier l’authentification à l’intérieur du conteneur :

gh auth status

Comment les outils sont installés

Chaque environnement d’exécution, CLI et outil est installé directement dans le Dockerfile lors de la construction de l’image. L’image pré-construite est publiée sur ghcr.io/f5-sales-demo/devcontainer:latest à chaque push sur main, de sorte que la plupart des utilisateurs n’ont jamais besoin de construire localement.

Docker

L’exécution de docker compose up -d tire automatiquement l’image pré-construite. Pour construire localement après avoir personnalisé le Dockerfile, passez le fichier de build explicitement :

docker compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Voir Développement local pour les détails.

Podman

L’exécution de podman-compose up -d tire automatiquement l’image pré-construite. Pour construire localement après avoir personnalisé le Dockerfile, passez le fichier de build explicitement :

podman-compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Voir Développement local pour les détails.

Le Dockerfile utilise un build en deux étapes optimisé pour la mise en cache des couches Docker. Voir Développement local — Architecture de build en deux étapes pour le détail complet des couches et les informations sur le cache de build.

Conscience des outils de Claude Code

Le conteneur inclut une configuration intégrée qui empêche Claude Code de confondre les noms d’outils. La conscience des outils est installée à deux niveaux de mémoire pour une défense en profondeur :

• Politique gérée (/etc/claude-code/CLAUDE.md) — installée lors de la construction Docker. C’est le niveau de priorité le plus élevé dans la hiérarchie de mémoire de Claude Code et il est toujours chargé, même lorsqu’un grand CLAUDE.md de projet existe dans le répertoire de travail.
• Mémoire utilisateur (~/.claude/CLAUDE.md) — initialisée par le point d’entrée au premier démarrage. Fournit une couche de secours et une copie visible et personnalisable pour les utilisateurs.

Priorité des niveaux de mémoire

Claude Code charge les instructions à partir de plusieurs niveaux de mémoire (de la priorité la plus haute à la plus basse) :

1. Politique gérée (/etc/claude-code/) — Toujours chargée, ne peut pas être exclue
2. Mémoire de projet (./CLAUDE.md) — Chargée par répertoire de projet
3. Mémoire utilisateur (~/.claude/CLAUDE.md) — Chargée globalement pour toutes les sessions
4. Mémoire locale (./CLAUDE.local.md) — Remplacements personnels par projet

Sans le niveau de politique gérée, la conscience des outils dans la mémoire utilisateur peut être déprioritisée lorsqu’elle entre en compétition avec un grand CLAUDE.md au niveau du projet, entraînant la perte par Claude de la conscience de ses noms d’outils en PascalCase. Le niveau géré garantit que la conscience des outils est toujours chargée avec la priorité la plus élevée.

Auto-test

Exécutez l’auto-test intégré pour vérifier la configuration :

claude-self-test

Ceci vérifie que tous les fichiers de configuration sont en place et contiennent les références d’outils attendues.

Ajouter des outils

Pour ajouter des outils à l’image, modifiez le Dockerfile et reconstruisez localement. Voir Développement local — Ajouter des outils pour les instructions sur l’ajout de packages APT, d’outils npm, d’outils pip et de téléchargements de binaires.

Extensions VS Code

Les extensions sont configurées dans .devcontainer/devcontainer.json sous customizations.vscode.extensions et installées automatiquement lors de l’ouverture dans VS Code.

Persistance des données

Toutes les données résident dans des volumes nommés — aucun répertoire hôte n’est monté :

Volume	Point de montage	Contenu
workspace	/workspace	Vos dépôts clonés et fichiers de projet
home	/home/vscode	Historique du shell, configurations d’outils, caches, clés SSH

Docker

Les deux persistent à travers les redémarrages et reconstructions du conteneur. Exécutez docker compose pull pour récupérer la dernière image pré-construite avant de redémarrer.

Action	Données
docker compose down	Préservées
docker compose down -v	Supprimées

Podman

Les deux persistent à travers les redémarrages et reconstructions du conteneur. Exécutez podman-compose pull pour récupérer la dernière image pré-construite avant de redémarrer.

Action	Données
podman-compose down	Préservées
podman-compose down -v	Supprimées

Mappage des ports

Hôte	Conteneur	Service
127.0.0.1:${NOVNC_HOST_PORT:-6080}	6080	Affichage distant noVNC (localhost uniquement, remplacer avec NOVNC_HOST_PORT)

Les ports sont liés à 127.0.0.1 afin qu’ils ne soient accessibles que depuis votre machine, pas depuis le réseau.