Aussi en: English, Español, Português, 日本語, Deutsch, 한국어, 简体中文, Italiano, हिन्दी · Tous les guides en français

Transparence : nous développons Carbon Forge chez 100monkeys.ai, lisez donc ceci comme le récit de son fabricant. Ce guide a été rédigé par l'un de nos agents d'IA puis relu par l'entreprise ; cette édition française est une traduction du guide original en anglais. Les étapes Carbon Forge citent la documentation publique, en anglais avec la traduction à côté ; la configuration de chaque client est copiée de la documentation de ce client, liée à côté. La dernière section liste ce à quoi la documentation ne répond pas.

Ce que vous construisez

Un workspace, plusieurs clients, un jeton chacun. Le serveur Carbon Forge parle Streamable HTTP, "binds every call to a workspace via a bearer token" (rattache chaque appel à un workspace via un bearer token), et "tools honor the cap exactly as a human session does: there is no agent-only privilege" (les outils respectent le plafond exactement comme une session humaine : il n'y a aucun privilège réservé aux agents) (MCP overview). Tout client capable d'envoyer un en-tête HTTP peut se brancher. Claude Code a son propre guide : Connecter Claude Code à Carbon Forge par MCP.

Étape 1. Créer un jeton par client

Connectez-vous sur carbonforge.dev/login, ouvrez les paramètres, choisissez API tokens, le workspace, un plafond de rôle et une portée d'outils, et "name the token after the agent or environment that will hold it" (nommez le jeton d'après l'agent ou l'environnement qui le détiendra) (MCP tokens). Un jeton par client signifie que le journal d'audit, qui enregistre "every tool call ... under the token identity" (chaque appel d'outil sous l'identité du jeton), vous dit quel outil a fait quoi, et vous pouvez en révoquer un sans toucher aux autres.

Choisissez les portées selon le travail (MCP token scopes) : Basic LLM memory pour un assistant qui prend des notes, Read-only memory ou SCM reader pour un client qui ne fait que lire, SCM agent pour un client qui écrit du code sur des lanes. La documentation conseille : "Default to the narrowest preset that still covers what the client needs." (Partez par défaut du préréglage le plus étroit qui couvre encore ce dont le client a besoin.)

Étape 2. Garder chaque jeton dans une variable d'environnement

Le secret "is shown once, then only the prefix." (est affiché une fois, puis seulement le préfixe.) Les deux clients ci-dessous peuvent le lire depuis l'environnement, pour qu'il ne se retrouve jamais dans un fichier de configuration qui finit dans un commit :

export CARBON_FORGE_TOKEN=‹token for this client›

Étape 3. Configurer Cursor

Cursor lit les serveurs MCP dans mcp.json : ~/.cursor/mcp.json pour tous les projets, ou .cursor/mcp.json dans un seul projet. Un serveur distant prend url et headers, et Cursor résout ${env:NAME} dans les deux (documentation MCP de Cursor) :

{
  "mcpServers": {
    "carbon-forge": {
      "url": "https://carbonforge.dev/api/mcp",
      "headers": {
        "Authorization": "Bearer ${env:CARBON_FORGE_TOKEN}"
      }
    }
  }
}

Étape 4. Configurer Codex

Codex garde les serveurs MCP dans ~/.codex/config.toml, ou .codex/config.toml dans un projet de confiance. Un serveur Streamable HTTP prend url, et bearer_token_env_var donne le "environment variable name for a bearer token to send in Authorization" (nom de la variable d'environnement du bearer token à envoyer dans Authorization) (documentation MCP de Codex) :

[mcp_servers.carbon_forge]
url = "https://carbonforge.dev/api/mcp"
bearer_token_env_var = "CARBON_FORGE_TOKEN"

Étape 5. Configurer tout autre client MCP

Pour Claude Desktop, la documentation de Carbon Forge dit : "add an MCP server entry pointing at the instance URL with the token in the Authorization header." (ajoutez une entrée de serveur MCP pointant vers l'URL de l'instance avec le jeton dans l'en-tête Authorization.) Pour les plugins d'IDE : "point the plugin at the same MCP endpoint; Streamable HTTP works over plain HTTPS." (pointez le plugin vers le même endpoint MCP ; Streamable HTTP fonctionne en HTTPS simple.) Quel que soit le format de fichier du client, voici les trois valeurs à saisir :

Endpoint:  https://carbonforge.dev/api/mcp
Transport: Streamable HTTP
Header:    Authorization: Bearer ‹token for this client›

Étape 6. Vérifier chaque client avec cortex.ground

Demandez à chaque client d'appeler cortex.ground. Il renvoie "the calling identity, what the bearer can do, what is reachable" (l'identité appelante, ce que le porteur peut faire, ce qui est accessible) (cortex.ground). Comparez les réponses : chaque client doit montrer le même workspace et les capacités que sa portée autorise. Un client au jeton erroné est refusé ; la documentation dit qu'un mauvais jeton est "refused outright rather than quietly treated as anonymous" (refusé d'emblée plutôt que traité en silence comme anonyme).

Étape 7. Nommer le workspace à chaque appel

Chaque jeton retient son propre workspace courant, donc "every agent has its own active workspace and they do not collide" (chaque agent a son propre workspace actif et ils ne se gênent pas) (MCP token scopes). Cela veut aussi dire que deux clients peuvent pointer sans bruit vers des workspaces différents. Demandez à chaque agent de passer workspace à chaque appel : les outils l'acceptent et il ne déplace jamais le pointeur.

Étape 8. Donner à chaque agent qui écrit sa propre lane

Les notes partagées sont des pages ; le code partagé est l'endroit où les clients se heurtent. Dans Carbon Forge, un agent ouvre une lane au lieu de cloner : "A lane costs nothing to open and holds no copy, so one per task, or one per agent, is the expected use" (ouvrir une lane ne coûte rien et elle ne contient aucune copie : une par tâche, ou une par agent, est l'usage prévu) (Working in lanes). Carbon Forge ne fusionne jamais le texte tout seul ; un patch qui ne s'applique plus revient comme un conflit nommé, et une intégration est un seul changeset, tout ou rien. L'agent de Cursor et Codex peuvent travailler sur le même trunk sans fusion silencieuse entre eux.

Ce que la documentation laisse sans réponse

Aucune configuration propre à un client. La documentation de Carbon Forge cite Claude Desktop et les plugins d'IDE en une phrase chacun et ne donne aucun fichier pour Cursor ou Codex ; les extraits ci-dessus viennent de la documentation de Cursor et de Codex.
L'endpoint d'une instance sur son propre hôte ou un domaine personnalisé n'est pas indiqué ; https://carbonforge.dev/api/mcp est celui que nomme la documentation.
How MCP works montre un appel curl vers /mcp, alors que la page sur l'accès anonyme utilise /api/mcp.
Si les jetons expirent d'eux-mêmes n'est pas dit ; comment en révoquer un, si.
La connexion OAuth pour les clients MCP n'est pas mentionnée ; la méthode documentée est un bearer token.

Connecter Cursor, Codex et tout client MCP à un seul workspace Carbon Forge