Am Ende kann Codex CLI zwei Aufgaben in einem GitNest-Repository auf osFoundry erledigen. Es schreibt Dateien aus deiner Terminal-Session auf einen Branch, und es bringt ein fertiges Change Set als Pull Request heraus, entweder direkt in GitNest oder als Draft auf GitHub oder GitLab. Codex selbst committet und pusht nichts. Jede Aufgabe kommt als Karte unter "Needs your approval" an der Verbindung Codex CLI an, mit den Dateien, dem Branch oder dem genauen Commit darauf. Es passiert nichts, bis der Owner des Repositorys klickt.
Wer was macht
| Codex CLI | osFoundry | |
|---|---|---|
| Login | Deine Codex-Anmeldung. Codex hält ein osFoundry-OAuth-Token mit osfoundry:read und osfoundry:write | Der Owner hat die Verbindung einmal freigegeben, im Tab Connected |
| Was es senden kann | Bis zu 20 UTF-8-Dateien, insgesamt 200 KB, für einen Branch. Oder eine Change-Set-ID, festgenagelt auf eine Version und einen zusammengesetzten Commit | Speichert jede Anfrage als Vorschlag mit Ablaufzeit |
| Wer freigibt | Codex fragt dich vor jedem schreibenden Aufruf (default_tools_approval_mode = "writes") | Der Owner der Verbindung klickt Approve and create oder Approve and publish, solange er die Rolle im Repository noch hat |
| Wer schreibt | Niemand auf der Codex-Seite | osFoundry legt nach der Freigabe den Commit an oder öffnet den Pull Request |
| Provider-Tokens | Werden nie gesendet | Bei der Freigabe wird das verknüpfte GitHub- oder GitLab-Konto des Owners verwendet, nur für den eigenen Branch des Change Sets |
| Mergen | Außer Reichweite | Bleibt bei Menschen, in GitNest oder beim Provider |
Einrichtung
1. Codex auf die GitNest-Tools beschränken
Die Verbindung wird wie gewohnt angelegt: das Schlüsselsymbol im Header, der Tab Connected, Other MCP client und ein Anzeigename wie Codex CLI. Dieser Name steht auf jeder Karte und jeder Benachrichtigung, also nimm einen, den der Owner wiedererkennt.
Auf der Codex-Seite:
codex mcp add osfoundry --url https://api.osfoundry.io/api/v1/external-mcp # ~/.codex/config.toml [mcp_servers.osfoundry] url = "https://api.osfoundry.io/api/v1/external-mcp" scopes = ["osfoundry:read", "osfoundry:write"] default_tools_approval_mode = "writes" enabled_tools = [ "list_granted_resources", "read_gitnest_repository", "list_gitnest_work", "list_gitnest_checks", "propose_gitnest_file_import", "propose_gitnest_native_publication", "propose_gitnest_provider_publication", ] codex mcp login osfoundry Der Server bietet 59 Tools an. Diese sieben braucht diese Anleitung. Die drei propose_-Tools sind die einzigen, die nicht als read-only markiert sind. Mit "writes" führt Codex die vier lesenden Tools also selbstständig aus und hält vor jedem Vorschlag an, um dich zu fragen. Das sind zwei Freigaben hintereinander: deine im Terminal, dann die des Owners in osFoundry. Wenn du selbst der Owner bist, ist die erste nur ein kurzer Check, ob Codex gleich das anfragt, was du gemeint hast.
2. Das Repository in ein Projekt legen, in dem die Verbindung ist
Eine Verbindung sieht ein GitNest-Repository nur über ein Projekt. Öffne in GitNest das Repository und such den Abschnitt Project. Nur der Owner des Repositorys bekommt die Auswahl. Wähl das Projekt aus, dann erscheint der Toast "Repository project updated". Danach wählst du im Tab Connected Codex CLI aus und klickst unter Projects für dasselbe Projekt auf Add to project.
Der Dateiimport braucht außerdem ein natives GitNest-Repository, also eines, dessen Git in osFoundry liegt. Die Tool-Beschreibung sagt es ganz direkt: "Repository GitNest must be enabled." Ein Repository, das nur GitHub spiegelt, geht stattdessen den Weg über Change Set und Provider-Veröffentlichung.
3. Für GitHub oder GitLab das Provider-Konto verknüpfen
propose_gitnest_provider_publication pusht mit dem verknüpften Git-Provider-Konto des Owners, und zwar in dem Moment, in dem der Owner freigibt. Ist kein Konto verknüpft, hat diese Freigabe nichts, womit sie pushen könnte. Codex braucht für all das nie ein GitHub-Token.
Ein echter Durchlauf
Auf dem Rechner, auf dem dieser Text entstand, ist Codex nicht installiert, deshalb ist die Session unten ein simuliertes Example. Tool- und Argumentnamen stammen aus tools/list des Live-Servers, mit dem Präfix mcp__osfoundry__, das Codex voranstellt. Repository, Dateien, IDs und Antworten sind Demo-Inhalte.
Example (simulated) > shop-api has no CI. In osFoundry, put a GitHub Actions workflow that runs `make test` on pull requests, plus the Makefile target, on a branch codex/ci-workflow. • mcp__osfoundry__list_granted_resources {} ← project "Checkout" · GitNest repository "shop-api" • mcp__osfoundry__read_gitnest_repository {"repository_id": "…"} ← native, GitNest enabled, default branch main • mcp__osfoundry__propose_gitnest_file_import { "repository_id": "…", "branch": "codex/ci-workflow", "message": "Add CI workflow and make test target", "files": [ {"path": ".github/workflows/ci.yml", "content": "name: ci\non: [pull_request]\n…"}, {"path": "Makefile", "content": "test:\n\tpython -m pytest -q\n"}], "idempotency_key": "codex-shop-api-ci-0001"} [Codex asks: allow this tool call? → yes] ← proposal waiting for the owner I prepared one commit for shop-api on codex/ci-workflow with two files. Nothing is committed yet. The owner approves it in osFoundry. In osFoundry zeigt die Glocke "Codex CLI proposes GitNest file changes". Im Panel der Verbindung steht auf der Karte "Commit GitNest files in shop-api", darunter "Commit to branch: codex/ci-workflow" und die Commit-Nachricht. "Review all proposed files (2)" klappt den vollständigen Text jeder Datei auf, keine Diff-Zusammenfassung. Approve and create legt den Commit an. Decline verwirft ihn.
Beispiel: die Karte Commit GitNest files für shop-api mit beiden vorgeschlagenen Dateien aufgeklappt
Später am selben Tag, mit einem Change Set, das in GitNest schon zusammengesetzt ist:
Example (simulated) > Is the "Add CI workflow" change set green? If so, open it on GitHub as a draft PR. • mcp__osfoundry__list_gitnest_work {"repository_id": "…", "kind": "changes"} ← "Add CI workflow" · version 3 • mcp__osfoundry__list_gitnest_checks {"repository_id": "…", "change_set_id": "…"} ← composed commit 73e59f27bc4f…: unit passed · lint passed • mcp__osfoundry__propose_gitnest_provider_publication { "repository_id": "…", "change_set_id": "…", "expected_change_set_version": 3, "expected_composition_oid": "73e59f27bc4f…", "idempotency_key": "codex-shop-api-ci-pr-0001"} [Codex asks: allow this tool call? → yes] ← proposal waiting for the owner Both checks passed on the composed commit. I asked for a draft GitHub PR of version 3; it opens when the owner approves it in osFoundry. Codex bestimmt weder Branch noch Titel noch Ziel des Pull Requests. Das Schema erlaubt nur das Change Set, die Version, die es gelesen hat, und den zusammengesetzten Commit, den es gelesen hat. Wer draft: false oder einen anderen target_branch anfragt, wird abgewiesen, bevor die Anfrage überhaupt jemanden erreicht.
Die Karte heißt "Open a draft GitHub or GitLab pull request in shop-api". Sie zeigt "Change set: … · expected version 3", "Reviewed commit: 73e59f27bc4f…", einen Link "Review change set before approving" und eine Zeile dazu, was die Freigabe tut: Sie "uses your linked Git provider account to push this change-set branch and open a draft pull request". Der Button heißt Approve and publish. Für ein Repository, das in GitNest lebt, erzeugt propose_gitnest_native_publication die Schwesterkarte "Publish GitNest pull request", die "creates a publication branch and opens a pull request in this native repository".
Beispiel: eine Provider-Pull-Request-Karte und eine native Veröffentlichungskarte unter Needs your approval
Der Link auf der Karte öffnet das Change Set in GitNest. Die Checks des zusammengesetzten Commits stehen ganz oben, über den Review-Tabs. So sieht der Owner vor der Entscheidung dasselbe, was Codex gesehen hat.
Wo die Grenze liegt
Ein Dateiimport transportiert nur Text. Jeder Eintrag ist ein Pfad und sein vollständiger Inhalt, sonst nichts. Es gibt keinen Dateimodus, kein Löschen und keine Binärdateien, und der ganze Commit bleibt innerhalb von 20 Dateien und 200 KB. So bleibt jedes Byte auf der Karte lesbar. Der eigene Browser-Upload des Owners in GitNest geht viel weiter (2,000 Dateien, je 8 MB, insgesamt 32 MB), weil dort ein Mensch seine eigenen Dateien committet.
Veröffentlicht wird aus einem zusammengesetzten Change Set, nicht aus einem Branch, den Codex nennt. Die Karte nagelt die Version und den Commit fest, die Codex angeschaut hat. Wird das Change Set vor dem Klick neu zusammengesetzt, lehnt die erneute Prüfung von osFoundry den Vorschlag ab, statt etwas zu veröffentlichen, das niemand reviewt hat. Bei der Freigabe prüft sie außerdem die aktuellen Berechtigungen, die Risikostufen und Pflicht-Checks des Repositorys sowie das Ziel. Diese Regeln setzen Menschen in GitNest, unter Risk tiers und Required checks, und Codex kommt da nicht ran.
Auf GitHub oder GitLab bewegt sich nur der eigene Branch des Change Sets. Der Pull Request öffnet sich als Draft, und der Push läuft zum Zeitpunkt der Freigabe über das verknüpfte Konto des Owners. Codex sieht dieses Token nie, und deine anderen Branches sind nicht Teil des Pushs.
Mergen steht nicht auf der Liste. Weiter als bis zu einem offenen Pull Request kommt keiner dieser Vorschläge. Wer ihn mergt, und was ein Merge auslöst, bleibt bei den Menschen am Repository.
Beide Veröffentlichungs-Tools tragen in tools/list openWorldHint: true, der Dateiimport nicht. Einen Pull Request sehen auch Leute außerhalb der Unterhaltung. Ein ordentlicher Client nimmt das als Grund, vorher zu fragen, so wie Codex es hier tut.
Als Nächstes probierst du den Import auf einem Branch aus, den noch niemand nutzt. Lass Codex eine einzelne neue Datei vorschlagen, eine CONTRIBUTING.md oder einen CI-Workflow, öffne auf der Karte "Review all proposed files" und gib sie frei. Die GitNest-Seite erklärt, wie Change Sets, Checks und Veröffentlichung auf der Repository-Seite zusammenspielen.
