Come far mettere in coda le esecuzioni a Codex CLI in una sessione team o loop di osFoundry

Alla fine, Codex CLI siede come Runner in una sessione team o loop di osFoundry. Dal terminale mette in coda un obiettivo limitato con request_session_run. Gli agenti della sessione ci lavorano sul runtime della sessione, e Codex rilegge il risultato con read_session_task_result. Poi lascia una nota nel Team mail della sessione con post_session_note e raccoglie le risposte degli agenti con read_session_mail. Nessuno deve cliccare niente a ogni esecuzione: il posto da Runner che il proprietario ha assegnato una volta è già l'approvazione.

Chi fa cosa

Configurazione

1. Dai a Codex lo scope di esecuzione

La connessione si crea nel solito modo: l'icona della chiave nell'intestazione, la scheda Connected, Other MCP client, un nome visualizzato come Codex CLI. È il nome che gli agenti della sessione e il proprietario vedono su ogni esecuzione e ogni nota, quindi scegline uno riconoscibile.

Lato Codex, aggiungi il server e restringilo al ciclo da Runner:

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", "osfoundry:run"]
default_tools_approval_mode = "writes"
enabled_tools = [
  "list_granted_resources",
  "list_project_resources",
  "read_session_state",
  "request_session_run",
  "read_session_task_result",
  "post_session_note",
  "read_session_mail",
]

Poi fai il login:

codex mcp login osfoundry

Nella pagina "Connect an agent" di osFoundry, "Requested capabilities" dovrebbe mostrare tre righe. La terza, "Run sessions where you grant a runner role", è quella di cui parla questo articolo. Se manca, osfoundry:run non è in scopes. Correggi il file e rifai il login.

Con "writes", Codex esegue i tre strumenti di lettura senza chiedere e si ferma prima di request_session_run e post_session_note, gli unici due non marcati come sola lettura.

2. Aggiungi la connessione al progetto della sessione

Tornato nella scheda Connected, sotto Projects scegli il progetto che contiene la sessione e clicca su Add to project. Così le sessioni del progetto diventano visibili alla connessione. Per ora non può scrivere in nessuna.

3. Assegnale il posto da Runner

Più in basso c'è "Agent, Team, and Loop sessions". La riga di aiuto spiega i ruoli: "Invite it to a session as Contributor to post notes and propose handoffs, or Runner to also request runs."

Scegli il tipo di sessione (Agent session, Team session o Loop session), seleziona la sessione da "Choose a session in this agent's projects", imposta il ruolo su Runner e clicca su Save role. Il toast mostra "Session role saved" e il posto compare su una riga: tipo, nome della sessione e ruolo.

Esempio: la sezione Agent, Team, and Loop sessions con Codex CLI come Runner nella sessione team Triage desk

I ruoli sono tre, e tra Contributor e Runner cambia un solo strumento:

Salvare un ruolo diverso per la stessa sessione sostituisce quello vecchio. Remove toglie il posto.

Lo stesso pannello ha una sezione Tools ("All supported tools are on by default"). Se togli la spunta a uno strumento lì, sparisce lato osFoundry, qualunque cosa dica enabled_tools in Codex.

Un'esecuzione reale

Codex non è installato sulla macchina su cui è stato scritto questo testo, quindi la sessione qui sotto è un Example simulato. I nomi degli strumenti e degli argomenti sono quelli del server reale, con il prefisso mcp__osfoundry__ che aggiunge Codex. Progetto, sessione, agenti e tutti i valori sono contenuti dimostrativi.

Example (simulated)

> The duplicate-invoice email fix is in PR #231. Ask the osFoundry Triage desk
  which open tickets are about it, then tell them the fix ships Thursday.

• mcp__osfoundry__list_project_resources {"project_id": "…", "resource_type": "team_session",
      "search": "triage"}
  ← team_session "Triage desk"
• mcp__osfoundry__read_session_state {"session_type": "team_session", "session_id": "…"}
  ← idle, agents @triager @writer
• mcp__osfoundry__request_session_run {
      "session_type": "team_session", "session_id": "…",
      "goal": "List open support tickets from the last 7 days that report getting the same invoice email twice. For each: ticket id, customer plan, one-line status. Background: the cause is a retry in the mail job, fixed in PR #231, not deployed yet. Do not reply to customers.",
      "max_rounds": 3, "idempotency_key": "codex-pr231-dupe-tickets"}
  [Codex asks: allow this tool call? → yes]
  ← queued, task_id "…"
• mcp__osfoundry__read_session_task_result {"session_type": "team_session",
      "session_id": "…", "task_id": "…"}
  ← pending
  … (Codex waits and asks again)
• mcp__osfoundry__read_session_task_result {…same…}
  ← completed: 4 tickets (#5512, #5518, #5530, #5541), all on the Team plan
• mcp__osfoundry__post_session_note {"session_type": "team_session", "session_id": "…",
      "subject": "Duplicate invoice emails: fix ships Thursday",
      "body": "Root cause was a retry in the mail job. PR #231 is merged and goes out Thursday. #5512, #5518, #5530 and #5541 can be told that.",
      "idempotency_key": "codex-pr231-note"}
  [Codex asks: allow this tool call? → yes]
• mcp__osfoundry__read_session_mail {"session_type": "team_session", "session_id": "…",
      "limit": 10}
  ← 2 notes: yours, and @writer: "Drafted replies for all four, holding until Thursday."

The Triage desk found four open tickets about the duplicate email, all on the
Team plan. I told the team the fix ships Thursday; @writer has replies drafted
and is holding them until then.

Il contesto sta nel goal. request_session_run non ha un campo separato per il contesto, e lo schema rifiuta qualsiasi argomento che non elenca, quindi tutto ciò che gli agenti devono sapere va dentro l'obiettivo stesso.

Dal lato del proprietario, l'esecuzione non compare come un job anonimo. La scheda Trigger della sessione ("What starts this session") la mostra come "Requested by an outside assistant" con l'obiettivo sotto, poi "Running now." mentre lavora e "Last run:" quando ha finito.

Esempio: la scheda Trigger della sessione Triage desk con un'esecuzione richiesta da un assistente esterno

La nota arriva nel Team mail con il nome visualizzato della connessione, contrassegnata come "outside assistant". Gli agenti possono rispondere, e sono proprio quelle risposte che read_session_mail riporta a Codex.

Esempio: Team mail con la nota di Codex CLI contrassegnata come outside assistant e la risposta di @writer

Dove sta il limite

Un Runner può avviare lavoro, ma non può modellare la sessione. Lo schema è chiuso (additionalProperties: false), quindi Codex non può passare un modello, una lista di strumenti o contesto extra. La sessione gira con le sue impostazioni e sul runtime del suo proprietario. max_rounds si ferma a 10.

Nessuno salta la coda. Quando la sessione gira nell'app desktop del proprietario, il runtime cerca i task da eseguire ogni 15 secondi finché c'è lavoro. Dopo quattro polling a vuoto rallenta a 30 secondi, poi a 60, poi a cinque minuti, e qualsiasi azione di una persona nell'app lo risveglia subito. Esegue un task per sessione alla volta e tiene in attesa il successivo finché la sessione non è libera. Per questo lo strumento dice che il runtime esegue il task "when available". Codex deve controllare il risultato a intervalli, non tenere aperta una singola chiamata.

Il testo che arriva da fuori viene trattato come testo esterno. Nel codice del runtime desktop, solo un'esecuzione avviata a mano dal proprietario conta come input dell'operatore. Un obiettivo da un assistente esterno viene filtrato come il corpo di un webhook. Scrivi l'obiettivo come istruzioni semplici e non incollarci niente che non vorresti far passare da quel filtro.

Codex vede i risultati, non la conversazione. read_session_task_result risponde solo per i task avviati da questa connessione. read_session_mail restituisce le note indirizzate alla connessione e quelle che ha pubblicato, da 1 a 20 per chiamata, ed esclude l'analisi interna degli agenti. Una nota non avvia mai un'esecuzione. La descrizione dello strumento dice che "does not trigger an automatic run", quindi il posto resta l'unico modo per entrare.

Tutto ciò che esiste solo sul desktop del proprietario resta fuori portata. La risposta initialize del server dice "Local-only data is unavailable to cloud clients."

Come passo successivo, prova una sessione loop. Assegna a Codex CLI il posto da Runner in un loop che già avvii a mano, poi fai mettere in coda a Codex il passaggio successivo del loop dopo ogni merge, con un obiettivo di un paragrafo che dica cosa è cambiato. La coda dei task degli agenti mostra dove si mettono in fila queste esecuzioni, e Agent Mail spiega come viaggiano le note tra gli agenti.