Exécution dans Docker

Disponible en aperçu pour les sessions Claude Code, Codex, Grok Build et Kimi Code sur Linux et macOS. L’exécution locale reste disponible et sélectionnée par défaut. Les cycles audités continuent de s’exécuter localement pendant cet aperçu.

AirCode Ø continue de fonctionner sur votre ordinateur ou serveur. Si vous choisissez Sandbox Docker, seule la session directe de l’agent s’exécute dans un conteneur temporaire. Ce mode permet à l’agent de modifier le projet cloné que vous avez choisi, sans lui donner accès à tout votre dossier personnel ni au socket Docker.

Web / Desktop / mobile
          ↓
AirCode Ø API + auth + tunnel (host)
          ↓
Local tmux / Windows ConPTY  OR  one Docker worker per session

Il s’agit d’un mode d’exécution, pas d’une seconde installation d’AirCode Ø. L’authentification, les données de session, les notifications, les WebSockets, l’accès distant et l’interface restent sur l’hôte.

Où choisir ce mode

• Web : Nouvelle session → Environnement d’exécution.
• Application de bureau : même formulaire de lancement que sur le Web.
• Application mobile native : Nouvelle session → Environnement d’exécution ; le choix est conservé pour chaque connexion enregistrée.
• API : POST /api/sessions accepte executionMode: "local" | "docker".

Les détails de la session indiquent le mode d’exécution et l’image réellement utilisés. Le serveur vérifie le service Docker, l’image et le moteur. Si Docker n’est pas disponible, AirCode Ø ne bascule pas discrètement vers l’exécution locale.

Essayer la version issue du dépôt

Docker Engine ou Docker Desktop doit être lancé :

git clone https://github.com/spartaquant/aircode.git
cd aircode
npm run docker:runtime:build
npm run docker:runtime:check
npm run docker:session:smoke

Redémarrez AirCode Ø, créez une session, puis choisissez Sandbox Docker dans Environnement d’exécution. Si Docker ou l’image manque, le formulaire en indique la raison précise.

Après la première construction, l’image suit les mises à jour d’AirCode Ø. Si une mise à jour apporte de nouvelles versions de Claude Code, Codex, Grok Build ou Kimi Code, ou ajoute un autre outil en ligne de commande (CLI), AirCode Ø reconstruit aircode-session-runtime:local en arrière-plan. Les nouvelles sessions Docker utilisent alors les versions et les moteurs disponibles à ce moment-là.

Pendant l’aperçu, l’image porte le nom aircode-session-runtime:local. Les versions officielles construisent et vérifient des images linux/amd64 et linux/arm64, publient un tag immuable sur Docker Hub, puis inscrivent l’empreinte de l’image dans le manifeste de version signé. Le workflow Docker manuel ne publie que sur le canal preview. Le dépôt public et les identifiants de publication sont configurés ; un tag ne peut être téléchargé qu’après sa première publication réussie.

Lorsqu’un tag public sera disponible, il ne sera pas nécessaire de reconstruire AirCode Ø :

AIRCODE_DOCKER_IMAGE=aircodezero/session-runtime:<version> aircode

Accès du conteneur

AirCode Ø ne copie pas le dépôt dans l’image. Il monte le projet déjà cloné au même chemin absolu dans le conteneur. Les modifications sont donc enregistrées dans votre véritable copie de travail et restent disponibles après l’arrêt du conteneur.

Le conteneur ne reçoit ni l’ensemble de votre dossier personnel, ni le socket Docker, ni les capacités Linux de l’hôte. Son système de fichiers racine est en lecture seule. AirCode Ø limite aussi le nombre de processus, la mémoire et le processeur.

L’API locale d’AirCode Ø reste privée. Un port de contrôle stable, protégé par des capacités, n’accepte que les notifications de fin de session du conteneur concerné, y compris après un redémarrage du serveur de bureau.

Le profil du moteur contient des identifiants et reste accessible en lecture et en écriture depuis le conteneur pendant l’aperçu. L’isolation protège les autres fichiers de l’hôte ; elle ne dissimule pas ces identifiants au moteur ni à un programme malveillant exécuté avec le même compte dans le conteneur.

Déroulement d’une session

1. Le client lit la liste des moteurs disponibles sur l’hôte.
2. L’hôte vérifie Docker, le contrat de l’image et le moteur choisi.
3. AirCode Ø crée un conteneur identifié et une URL de retour limitée à cette session.
4. Le conteneur démarre tmux dans le projet monté.
5. Le WebSocket du terminal existant communique avec cette session tmux par Docker.
6. La fin normale ou l’action Arrêter la session supprime le conteneur. Les modifications du projet et l’historique du moteur restent sur l’hôte.
7. Après un redémarrage d’AirCode Ø, le conteneur est retrouvé et ses notifications de fin de session sont rétablies.

VPN et trafic des serveurs de développement

Le trafic sortant du conteneur suit normalement les règles de routage et de NAT de Docker sur l’hôte. Un VPN installé sur l’hôte le transporte seulement s’il prend en charge le trafic du réseau Docker. Le tunnel géré Hetzner/AirCode Ø sert à accéder à AirCode Ø depuis l’extérieur ; il ne redirige pas automatiquement le trafic sortant du conteneur.

Aucun port du conteneur n’est encore publié. Le transfert authentifié des serveurs de développement par AirCode Ø et le tunnel Hetzner est prévu pour une prochaine étape. Les sessions locales et l’accès distant existants continuent de fonctionner.

Limites de l’aperçu

• Claude Code, Codex, Grok Build et Kimi Code sont inclus pour les sessions Docker ordinaires. Le démarrage est refusé si leur version manque, est illisible ou est trop ancienne.
• Le mode Docker couvre les sessions directes. Les cycles audités restent en exécution locale.
• Linux et macOS sont pris en charge dans cet aperçu. Sous Windows, l’application de bureau garde les sessions locales natives avec ConPTY ; le comportement des chemins Docker n’y est pas encore validé.
• Les fonctions du navigateur de l’hôte et les outils externes d’optimisation des tokens ne sont pas encore transmis aux conteneurs.

Configuration

Gardez le même port de retour tant que des conteneurs fonctionnent. Consultez le dépannage pour connaître les codes d’erreur.

Le service Docker doit rester digne de confiance : une personne qui en prend le contrôle peut contourner l’isolation des conteneurs.