Skip to main content
Exécutez OpenCode sur un dépôt dans une sandbox CoreWeave. Envoyez une tâche depuis votre terminal, vérifiez les fichiers produits et enregistrez le Workspace pour le réutiliser ultérieurement. Le processus de l’agent, le Workspace et les commandes s’exécutent dans la sandbox. Les requêtes adressées au modèle sont envoyées au fournisseur que vous avez configuré.

​
Prérequis

Avant de commencer, vous devez disposer des éléments suivants :

​
Choisir les identifiants d’authentification du sandbox

Ces exemples utilisent la capacité sans serveur. Les deux types d’identifiants d’authentification prennent en charge les bacs à sable sans serveur. Pour obtenir l’un ou l’autre, consultez Choisir et obtenir des identifiants d’authentification. Les identifiants d’authentification de l’agent et du fournisseur de modèles se configurent séparément.
Remplacez [WANDB-API-KEY] par votre clé API Forge, puis exportez-la dans votre terminal local :
cws-agent utilise l’authentification Forge lorsque CWSANDBOX_API_KEY n’est pas défini.

​
Lancer OpenCode avec cws-agent

Utilisez cws-agent pour installer OpenCode dans une sandbox, cloner votre dépôt dans le répertoire /workspace/project et configurer un point de montage d’instantanés pour les instantanés du système de fichiers. Choisissez l’une des options de fournisseur suivantes. Remplacez [SANDBOX-NAME] par un nom de session composé de 1 à 40 lettres minuscules, chiffres ou traits d’union. Le nom doit commencer par une lettre ou un chiffre. Remplacez [REPOSITORY-URL] par l’URL de votre dépôt public. Serverless Inference est le fournisseur recommandé pour ce guide. Il vous permet d’accéder à des modèles ouverts hébergés. Vous pouvez aussi utiliser n’importe quel modèle et fournisseur pris en charge par OpenCode. Dans ce cas, suivez la section Utiliser un autre fournisseur de modèles. Remplissez les prérequis de Serverless Inference, notamment la création d’un projet Forge, et vérifiez vos crédits d’inférence disponibles. Définissez une clé API Forge pour l’inférence. Cet exemple sélectionne explicitement GLM 5.2 :
Le préréglage --wandb configure le point de terminaison d’inférence de Forge et limite OpenCode à ce fournisseur. Ce préréglage de la CLI lit WANDB_API_KEY et la transmet à la sandbox pour l’inférence. L’accès à la sandbox s’effectue avec l’identifiant d’authentification sélectionné à l’étape Choisir les identifiants d’authentification de la sandbox. Pour choisir un autre modèle Forge, remplacez zai-org/GLM-5.2 par un ID figurant dans la liste des modèles disponibles.

​
Utiliser un autre fournisseur de modèles

Pour utiliser un autre fournisseur, omettez --wandb et --wandb-model lors de la création de la sandbox. Exportez localement la clé API de ce fournisseur. Par exemple, choisissez l’une de ces options et remplacez la valeur de substitution de la clé :
Dans les deux champs, remplacez [PROVIDER-ID]/[MODEL-ID] par votre identifiant de modèle OpenCode, avec le préfixe de fournisseur anthropic/ ou openai/ selon le cas. Le champ small_model définit le modèle utilisé pour les tâches légères, comme la génération de titres. Voir Modèles OpenCode.
Si elles sont définies, cws-agent transmet ANTHROPIC_API_KEY et OPENAI_API_KEY. Pour les fournisseurs dont les clés ne sont pas transmises automatiquement, suivez leur configuration de fournisseur OpenCode et utilisez --env-passthrough [VARIABLE-NAME] pour transmettre d’autres variables d’environnement. Les deux options de lancement affichent session ready. une fois la configuration terminée. --detach laisse la sandbox s’exécuter sans ouvrir l’interface du terminal ni importer les compétences locales ni la configuration Model Context Protocol (MCP). La durée de vie de 2 heures correspond à une limite en temps réel, configuration comprise. Arrêtez les ressources de calcul lorsque vous avez terminé.

​
Exécuter une tâche et vérifier le résultat

Depuis votre terminal local, demandez à OpenCode d’écrire puis de lire un fichier :
Cette commande exécute OpenCode sans terminal interactif. --permission-mode native conserve les autorisations configurées dans OpenCode. Sans cette option, cws-agent accepte par défaut les demandes d’approbation. Si votre politique OpenCode exige une approbation pour la tâche, utilisez une session interactive pour l’approuver. Voir Autorisations OpenCode. Vérifiez le fichier lui-même, indépendamment de la réponse de l’agent :
Vous devriez obtenir la sortie Hello from CoreWeave. Avant d’arrêter les ressources de calcul, récupérez une copie locale :

​
Facultatif : travailler de manière interactive

Depuis un terminal interactif sous macOS ou Linux, ouvrez OpenCode dans le même Workspace :
L’option --no-config-sync ignore les compétences locales et les importations MCP. Envoyez des prompts et approuvez des actions dans OpenCode, puis utilisez /exit pour revenir à votre terminal local. Lorsque vous quittez OpenCode, la sandbox continue de s’exécuter. Relancez la commande de connexion pour rouvrir OpenCode. Aucune conversation précédente n’est sélectionnée automatiquement. Pour l’historique des conversations et les commandes de reprise, consultez Sessions cws-agent.

​
Enregistrer, arrêter et restaurer

Une fois l’agent terminé, créez un instantané du Workspace et arrêtez les ressources de calcul :
down enregistre le répertoire /workspace avant d’arrêter la sandbox. Si l’instantané échoue, la sandbox continue de s’exécuter. Examinez l’erreur, corrigez-la, puis effectuez une nouvelle tentative. Pour arrêter la sandbox sans attendre d’instantané explicite, exécutez :
Ne comptez pas sur cette commande pour enregistrer les modifications. Copiez les résultats ailleurs ou vérifiez qu’un instantané est terminé avant l’arrêt. La restauration nécessite un instantané terminé. Pour revenir à un Workspace enregistré avec l’inférence Forge, assurez-vous que WANDB_API_KEY est toujours exportée dans votre terminal local, puis exécutez :
Utilisez la même valeur --wandb-model que lors du lancement. Si vous l’omettez en utilisant --wandb, la restauration sélectionne le modèle par défaut du préréglage. Pour un autre fournisseur, exportez à nouveau sa clé et OPENCODE_CONFIG_CONTENT, puis exécutez :
La restauration crée un nouveau sandbox à partir du Workspace enregistré. Fournissez de nouveau les identifiants d’authentification définis uniquement dans l’environnement. Les instantanés peuvent contenir les connexions OpenCode enregistrées et les données de conversation, mais ils ne conservent pas les processus en cours d’exécution. Relancez la vérification du fichier pour confirmer que le fichier sandbox-proof.txt a bien été conservé. Poursuivez avec cws-agent run ou la commande de connexion interactive. Une fois terminé, arrêtez le sandbox restauré avec cws-agent down.

​
Dépannage

Si la configuration ou une tâche échoue, effectuez les vérifications suivantes :
  • Échec de l’authentification à la sandbox : vérifiez l’identifiant d’authentification de sandbox sélectionné et votre accès au compte.
  • Échec des requêtes vers les modèles Forge : vérifiez votre accès à l’inférence, vos crédits et l’ID du modèle. L’accès à la sandbox ne suffit pas à lui seul à obtenir l’accès à l’inférence.
  • Un autre fournisseur n’est pas disponible : démarrez une nouvelle session sans --wandb. Le préréglage Forge est enregistré dans le Workspace : l’omission de --wandb lors de la restauration ne le supprime donc pas. Pour un Workspace existant, voir Configuration du préréglage Forge.
  • Une tâche en mode headless nécessite une approbation : connectez-vous de manière interactive et répondez aux invites d’approbation d’OpenCode avant de continuer.

​
Étapes suivantes

Pour plus d’informations, consultez les guides suivants :
Dernière modification le 20 octobre 2026