Utiliser un agent IA avec une sandbox

Une sandbox sert à donner à un agent IA une machine jetable et isolée : il peut installer des paquets, lancer Docker ou exécuter du code sans risque pour votre ordinateur. Deux façons de travailler :

1. L'agent tourne dans la sandbox : vous vous connectez et lancez claude, codex, etc.
2. L'agent tourne sur votre machine et exécute ses commandes dans la sandbox via ssh yorkhost.sh '…'.

1. Lancer un agent dans la sandbox

Connectez-vous (ssh yorkhost.sh), placez-vous dans votre projet, puis lancez l'agent de votre choix :

Agent	Commande
Claude Code	claude
OpenAI Codex	codex
OpenCode	opencode
Cursor CLI	cursor-agent
Gemini CLI	gemini

Au premier lancement, chaque agent vous demande de vous connecter à votre propre compte chez son éditeur (Anthropic, OpenAI, Cursor, Google…) : suivez l'invite, qui affiche en général un lien à ouvrir dans le navigateur de votre ordinateur. Vous pouvez aussi fournir une clé API par variable d'environnement, par exemple :

export ANTHROPIC_API_KEY=…   # Claude Code
export OPENAI_API_KEY=…      # Codex
export GEMINI_API_KEY=…      # Gemini CLI

L'abonnement ou la consommation de l'agent restent facturés par son éditeur : YorkHost fournit la machine, pas le modèle.

Vos identifiants sont dans la VM

Les jetons de connexion et clés API que vous saisissez sont stockés dans la sandbox (et copiés sur le VPS si vous la gardez, car ils sont dans /home/agent). Préférez une clé dédiée, avec un plafond de dépense, que vous révoquerez après l'essai. Ne donnez jamais à l'agent plus d'accès que nécessaire (dépôts Git, clés cloud…).

Récupérer votre code

Clonez vos dépôts directement dans la sandbox (git clone, gh repo clone après gh auth login), ou envoyez vos fichiers avec scp / rsync. Git en HTTPS et en SSH fonctionne.

Garder l'agent actif

Lancez l'agent dans tmux : si votre connexion coupe, il continue de travailler et vous le retrouvez avec tmux attach. Pensez à l'heure d'arrêt (60 minutes après la création) : poussez régulièrement votre travail sur Git, ou gardez la sandbox en VPS pour continuer.

Tester le résultat

Demandez à l'agent de démarrer l'application sur 0.0.0.0:8080 (ou un autre port de preview) : vous l'ouvrez aussitôt dans votre navigateur sur https://<id>-8080.yorkhost.sh.

2. Piloter la sandbox depuis un agent local

Un agent qui tourne sur votre ordinateur (Claude Code, Cursor, un script…) peut utiliser la sandbox comme environnement d'exécution isolé : chaque commande passée à ssh yorkhost.sh s'exécute dans la sandbox, avec son code de sortie.

ssh -o StrictHostKeyChecking=accept-new yorkhost.sh 'git clone https://github.com/moi/projet && cd projet && npm ci && npm test'

Quelques consignes utiles à donner à votre agent :

• Obtenir l'état, l'adresse de preview et les échéances en JSON : ssh status@yorkhost.sh.
• Utiliser l'identifiant de la sandbox (ssh sbx…@yorkhost.sh) une fois qu'elle existe, pour toujours viser la même.
• Ne jamais lancer ssh destroy@yorkhost.sh ni commander quoi que ce soit sans votre accord.

Un agent relié à votre compte YorkHost

Si votre agent est connecté à votre compte YorkHost (serveur MCP ou clé API), il peut aussi créer des sandboxes, lister leurs URLs et proposer de les garder en VPS, toujours avec votre validation avant toute commande. Voir API et MCP.

Bonnes pratiques

• Une sandbox par tâche : une clé SSH n'a qu'une sandbox à la fois. Supprimez-la (ssh destroy@yorkhost.sh) avant d'en demander une nouvelle.
• Rien d'important uniquement dans la sandbox : elle est supprimée avec ses fichiers au bout de 24 h, et n'est pas sauvegardée.
• Réseau sortant limité : l'agent peut télécharger (web, Git, registres npm/PyPI/Docker), mais pas joindre une base de données distante ou un serveur mail. Détails dans Limites et sécurité.