Skip to main content
Exécutez l’interface de ligne de commande (CLI) de Cursor sur un dépôt dans une sandbox CoreWeave. Connectez votre terminal pour travailler de manière interactive, ou exécutez un prompt via le kit de développement logiciel (SDK) Sandboxes et récupérez le résultat. Le processus de la CLI, le workspace et les commandes s’exécutent dans la sandbox. Les requêtes adressées au modèle sont envoyées à Cursor. Cursor prend également en charge les Self-Hosted Machines : le cloud de Cursor y exécute la boucle de l’agent, tandis qu’un worker distinct exécute les appels d’outils.

Prérequis

Avant de commencer, vous devez disposer des éléments suivants :
  • Un jeton d’accès à l’API CoreWeave disposant de l’action SANDBOX_USER pour le chemin cws-agent. Le SDK prend également en charge une clé API Forge pour l’injection de secrets ; voir Choisir comment fournir la clé Cursor.
  • Une clé API utilisateur Cursor et un accès à un modèle pris en charge par la CLI Cursor.
  • L’URL d’un dépôt public. Les dépôts privés nécessitent des identifiants d’authentification Git dans la sandbox.
  • Une connectivité sortante vers Cursor, son hôte de téléchargement et votre hôte Git.
Dans votre terminal local, définissez votre jeton d’accès à l’API CoreWeave :
Cursor lit CURSOR_API_KEY dans la sandbox. Cursor peut transmettre des prompts, le contenu des fichiers et la sortie des outils à son service. Utilisez un dépôt et des identifiants d’authentification adaptés à la tâche.

Exécuter Cursor CLI avec cws-agent

Utilisez cws-agent pour créer une sandbox, y installer Cursor et y attacher votre terminal. L’attachement interactif nécessite un terminal interactif (TTY) sous macOS, Linux ou Windows Subsystem for Linux (WSL). Les terminaux Windows natifs ne sont pas pris en charge. Exportez votre clé Cursor en local. cws-agent la transmet à l’environnement de la sandbox :
  1. Suivez les instructions d’installation de cws-agent.
  2. Remplacez [SANDBOX-NAME] par un nom de session comprenant de 1 à 40 lettres minuscules, chiffres ou traits d’union, et commençant par une lettre ou un chiffre. Remplacez [REPOSITORY-URL] par l’URL de votre dépôt :
    Cursor s’ouvre dans /workspace/project. Si une invite vous demande de faire confiance au workspace, acceptez-la. --permission-mode native conserve les paramètres d’approbation de Cursor ; sans cette option, cws-agent utilise --force. --no-config-sync évite d’importer vos skills locaux et votre configuration Model Context Protocol (MCP).
  3. Demandez à Cursor de créer un fichier que vous pourrez récupérer :
    Approuvez toutes les invites liées à la tâche. Quittez Cursor avec /exit. Dans votre terminal local, lisez le fichier :
    La sortie doit être Hello from CoreWeave. Quitter Cursor n’arrête pas la sandbox.
  4. Après avoir quitté toutes les sessions Cursor dans la sandbox, supprimez les fichiers de socket worker.sock laissés par Cursor, enregistrez le workspace et arrêtez les ressources de calcul :
    Le nettoyage supprime les fichiers de socket susceptibles de bloquer la création d’instantanés. down prend un instantané avant d’arrêter la sandbox. Si la création de l’instantané échoue, la sandbox continue de s’exécuter. Corrigez l’erreur et relancez down avant toute restauration.
  5. Pour revenir au workspace enregistré, gardez la variable CURSOR_API_KEY exportée localement et exécutez :
    Demandez à Cursor de lire le fichier sandbox-proof.txt pour vérifier qu’il a bien été restauré. Lorsque vous avez terminé, quittez Cursor et répétez les commandes de nettoyage et down.

Exécuter un prompt sans surveillance

Choisissez un nouveau nom de session. Dans votre terminal local, lancez la commande avec --detach pour ne pas vous rattacher au terminal, puis envoyez un prompt :
Par défaut, cws-agent run transmet l’option --force de Cursor afin que la tâche headless puisse écrire des fichiers sans validation interactive. Les règles de refus explicites de Cursor restent appliquées. Pour attacher votre terminal à la session en cours d’exécution, exécutez :
Une fois l’opération terminée, quittez Cursor si vous y êtes attaché, lisez le résultat avec cws-agent exec, puis nettoyez les sockets et enregistrez avec cws-agent down, comme indiqué dans Exécuter Cursor CLI avec cws-agent.

Exécuter une tâche avec le SDK Sandboxes

Utilisez le SDK Sandboxes pour gérer directement une tâche. Cette approche crée une sandbox dédiée, exécute Cursor en mode print, récupère le fichier, puis arrête la sandbox dans un bloc de nettoyage. Elle ne configure pas d’instantanés et ne requiert pas cws-agent.

Choisir comment fournir la clé Cursor

Les deux scripts prennent un mode d’authentification comme premier argument : Ces exemples utilisent le placement sans serveur. L’injection de secrets Forge nécessite l’authentification Forge et le placement sans serveur. Pour le mode forge, demandez à un administrateur Forge d’ajouter votre clé Cursor en tant que secret d’équipe. Dans votre terminal local, remplacez [FORGE-TEAM] par le nom de votre équipe et [CURSOR-SECRET-NAME] par le nom du secret :
Votre clé API Forge doit avoir accès à cette équipe. Les scripts mappent le secret nommé sur CURSOR_API_KEY dans la sandbox. Voir Utiliser les secrets Forge. Pour le mode coreweave, définissez CWSANDBOX_API_KEY sur un jeton d’accès à l’API CoreWeave disposant de l’action IAM SANDBOX_USER. Voir Choisir et obtenir des identifiants d’authentification. Exportez votre clé Cursor dans ce même terminal local :
Le chemin coreweave transmet la clé Cursor sous forme de valeur d’environnement en clair dans la requête de création de la sandbox. Il s’agit d’une exception à la recommandation du SDK, qui préconise d’utiliser des références de secret pour les identifiants d’authentification. N’utilisez ce chemin que si votre politique de gestion des identifiants d’authentification l’autorise. Évitez de journaliser la requête ou de versionner la clé.

Installer un client

Choisissez un langage et installez le client en local :
Utilisez Python 3.11 ou version ultérieure, ainsi que uv. Dans un nouveau répertoire de projet, exécutez :

Créer, exécuter et nettoyer

Enregistrez le script correspondant à votre langage sous le nom de fichier indiqué. Chaque script installe Cursor, clone le dépôt passé en ligne de commande, puis demande à Cursor d’écrire le fichier sandbox-proof.txt. Les options --print, --force et --trust activent une sortie non interactive, autorisent la modification des fichiers et marquent le workspace comme fiable. N’utilisez cet exemple qu’avec un dépôt de confiance. Voir le mode headless de Cursor.
run_cursor_sandbox.py
Dans le terminal local où vous avez défini vos identifiants d’authentification, remplacez [AUTH-MODE] par forge ou coreweave, et [REPOSITORY-URL] par l’URL de votre dépôt :
Le script affiche la réponse de Cursor, suivie du contenu du fichier, Hello from CoreWeave. Le bloc de nettoyage appelle stop() même si la configuration ou l’exécution lève une erreur. Récupérez les éventuels fichiers supplémentaires avant l’exécution du bloc de nettoyage. Pour des résultats plus volumineux, utilisez les opérations sur les fichiers. La durée de vie de 2 heures correspond à une durée maximale en temps réel, démarrage compris. Chaque commande dispose en outre de son propre délai d’expiration. Modifier le délai d’expiration d’une commande ne prolonge pas la durée de vie du bac à sable.

Dépannage

Effectuez les vérifications suivantes pour résoudre les problèmes courants :
  • Si la création de la sandbox échoue, vérifiez l’identifiant d’authentification associé au mode d’authentification sélectionné.
  • Si un secret Forge ne peut pas être résolu, vérifiez FORGE_TEAM, CURSOR_SECRET_NAME, ainsi que l’accès de votre clé API à l’équipe.
  • Si Cursor signale une erreur d’authentification, vérifiez la clé dans votre secret Forge ou dans la variable locale CURSOR_API_KEY, selon le mode, et assurez-vous que votre compte a accès au modèle.
  • Si un prompt du SDK se contente de proposer des modifications, assurez-vous que la commande Cursor inclut --force.
  • Si l’installation, le clonage ou les requêtes au modèle échouent, vérifiez la connectivité sortante et les identifiants d’authentification du fournisseur. Pour un placement sur CoreWeave Kubernetes Service (CKS), la politique de votre exécuteur doit autoriser les destinations requises.

Étapes suivantes

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