Alla fine, Codex CLI saprà rispondere a "cosa è cambiato nel progetto Launch plan da ieri?" senza rileggere ogni nota e ogni canale del progetto. Chiede a osFoundry quali risorse ha concesso il proprietario (list_granted_resources), scopre cosa c'è nel progetto (list_project_resources) e poi chiede a ogni risorsa solo gli eventi successivi all'ultimo numero di sequenza che ha visto (poll_resource_events). Quei numeri stanno in un piccolo file nel tuo repo, così la sessione Codex successiva riprende da dove si era fermata la precedente. Ogni chiamata compare in Recent activity della connessione su osFoundry.
Chi fa cosa
| Codex CLI | osFoundry | |
|---|---|---|
| Login | Tiene il token OAuth di osFoundry, basta osfoundry:read | Il proprietario approva la connessione una volta nella scheda Connected |
| Cosa può vedere | Ciò che restituisce list_granted_resources, nient'altro | Lo decide il proprietario: progetti aggiunti alla connessione, Message channels a cui è stata invitata |
| Dove vive lo stato "visto per ultimo" | Un intero per risorsa, gestito da Codex (qui in .osfoundry/cursors.json) | Un log di eventi ordinato per risorsa, letto a partire da un numero di sequenza |
| Cosa succede a un cambiamento | Decide Codex: rileggere quella nota, leggere il canale o solo segnalarlo | Niente. Il polling non modifica mai nulla sul server |
| Chi può fermarlo | Tu, smettendo di chiedere | Il proprietario rimuove il progetto, toglie la spunta a un tool o revoca la connessione |
Configurazione
1. Trova la connessione di Codex
In osFoundry, l'icona della chiave nell'header apre la scheda Connected. Se Codex non è ancora connesso, scegli Other MCP client sotto Assistant, dagli un nome visualizzato come Codex CLI e clicca su Add assistant. Il pannello mostra l'indirizzo del server da passare a Codex.
Esempio: la scheda Connected agents con una connessione Codex CLI attiva
Dal lato di Codex:
codex mcp add osfoundry --url https://api.osfoundry.io/api/v1/external-mcp codex mcp login osfoundry 2. Decidi cosa può osservare Codex
Questa è la parte del proprietario, ed è l'intera risposta a "cosa vedrà Codex?". Seleziona la connessione e apri Projects. Scegli un progetto in "Choose a project" e clicca su Add to project. La riga di aiuto spiega cosa concede: "Adding this agent to a project gives it access to supported synced content in that project and its discussion channel. Other Message channels require a separate invitation."
Quindi un progetto dà a Codex le sue note, knowledge base, record channel, Room, repository GitNest e sessioni, più il canale di discussione del progetto. Qualsiasi altro Message channel è un secondo passaggio esplicito: più in basso, sotto Message channels, sceglilo in "Choose a Message channel" e clicca su Invite.
Esempio: la connessione Codex CLI con il progetto Launch plan aggiunto e un Message channel invitato
I permessi salvati prima che esistesse l'accesso per progetto compaiono sotto "Older individual access". Anche questi vengono restituiti da list_granted_resources, come risorse concesse singolarmente, quindi controlla quella sezione prima di dare per scontato che un progetto sia l'unico modo di entrare.
3. Lascia attivi i tre tool
Apri Tools sulla stessa connessione. "All supported tools are on by default." Lascia spuntati list granted resources, list project resources e poll resource events, insieme ai tool di lettura di cui Codex ha bisogno quando sa che qualcosa è cambiato (read note tab, read channel messages e così via). Togliere la spunta a un tool qui lo rimuove dal lato di osFoundry, qualunque cosa dica la configurazione di Codex.
4. Limita Codex al ciclo di osservazione
# ~/.codex/config.toml [mcp_servers.osfoundry] url = "https://api.osfoundry.io/api/v1/external-mcp" scopes = ["osfoundry:read"] enabled_tools = [ "list_granted_resources", "list_project_resources", "poll_resource_events", "list_note_tabs", "read_note_tab", "read_channel_messages", ] Tutti e sei sono marcati come read-only sul server, quindi Codex li esegue senza chiedere.
5. Di' a Codex dove tenere i cursori
Codex inizia ogni sessione da zero, quindi l'ultima sequenza di ogni risorsa deve stare in un posto che possa leggere. Basta un AGENTS.md nel repo:
## osFoundry changes - Cursors are in .osfoundry/cursors.json: {"<resource_type>:<resource_id>": <last sequence>}. - Start with list_granted_resources. Drop cursors for resources it no longer returns. - For each watched resource call poll_resource_events with after_sequence from the file and limit 100. If a page comes back full, call again from its last sequence. - Only after reporting the changes, write the new sequence back to the file. - A resource with no cursor yet: poll from after_sequence 0 once to get its current sequence. Riscrivere il cursore dopo il resoconto, e non prima, fa sì che una sessione che si interrompe a metà mostri gli stessi eventi la volta successiva invece di perderli.
Un'esecuzione reale
Codex non è installato sulla macchina su cui è stato scritto questo testo, quindi la sessione qui sotto è un esempio simulato. I nomi dei tool e degli argomenti sono quelli del server live, con il prefisso mcp__osfoundry__ che aggiunge Codex. Progetto, risorse, numeri di sequenza e risultati sono contenuti dimostrativi.
Example (simulated) > What changed in the Launch plan project since my last check? • mcp__osfoundry__list_granted_resources {} ← project "Launch plan"; message_channel "launch-updates" (invited) • mcp__osfoundry__list_project_resources {"project_id": "…", "resource_type": "note"} ← 3 notes: "Launch checklist", "Pricing page copy", "Press list" • mcp__osfoundry__poll_resource_events {"resource_type": "note", "resource_id": "…", "after_sequence": 118, "limit": 100} (Launch checklist) ← 2 events, last sequence 120 • mcp__osfoundry__poll_resource_events {… "Pricing page copy", "after_sequence": 64 …} ← no events • mcp__osfoundry__poll_resource_events {… "Press list", "after_sequence": 9 …} ← no events • mcp__osfoundry__poll_resource_events {"resource_type": "message_channel", "resource_id": "…", "after_sequence": 311, "limit": 100} ← 5 events, last sequence 316 • mcp__osfoundry__read_note_tab {"note_id": "…", "tab_id": "…"} (Launch checklist) • mcp__osfoundry__read_channel_messages {"channel_id": "…", "limit": 5} (Codex writes 120 and 316 back to .osfoundry/cursors.json) Two things moved since yesterday. In "Launch checklist", the press embargo line now says Thursday 09:00 instead of Wednesday. In launch-updates, five messages: the pricing page is approved, and the App Store build is still in review. "Pricing page copy" and "Press list" haven't changed. Quattro poll, due letture. Senza i cursori, la stessa risposta significa leggere per intero le tre note e il canale e confrontarle con quello che Codex ricorda, cioè niente.
Dal lato del proprietario, ogni chiamata è una riga in Recent activity della connessione: nome del tool, decisione, orario.
Esempio: Tools e Recent activity della connessione Codex CLI dopo un controllo
Dove passa il confine
Codex vede solo ciò che elenca list_granted_resources. La risposta initialize del server stesso dice "Use list_granted_resources first", e quella chiamata non accetta argomenti: Codex non può chiedere un progetto per nome ed entrarci. Un Message channel che non sia il canale di discussione del progetto resta invisibile finché il proprietario non ci invita la connessione. La descrizione di list_project_resources lo ribadisce: "Ordinary Message channels require a separate invitation."
Il polling legge, non si iscrive. Il server espone solo tool, quindi osFoundry non sveglia mai Codex. Del resto è così che funziona Codex: guarda quando lo lanci, e i cursori rendono economico il "dall'ultima volta".
poll_resource_events lavora su una risorsa per chiamata. Non esiste un cursore per "tutto il progetto". In questo modo ogni log resta piccolo e ogni permesso separato. Quando il proprietario rimuove il progetto, i poll sulle sue risorse smettono di funzionare e il successivo list_granted_resources non le elenca più. A quel punto Codex dovrebbe eliminare quei cursori, non riprovare.
Le sessioni Graph sono un caso a parte. poll_resource_events accetta graph_session, ma i Graph vivono sul desktop del proprietario. Arrivano alla connessione solo quando il proprietario li spunta sotto "Share desktop Graph sessions" e l'app desktop è aperta e con l'accesso effettuato. Tutto il resto che esiste solo sul dispositivo resta lì. La risposta initialize dice "Local-only data is unavailable to cloud clients."
Come passo successivo, inseriscilo nella tua routine del mattino: codex exec "What changed in the Launch plan project since my last check?" dal repo con l'AGENTS.md, prima di aprire qualsiasi altra cosa. Quali tool riceve ogni connessione, e perché l'accesso si decide comunque per progetto, è spiegato nella pagina sul tool scope. Il protocollo sottostante è nella voce MCP del glossario.
