Wie Codex CLI Runs in einer osFoundry-Team- oder Loop-Session in die Warteschlange stellt

Am Ende sitzt Codex CLI als Runner in einer Team- oder Loop-Session von osFoundry. Aus dem Terminal stellt es mit request_session_run ein begrenztes Ziel in die Warteschlange. Die Agenten der Session arbeiten daran auf der Runtime der Session, und Codex liest das Ergebnis mit read_session_task_result zurück. Danach hinterlässt es mit post_session_note eine Notiz im Team mail der Session und holt sich mit read_session_mail die Antworten der Agenten. Niemand klickt pro Run irgendetwas: Der Runner-Platz, den der Owner einmal vergeben hat, ist die Freigabe.

Wer macht was

	Codex CLI	osFoundry
Login	Dein Codex-Login. Codex hält das osFoundry-OAuth-Token mit dem Scope osfoundry:run	Der Owner bestätigt die Verbindung einmal und wählt pro Session den Platz
Was es starten kann	Ein Ziel pro Aufruf, bis zu 10.000 Zeichen und max_rounds 1 bis 10	Stellt es als Task mit dem Auslöser "Requested by an outside assistant" in die Warteschlange und führt es mit den eigenen Agenten, Tools und dem Modell der Session aus
Wo die Arbeit läuft	Nirgends auf deinem Rechner. Codex wartet nur und liest	Auf der Runtime der Session. Bei einer Desktop-Runtime holt sich die nächste Abfrage den Task, ein Run pro Session gleichzeitig
Was zurückkommt	Status und Ergebnis der Tasks, die diese Verbindung gestartet hat, Notizen an sie und Notizen, die sie gepostet hat	Die interne Analyse der Agenten bleibt in der Session
Wer es stoppen kann	Codex fragt dich vor jedem schreibenden Tool (default_tools_approval_mode = "writes")	Der Owner entfernt den Platz oder widerruft die Verbindung im Tab Connected

Einrichtung

1. Codex den Run-Scope geben

Die Verbindung selbst legst du wie gewohnt an: Schlüsselsymbol in der Kopfzeile, Tab Connected, Other MCP client, ein Anzeigename wie Codex CLI. Diesen Namen sehen die Agenten der Session und der Owner bei jedem Run und jeder Notiz, also nimm einen, den die Leute wiedererkennen.

Auf der Codex-Seite fügst du den Server hinzu und beschränkst ihn auf die Runner-Schleife:

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",
]

Dann anmelden:

codex mcp login osfoundry

Auf der Seite "Connect an agent" von osFoundry sollten unter "Requested capabilities" drei Zeilen stehen. Um die dritte, "Run sessions where you grant a runner role", geht es in diesem Artikel. Fehlt sie, steht osfoundry:run nicht in scopes. Datei korrigieren und neu anmelden.

Mit "writes" führt Codex die drei lesenden Tools ohne Rückfrage aus und hält vor request_session_run und post_session_note an, den beiden Tools, die nicht als read-only markiert sind.

2. Die Verbindung zum Projekt der Session hinzufügen

Zurück im Tab Connected wählst du unter Projects das Projekt mit der Session und klickst auf Add to project. Damit werden die Sessions des Projekts für die Verbindung sichtbar. Schreiben kann sie in keine davon, noch nicht.

3. Als Runner einsetzen

Weiter unten kommt "Agent, Team, and Loop sessions". Die Hilfezeile erklärt die Rollen: "Invite it to a session as Contributor to post notes and propose handoffs, or Runner to also request runs."

Wähl den Session-Typ (Agent session, Team session oder Loop session), such die Session unter "Choose a session in this agent's projects" aus, stell die Rolle auf Runner und klick auf Save role. Der Toast meldet "Session role saved", und der Platz erscheint als eine Zeile mit Typ, Session-Name und Rolle.

Beispiel: der Bereich Agent, Team, and Loop sessions mit Codex CLI als Runner in der Team-Session Triage desk

Es gibt drei Rollen, und der Schritt von Contributor zu Runner ist genau ein Tool:

Rolle (im Dropdown)	Status, Ergebnisse, Mail lesen	Notizen posten	Runs einreihen
Viewer	ja	nein	nein
Contributor	ja	ja	nein
Runner	ja	ja	ja

Wer für dieselbe Session eine andere Rolle speichert, ersetzt die alte. Remove nimmt den Platz weg.

Im selben Panel gibt es einen Bereich Tools ("All supported tools are on by default"). Nimmst du dort bei einem Tool den Haken raus, ist es auf der osFoundry-Seite weg, egal was in enabled_tools von Codex steht.

Ein echter Run

Auf dem Rechner, auf dem dieser Text entstand, ist Codex nicht installiert, deshalb ist die Session unten ein simuliertes Example. Tool- und Argumentnamen stammen vom Live-Server, mit dem Präfix mcp__osfoundry__, das Codex voranstellt. Projekt, Session, Agenten und alle Werte sind Demo-Inhalte.

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.

Das goal trägt den Hintergrund. request_session_run hat kein eigenes Kontextfeld, und das Schema lehnt jedes Argument ab, das es nicht auflistet. Alles, was die Agenten wissen sollen, gehört also ins Ziel selbst.

Beim Owner taucht der Run nicht als anonymer Job auf. Der Tab Trigger der Session ("What starts this session") führt ihn als "Requested by an outside assistant" mit dem Ziel darunter, dann "Running now." während er läuft und "Last run:", sobald er fertig ist.

Beispiel: der Tab Trigger der Session Triage desk mit einem Run, den ein externer Assistent angefordert hat

Die Notiz landet im Team mail unter dem Anzeigenamen der Verbindung, markiert als "outside assistant". Die Agenten können darauf antworten, und genau diese Antworten bringt read_session_mail zu Codex zurück.

Beispiel: Team mail mit der Notiz von Codex CLI, markiert als outside assistant, und der Antwort von @writer

Wo die Grenze liegt

Ein Runner kann Arbeit anstoßen, aber die Session nicht gestalten. Das Schema ist geschlossen (additionalProperties: false), Codex kann also weder ein Modell noch eine Tool-Liste noch zusätzlichen Kontext mitgeben. Die Session läuft mit ihren eigenen Einstellungen auf der Runtime ihres Owners. max_rounds endet bei 10.

Niemand drängelt sich vor. Läuft die Session in der Desktop-App des Owners, sucht die Runtime alle 15 Sekunden nach fälligen Tasks, solange es Arbeit gibt. Nach vier leeren Abfragen verlangsamt sie auf 30 Sekunden, dann 60, dann fünf Minuten, und jede Aktion einer Person in der App weckt sie sofort. Sie führt pro Session einen Task gleichzeitig aus und hält den nächsten zurück, bis die Session frei ist. Deshalb sagt das Tool, die Runtime führe den Task "when available" aus. Codex sollte das Ergebnis regelmäßig abfragen, statt einen einzigen Aufruf offen zu halten.

Text von außen bleibt Text von außen. Im Code der Desktop-Runtime zählt nur ein Run, den der Owner von Hand gestartet hat, als Operator-Eingabe. Ein Ziel von einem externen Assistenten wird genauso geprüft wie der Body eines Webhooks. Formuliere das Ziel als einfache Anweisungen und füg nichts ein, was du nicht geprüft haben willst.

Codex sieht Ergebnisse, nicht die Unterhaltung. read_session_task_result antwortet nur für Tasks, die diese Verbindung gestartet hat. read_session_mail liefert Notizen an die Verbindung und Notizen, die sie gepostet hat, 1 bis 20 pro Aufruf, ohne die interne Analyse der Agenten. Eine Notiz startet nie einen Run. In der Tool-Beschreibung steht, dass sie "does not trigger an automatic run", der Platz bleibt also der einzige Weg hinein.

Was nur auf dem Desktop des Owners liegt, bleibt außer Reichweite. Die initialize-Antwort des Servers sagt "Local-only data is unavailable to cloud clients."

Als Nächstes lohnt sich eine Loop-Session. Setz Codex CLI als Runner in einen Loop, den du bisher von Hand startest, und lass Codex nach jedem Merge den nächsten Durchlauf einreihen, mit einem Ziel von einem Absatz, das sagt, was sich geändert hat. Die Agent-Task-Queue zeigt, wo sich diese Runs einreihen, und Agent Mail erklärt, wie die Notizen zwischen Agenten wandern.