Alla fine, Codex CLI potrà fare due lavori su un repository GitNest in osFoundry. Scrive su un branch file che arrivano dalla tua sessione di terminale, e porta fuori un change set finito come pull request, dentro GitNest oppure come bozza su GitHub o GitLab. Codex non fa commit né push di niente da solo. Ogni lavoro arriva come una scheda sotto "Needs your approval" sulla connessione Codex CLI, con sopra i file, il branch o il commit esatto. Non succede nulla finché il proprietario del repository non clicca.
Chi fa cosa
| Codex CLI | osFoundry | |
|---|---|---|
| Accesso | Il tuo login Codex. Codex ha un token OAuth di osFoundry con osfoundry:read e osfoundry:write
|
Il proprietario ha approvato la connessione una volta sola, nella scheda Connected |
| Cosa può inviare | Fino a 20 file UTF-8, 200 KB in totale, per un branch. Oppure un ID di change set fissato a una versione e a un commit composto | Salva ogni richiesta come proposta con una scadenza |
| Chi approva | Codex ti chiede conferma prima di ogni chiamata in scrittura (default_tools_approval_mode = "writes") |
Il proprietario della connessione clicca Approve and create, o Approve and publish, finché ha ancora il ruolo sul repository |
| Chi scrive | Nessuno dal lato Codex | osFoundry crea il commit, o apre la pull request, dopo l'approvazione |
| Token del provider | Mai inviati | Al momento dell'approvazione si usa l'account GitHub o GitLab collegato del proprietario, solo per il branch del change set |
| Merge | Fuori portata | Resta alle persone, in GitNest o sul provider |
Configurazione
1. Limita Codex agli strumenti di GitNest
La connessione si crea nel solito modo: l'icona della chiave nell'header, la scheda Connected, Other MCP client e un nome visualizzato come Codex CLI. Quel nome compare su ogni scheda e ogni notifica, quindi scegline uno che il proprietario riconosca.
Dal lato Codex:
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
Il server espone 59 strumenti. Questi sette sono quelli che servono per questa guida. I tre strumenti propose_ sono gli unici non marcati come sola lettura, quindi con "writes" Codex esegue da solo i quattro strumenti di lettura e si ferma a chiederti conferma prima di ogni proposta. Sono due approvazioni di fila: la tua nel terminale, poi quella del proprietario in osFoundry. Se il proprietario sei tu, la prima è solo un controllo che Codex stia per chiedere quello che intendevi.
2. Metti il repository in un progetto in cui c'è la connessione
Una connessione vede un repository GitNest solo attraverso un progetto. In GitNest apri il repository e cerca la sezione Project. Solo il proprietario del repository ha il selettore. Scegli il progetto e compare il toast "Repository project updated". Poi, nella scheda Connected, seleziona Codex CLI e sotto Projects clicca Add to project per lo stesso progetto.
L'importazione di file richiede anche un repository GitNest nativo, cioè uno il cui Git vive in osFoundry. La descrizione dello strumento lo dice chiaramente: "Repository GitNest must be enabled." Un repository che fa solo da mirror di GitHub segue invece la strada del change set e della pubblicazione sul provider.
3. Per GitHub o GitLab, collega l'account del provider
propose_gitnest_provider_publication fa push con l'account del provider Git collegato dal proprietario, nel momento in cui il proprietario approva. Se non c'è nessun account collegato, quell'approvazione non ha niente con cui fare push. Per tutto questo Codex non ha mai bisogno di un token GitHub.
Un'esecuzione reale
Codex non è installato sulla macchina su cui è stato scritto questo articolo, quindi la sessione qui sotto è un Example simulato. I nomi degli strumenti e degli argomenti vengono dal tools/list del server reale, con il prefisso mcp__osfoundry__ che aggiunge Codex. Repository, file, ID e risposte sono contenuti dimostrativi.
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 la campanella mostra "Codex CLI proposes GitNest file changes". Nel pannello della connessione la scheda riporta "Commit GitNest files in shop-api", poi "Commit to branch: codex/ci-workflow" e il messaggio di commit. "Review all proposed files (2)" si apre sul testo completo di ogni file, non su un riassunto del diff. Approve and create crea il commit. Decline lo scarta.
Esempio: la scheda Commit GitNest files per shop-api con entrambi i file proposti espansi
Più tardi, lo stesso giorno, con un change set già composto in GitNest:
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 non sceglie né il branch, né il titolo, né la destinazione della pull request. Lo schema ammette solo il change set, la versione che ha letto e il commit composto che ha letto. Se chiede draft: false o un target_branch diverso, la richiesta viene respinta prima ancora di arrivare a qualcuno.
La scheda si intitola "Open a draft GitHub or GitLab pull request in shop-api". Mostra "Change set: … · expected version 3", "Reviewed commit: 73e59f27bc4f…", un link "Review change set before approving" e una riga su cosa fa l'approvazione: "uses your linked Git provider account to push this change-set branch and open a draft pull request". Il pulsante è Approve and publish. Per un repository che vive in GitNest, propose_gitnest_native_publication genera la scheda gemella, "Publish GitNest pull request", che "creates a publication branch and opens a pull request in this native repository".
Esempio: una scheda di pull request sul provider e una scheda di pubblicazione nativa sotto Needs your approval
Il link sulla scheda apre il change set in GitNest. I check sul suo commit composto stanno in alto, sopra le schede di revisione, così il proprietario vede quello che ha visto Codex prima di decidere.
Dov'è il limite
Un'importazione di file porta solo testo. Ogni voce è un percorso con il suo contenuto completo, nient'altro. Niente modalità del file, niente cancellazioni, niente binari, e l'intero commit resta entro 20 file e 200 KB. Così ogni byte si può leggere sulla scheda. Il caricamento che il proprietario fa da browser in GitNest arriva molto più in là (2,000 file, 8 MB ciascuno, 32 MB in totale), perché lì è una persona che fa il commit dei propri file.
La pubblicazione parte da un change set composto, non da un branch indicato da Codex. La scheda fissa la versione e il commit che Codex ha guardato. Se il change set viene ricomposto prima del clic, il nuovo controllo di osFoundry rifiuta la proposta invece di pubblicare qualcosa che nessuno ha revisionato. Al momento dell'approvazione controlla anche i permessi attuali, i livelli di rischio e i check obbligatori del repository, e la destinazione. Queste regole le impostano le persone in GitNest, in Risk tiers e Required checks, e Codex non può toccarle.
Su GitHub o GitLab si muove solo il branch del change set. La pull request si apre come bozza, e il push usa l'account collegato del proprietario al momento dell'approvazione. Codex non vede mai quel token, e gli altri tuoi branch non fanno parte del push.
Il merge non è nella lista. Nessuna di queste proposte va oltre una pull request aperta. Chi la unisce, e qualunque cosa un merge metta in moto, resta alle persone del repository.
Entrambi gli strumenti di pubblicazione hanno openWorldHint: true in tools/list, l'importazione di file no. Una pull request la vedono anche persone esterne alla conversazione. Un client fatto bene lo prende come motivo per chiedere prima, come fa Codex qui.
Come passo successivo, prova l'importazione su un branch che ancora nessuno usa. Chiedi a Codex di proporre un solo file nuovo, un CONTRIBUTING.md o un workflow di CI, apri "Review all proposed files" sulla scheda e approva. La pagina di GitNest spiega come change set, check e pubblicazione si incastrano dal lato del repository.
Top comments (0)