Lisez vos cartes et documents dans Codex grâce à MCP. Pour une mission de code lancée depuis Stellary, connectez Desktop au dépôt local et suivez le résultat dans la carte.
Codex
Connecté
Stellary
Projet de lancement
MCP donne au client accès au projet. Desktop permet à Stellary de lancer une mission dans le dépôt lié. Choisissez le parcours correspondant à votre besoin.
01
Installez Codex et connectez la CLI sur la machine cible.
02
Actualisez Stellary Desktop jusqu’à ce que le runner soit prêt.
03
Rattachez le projet au dossier exact du dépôt local.
04
Affectez la card à l’agent configuré avec Codex.
05
Consultez la trace et relisez le résultat livré.
Mission STL-128
Installez Codex et connectez la CLI sur la machine cible.
Liste de contrôle
Contexte lié
Le lien projet-dépôt indique au runner où la mission doit s’exécuter.
Codex travaille localement pendant que Stellary conserve la card, le contexte, l’état d’exécution et la revue partagée.
Le lien projet-dépôt indique au runner où la mission doit s’exécuter.
Seuls les modèles prêts et partagés sont proposés aux membres et aux agents.
Les états en attente, en cours, bloqué, échoué, annulé et terminé restent explicites.
La commande login ouvre le consentement Stellary dans le navigateur. Sélectionnez votre espace de travail et les accès nécessaires.
codex mcp add stellary --url https://api.stellary.co/mcp
codex mcp login stellary
codex mcp listConfiguration dans ~/.codex/config.toml. Définissez STELLARY_MCP_TOKEN dans l’environnement du client avant son lancement. Pour découvrir le projet en votre nom, un PAT projects:read suffit ; une mission d’agent demande une identité et des permissions adaptées.
[mcp_servers.stellary]
url = "https://api.stellary.co/mcp"
bearer_token_env_var = "STELLARY_MCP_TOKEN"Documentation de configuration vérifiée le .
Sources et conditions à consulter
Installez une version récente de Codex et vérifiez que son aide propose les commandes MCP ci-dessus. Le compte du fournisseur IA et la connexion à Stellary sont deux accès distincts.
Créez un projet Stellary avec une carte de test, un objectif précis et un document de contexte. Pour lire ces données par MCP, aucun dépôt local ni Desktop n’est nécessaire.
Après le consentement OAuth, ouvrez /mcp dans le client et vérifiez que Stellary est disponible. Demandez ensuite : « Appelle stellary_init, liste les projets auxquels j’ai accès, puis résume les critères de la carte de test. Ne modifie aucun objet. »
La vérification réussit quand le client retrouve le bon projet et les critères réellement écrits dans la carte. Utilisez les identifiants retournés par list_projects pour les appels suivants. Un serveur ajouté à la configuration ne prouve pas encore cet accès.
Pour lancer Codex depuis une carte, installez et authentifiez sa CLI sur la machine du dépôt. Dans Stellary Desktop, actualisez les moteurs, partagez le moteur disponible avec l’espace de travail, puis liez le dossier Git exact au projet.
Configurez un agent en exécution locale avec Codex. Préparez une carte : « Lis le README et les scripts du dépôt. Propose un plan de vérification avec les commandes pertinentes, sans modifier de fichier. » Lancez la mission et attendez son retour dans l’activité de la carte.
Une réponse 401 indique un accès absent, expiré ou révoqué. Reconnectez OAuth, ou vérifiez le jeton et la variable d’environnement dans le processus du client.
Une réponse 403 demande de vérifier les scopes, le rôle et l’accès au projet. Si un outil n’est pas annoncé, vérifiez aussi l’identité choisie et la politique de l’agent.
Une connexion MCP distante donne accès au projet hébergé. Une mission Desktop s’exécute sur la machine connectée ; cela ne signifie pas que le modèle IA tourne localement.
Le fournisseur du modèle peut recevoir le contexte nécessaire à la demande et appliquer ses propres conditions d’accès ou de facturation. Vérifiez le modèle choisi et les données autorisées avant d’envoyer un document sensible.
Depuis Codex, une identité d’agent déjà autorisée a initialisé Stellary, ouvert une mission dans le projet de démonstration, créé une carte avec des données fictives puis relu son titre et sa description par MCP. Les deux champs correspondaient au contenu envoyé.
Ce contrôle vérifie la création et la lecture d’une carte sur le service hébergé. Il ne valide ni une nouvelle connexion OAuth, ni une mission Desktop, ni la livraison autonome d’une application. Le protocole et ses limites sont disponibles dans la fiche de contrôle ci-dessous.
Session Codex autonome
Mission gérée par Stellary
Source du travail
Session Codex autonome
Demande saisie dans la session.
Mission gérée par Stellary
Carte avec responsable, contexte et critères.
Dépôt
Session Codex autonome
Dossier choisi dans le client.
Mission gérée par Stellary
Dépôt explicitement lié au projet.
État
Session Codex autonome
Suivi dans le client.
Mission gérée par Stellary
Suivi dans le tableau et l’activité de la carte.
Revue
Session Codex autonome
Dans le client ou le dépôt.
Mission gérée par Stellary
Rattachée à la carte et à la mission.
Stellary se connecte à la CLI Codex installée et authentifiée sur votre machine. Les modèles disponibles dépendent de ce runner local.
Oui, si chaque projet pointe vers le bon dépôt et si la machine est autorisée et disponible.
Oui. L’annulation fait partie du cycle de mission et le runtime doit renvoyer un état visible dans Stellary.
Oui. Ajoutez le serveur distant puis connectez Stellary avec OAuth, ou utilisez un jeton via une variable d’environnement. Ce parcours donne accès aux outils projet ; Desktop permet de lancer les missions depuis Stellary.
Liez un dépôt et lancez la première mission de code bornée.
Créer votre première mission