Connecteur MCP

repo-harness embarque un serveur MCP qui donne à ChatGPT et à Codex un accès en lecture seule à vos dépôts enregistrés — les fichiers de workflow PLUS l’arborescence du dépôt, la recherche de texte et le contenu des fichiers — tandis que les écritures restent limitées aux artefacts de workflow (plans, sprints, contrats, handoffs). ChatGPT se connecte en HTTP avec OAuth via un point de terminaison public /mcp ; Codex se connecte localement en stdio sans tunnel. Le sidecar n’est pas un agent de codage distant — il prépare les artefacts de workflow pour l’hôte d’agent local.

Prérequis

Un dépôt adopté

Exécutez depuis un dépôt qui a déjà exécuté repo-harness adopt. Voir Installation.

repo-harness sur le PATH

La CLI repo-harness doit être installée et résolvable sur le PATH de votre shell.

Mode Développeur ChatGPT

Un espace de travail ChatGPT avec accès au Mode Développeur et aux Connecteurs MCP personnalisés.

Un point de terminaison /mcp public

Une URL HTTPS publique stable /mcp pour un usage récurrent de ChatGPT. Codex local utilise stdio sans tunnel.

1. Démarrer le serveur MCP local

1. Lancez le serveur en profil planificateur en HTTP sur localhost :

   repo-harness mcp serve --repo . --transport http --host 127.0.0.1 --port 8765 --profile planner

2. Confirmez qu’il est sain :

   curl http://127.0.0.1:8765/health

3. Lisez la phrase secrète OAuth locale — ChatGPT la demandera pendant l’autorisation :

   jq -r .passphrase .repo-harness/mcp.oauth.json

4. Testez à blanc la découverte OAuth :

   curl http://127.0.0.1:8765/.well-known/oauth-protected-resource/mcp

Gardez la phrase secrète hors du contrôle de version

.repo-harness/mcp.oauth.json est un fichier local ignoré. Ne committez jamais la phrase secrète et ne la collez jamais dans des outils de suivi de tickets, des PR ou des logs partagés.

2. Choisir un point de terminaison de tunnel

ChatGPT a besoin d’une URL HTTPS publique se terminant par /mcp. Préférez un nom d’hôte stable pour un usage récurrent — l’URL d’un tunnel rapide change, et ChatGPT traite chaque nouvelle URL comme une application Connecteur différente.

Stable (nommé)

cloudflared tunnel login
cloudflared tunnel create repo-harness-mcp
cloudflared tunnel route dns repo-harness-mcp repo-harness-mcp.example.com
cloudflared tunnel run --url http://127.0.0.1:8765 repo-harness-mcp

Puis enregistrez le point de terminaison stable dans la config locale ignorée :

repo-harness mcp setup chatgpt --repo . --endpoint <https-url>/mcp

Quick (ponctuel)

cloudflared tunnel --url http://127.0.0.1:8765

Utilisez l’URL HTTPS affichée avec /mcp ajouté comme URL de votre Connecteur :

<https-tunnel-url>/mcp

3. Créer le Connecteur ChatGPT

1. Ouvrez les Paramètres ChatGPT.
2. Activez le Mode Développeur si votre espace de travail l’expose.
3. Allez dans Connecteurs.
4. Créez un Connecteur nommé repo-harness.
5. Collez l’URL HTTPS du Connecteur se terminant par /mcp.
6. Configurez l’authentification du Connecteur en OAuth.
7. Cliquez sur Scan Tools.
8. Quand la page d’autorisation s’ouvre, saisissez la phrase secrète depuis .repo-harness/mcp.oauth.json.
9. Attendez la fin du scan des outils, puis créez le Connecteur.
10. Gardez les confirmations d’écriture activées.

4. Câbler Codex (stdio)

Codex s’exécute localement et n’a besoin d’aucun tunnel — il parle stdio directement. Générez automatiquement la config :

repo-harness mcp setup codex --repo . --scope project

Cela écrit .codex/config.toml avec une entrée de serveur stdio repo_harness et la liste des outils autorisés.

5. Runner d’agent en mode dev (opt-in)

Désactivé par défaut — local uniquement

Le Connecteur planificateur n’exécute pas Codex ni Claude. N’activez le runner dev que si vous voulez intentionnellement que ChatGPT déclenche un agent local via MCP. Gardez-le derrière le Mode Développeur local avec des confirmations par appel, et n’exposez jamais un tunnel d’orchestrateur à des utilisateurs non approuvés.

repo-harness mcp serve --repo . --transport http --host 127.0.0.1 --port 8765 \
  --profile orchestrator --enable-dev-runner --dev-runner-agents codex

Ou via une surcharge d’environnement :

REPO_HARNESS_MCP_DEV_RUNNER=1 REPO_HARNESS_MCP_DEV_RUNNER_AGENTS=codex,claude \
  repo-harness mcp serve --repo . --transport http --profile orchestrator

Quand il est activé, le serveur expose run_agent_goal. Il lit uniquement .ai/harness/handoff/codex-goal.md et exécute ce handoff fixe via la CLI locale autorisée. Ce n’est pas un shell arbitraire.

Ce qui est exposé

Le profil planner est principalement en lecture : il peut lire vos dépôts enregistrés et écrire uniquement des artefacts de planification — jamais le code source d’application, les manifestes, les fichiers de verrouillage, la config CI, les secrets, ni les fichiers hors d’une racine de dépôt autorisée.

• Lectures de workflow : harness_status, harness_doctor, read_workflow_file, list_workflow_files, latest_handoff, latest_checks
• Lectures de dépôt (lecture seule) : reader_status, list_allowed_roots, open_workspace, tree, search_text, read_text — parcourez et recherchez dans le dépôt, pas seulement les fichiers de workflow
• Écritures de planification : write_prd_from_idea, write_checklist_sprint, prepare_codex_goal_from_sprint

Les globs de refus restent actifs même lorsque les lectures de dépôt sont activées : .env, les clés privées, les clés SSH, les identifiants, les secrets, .git, et la sortie de dépendances/build ne sont jamais retournés.

Dépôts enregistrés et multi-dépôts

Un seul Connecteur peut servir tous les dépôts que vous avez adoptés. repo-harness adopt et repo-harness init enregistrent un dépôt dans ~/.repo-harness/registered-repos.json ; discover_harness_repos les liste, et les outils de lecture acceptent un repo_path pour cibler un dépôt spécifique. La lecture intégrale du disque est dépréciée — l’ancien fullDiskRead: true échoue désormais de façon fermée ; ajoutez explicitement des racines supplémentaires hors dépôt avec --allow-root.

La configuration au niveau utilisateur (repo-harness mcp setup chatgpt sans --repo, stockant la config et l’auth sous ~/.repo-harness/) fonctionne pour les déploiements en Mode Développeur. L’auth HTTP prend en charge OAuth — avec rotation de jeton de rafraîchissement offline_access — et un mode de compatibilité url-token.

La chaîne de planification attendue : idée → write_prd_from_idea → write_checklist_sprint → prepare_codex_goal_from_sprint → exécution locale Codex /goal.

Dépannage

• Si ChatGPT ne parvient pas à se connecter, vérifiez que l’URL du tunnel est en HTTPS et se termine par /mcp.
• Si ChatGPT renvoie une erreur d’autorisation, vérifiez que la découverte OAuth fonctionne et relancez le flux de phrase secrète.
• Si des outils sont manquants, redémarrez repo-harness mcp serve et rescannez les outils.
• Si les écritures échouent, vérifiez que le chemin cible est un fichier PRD, sprint, plan ou handoff approuvé.
• Si ChatGPT a généré de la prose au lieu de cartes de tâche Sprint en liste de contrôle, demandez-lui d’utiliser write_checklist_sprint.
• Si Codex ne voit pas le serveur, exécutez repo-harness mcp setup codex --repo . --scope project.

Étapes suivantes

Planificateur ChatGPT Pro Le workflow de planification et de revue que ce sidecar débloque.

Moteur navigateur ChatGPT Pilotez ChatGPT Web via Oracle — sans clé API.