Wie Codex CLI einen Bug-Tracker in einem osFoundry-Record-Channel triagiert

Am Ende arbeitet Codex CLI den Record-Channel "Bugs" in einem deiner osFoundry-Projekte ab. Es liest das Schema des Channels, blättert durch die Items, die noch auf New stehen, öffnet jedes davon und setzt Status, Owner und Severity. Die Änderungen erscheinen im Tab Data des Channels wie die Bearbeitungen jedes Teammitglieds, und jeder Aufruf wird unter Recent activity (letzte Aktivität) der Verbindung aufgeführt. Passt ein Wert nicht zu einem Feld, lehnt osFoundry die Änderung ab, und Codex überlässt dieses Feld einem Menschen, statt zu raten.

Wer macht was

	Seite von Codex	Seite von osFoundry
Anmeldung	Deine Codex-Anmeldung, unverändert. Codex verwahrt das OAuth-Token von osFoundry	Eine genehmigte Verbindung für einen Workspace
Welcher Channel	Codex findet ihn mit list_project_resources	Nur Record-Channels in Projekten, denen die Verbindung hinzugefügt wurde
Feldregeln	Codex liest sie aus dem Schema, das list_record_items zurückgibt	Der Tab Schema des Channels: Feldtypen, Required, Select-Optionen
Schreibzugriffe	edit_record_item, nach der eigenen Rückfrage von Codex	Werte werden gegen die Felder validiert. Ein falscher Typ oder eine unbekannte Option wird abgelehnt
Konflikte	Codex liest das Item neu und entscheidet erneut	expected_version muss zur aktuellen Version des Items passen
Zeilen und Felder	Codex kann Werte in bestehenden Items ändern	Items anlegen oder löschen und das Schema ändern bleibt in der App

Einrichtung

Vorausgesetzt ist, dass Codex schon verbunden ist: Die Tabelle [mcp_servers.osfoundry] steht in ~/.codex/config.toml, und codex mcp login osfoundry ist durchgelaufen. Die Schritte hier sind das, was ein Record-Channel zusätzlich braucht.

1. Den Record-Channel ins verbundene Projekt legen

Öffne Records in der Seitenleiste und wähle den Channel. Ein neuer Tracker entsteht über Create Record Channel, Record Type Custom, das nach einem Namen fragt. Öffne im Channel den Tab Settings. Das Feld Project zeigt "Add to project", solange der Channel in keinem Projekt ist. Wähle das Projekt, zu dem die Codex-Verbindung gehört.

Die Verbindung erreicht einen Record-Channel über sein Projekt. Verschiebst du den Channel in ein anderes Projekt, wird der nächste Aufruf von Codex abgelehnt.

2. Das Schema prüfen, an das Codex gebunden ist

Der Tab Schema ("Define the fields for this record channel.") ist der Vertrag. Jedes Feld hat einen Typ, optional das Flag Required und bei Select und Multi-Select eine Liste von Optionen. Jede Option hat einen gespeicherten Wert und ein Label. Das Grid zeigt das Label. Codex muss den Wert schicken.

Example: the Bugs channel
ticket      Text          Required
title       Text          Required
status      Select        Required   new · triaged · in_progress · fixed · wont_fix
owner       Select                   aiko · mika · ren
severity    Select                   s1 · s2 · s3 · s4
points      Number                   min 0, max 13
area        Multi-Select             billing · auth · api · ui
due         Date
age_days    Formula                  computed

Beispiel: Der Tab Schema des Record-Channels Bugs

Ein Formula-Feld wird aus seinem Ausdruck berechnet. Niemand schreibt hinein, auch Codex nicht.

3. Die Verbindung zum Projekt hinzufügen und ihre Tools prüfen

Klick auf das Schlüsselsymbol im Header und öffne Connected. Wähle die Codex-Verbindung. Unter Projects wählst du das Projekt und klickst auf Add to project (zum Projekt hinzufügen). Damit öffnet sich der synchronisierte Inhalt des Projekts für diese Verbindung, Record-Channels eingeschlossen.

Weiter unten öffnest du Tools. Die Checkliste zeigt die Tool-Namen mit Leerzeichen, such also nach "list record items", "read record item", "edit record item" und "poll resource events". Alle unterstützten Tools sind standardmäßig an. Soll Codex vorerst nur lesen, nimm den Haken bei "edit record item" raus und klick auf Save tools (Tools speichern).

Beispiel: Die Verbindung Codex CLI mit hinzugefügtem Projekt "Product"

4. Einschränken, was Codex angeboten wird

Codex filtert Tools auch auf seiner Seite. Für die Triage reichen sechs:

[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",
  "list_project_resources",
  "list_record_items",
  "read_record_item",
  "edit_record_item",
  "poll_resource_events",
]

list_record_items, read_record_item und poll_resource_events sind auf dem Server als read-only markiert, mit "writes" laufen sie also ohne Rückfrage. Vor jedem edit_record_item fragt Codex nach. Bei einem Durchlauf über 40 Items sind das 40 Rückfragen. Es sind aber auch 40 Gelegenheiten, es anzuhalten.

5. Mit ausformulierten Regeln fragen

In osFoundry, open the "Bugs" record channel in the Product project.
Go through every item with status "new", newest first.
For each one: read it, then set status to triaged, pick an owner by area
(billing → aiko, auth → mika, everything else → ren) and a severity.
Use the option values from the schema, not the labels.
If osFoundry rejects a value, don't guess. Leave that field and list the
item at the end.

Ein echter Durchlauf

Auf dem Rechner, auf dem dieser Text entstand, ist Codex nicht installiert, daher ist die Sitzung unten ein simuliertes Beispiel. Tool-Namen und Argumente sind die, die der Live-Server in tools/list auflistet. Codex zeigt dem Modell MCP-Tools als mcp__<server>__<tool>. Channel, Items und Antwort sind Demo-Inhalte.

Example (simulated)

• mcp__osfoundry__list_project_resources {"project_id": "…", "resource_type": "record_channel",
      "search": "Bugs"}
  ← record channel "Bugs", id 4127
• mcp__osfoundry__list_record_items {"record_channel_id": "4127", "limit": 50}
  ← schema: 11 fields · 50 item previews · more before item 9811
• mcp__osfoundry__list_record_items {"record_channel_id": "4127", "before_id": "9811", "limit": 50}
  ← schema · 23 item previews · no more pages
  (38 of the 73 items have status "new")
• mcp__osfoundry__read_record_item {"record_channel_id": "4127", "item_id": "9874"}
  ← BUG-1873 "Invoice PDF shows last month's total", area ["billing"], version "…14.208311Z"
• mcp__osfoundry__edit_record_item {"record_channel_id": "4127", "item_id": "9874",
      "values": {"status": "triaged", "owner": "aiko", "severity": "s2"},
      "expected_version": "…14.208311Z", "idempotency_key": "triage-9874"}
  [Codex asks: allow this tool call? → yes]
  ← saved
  … 36 more items …
• mcp__osfoundry__edit_record_item {… "item_id": "9790",
      "values": {"status": "triaged", "owner": "ren", "severity": "s3", "points": 20}, …}
  ← rejected: points must be between 0 and 13
• mcp__osfoundry__read_record_item {… "item_id": "9790"}
• mcp__osfoundry__edit_record_item {… "values": {"status": "triaged", "owner": "ren", "severity": "s3"}, …}
  ← saved
• mcp__osfoundry__edit_record_item {… "item_id": "9802", …, "expected_version": "…02.551904Z"}
  ← rejected: the item changed after that version
• mcp__osfoundry__read_record_item {… "item_id": "9802"}
  ← status "in_progress", owner "mika" (set by Mika in osFoundry a minute ago)

Triaged 37 of 38 new items. BUG-1791's description says "about 20 points",
but Points only goes to 13, so I left it empty. BUG-1805 was already
in progress with Mika, so I didn't touch it.

Zwei Ablehnungen haben hier die Arbeit gemacht. Das Feld Points ist in diesem Beispiel bei 13 gedeckelt, also wurde die Änderung mit 20 komplett abgewiesen. Codex hat dieses eine Feld weggelassen und den Rest gespeichert. Es hat 20 nicht auf 13 gekappt, denn eine gekappte Schätzung sieht aus wie eine echte. Die zweite Ablehnung ist die Versionsprüfung. Mika hatte das Item zwischen dem Lesen und dem Schreiben von Codex übernommen. Codex hat es neu gelesen, den neuen Status und Owner gesehen und sie in Ruhe gelassen, statt ihre Arbeit mit seinem Plan zu überschreiben.

Geblättert wurde über before_id. Jede Seite endet mit dem ältesten Item, das sie enthält, und die nächste Seite fragt nach Items vor diesem. Bugs, die gemeldet werden, während Codex liest, schieben keine älteren Items auf die nächste Seite, also wird nichts doppelt gelesen.

Beispiel: Der Tab Data nach dem Durchlauf, Status und Owner ausgefüllt

Der Tab Data zeigt das Ergebnis so, wie das Grid es immer tut. Status erscheint als Label der Option, "Triaged", in der Farbe der Option, falls sie eine hat, und nicht als gespeicherter Wert triaged. Ein Item, das jemand anderes geändert hat, behält die Werte dieser Person.

Wo die Grenze liegt

Das Schema ist die Grenze für Werte. Codex kann in ein Feld nur das schreiben, was das Feld akzeptiert, und Select-Felder akzeptieren die Werte ihrer Optionen. Die Labels "In progress" oder "Aiko Tanaka" werden abgelehnt, nicht umgewandelt. Eine Umwandlung müsste raten. "major" könnte S2 bedeuten, und "Won't fix" und wont_fix sehen nur für einen Menschen gleich aus. Wenn Codex bei einem Feld nicht mehr nachfragen soll, ändere das Feld im Tab Schema. Von außen kann Codex es nicht lockern.

Codex bearbeitet Werte und sonst nichts. Über MCP gibt es kein Tool, um ein Item anzulegen, eines zu löschen oder ein Feld hinzuzufügen. Duplikate schließen und den Tracker umbauen passiert in der App, wo Versions und der eigene Verlauf des Channels zeigen, wer es war.

Jeder Aufruf wird bei seinem Eintreffen geprüft. Der Status der Verbindung, das Projekt, in dem der Channel gerade liegt, und deine eigenen Rechte darauf werden pro Aufruf ausgewertet. Ein früher ausgestelltes Token hält den Zugriff nicht offen, nachdem du das Projekt entfernt oder auf Revoke connection (Verbindung widerrufen) geklickt hast. Erreichbar sind nur synchronisierte, gehostete Channels. Die initialize-Antwort des Servers sagt "Local-only data is unavailable to cloud clients."

osFoundry sieht die Aufrufe, nicht die Sitzung. Recent activity listet Tool-Name, Zugriffsentscheidung und Uhrzeit. Die Überlegungen von Codex und dein Repository bleiben auf deinem Rechner.

Wie es weitergeht

Starte am nächsten Morgen denselben Prompt, aber beginne mit poll_resource_events auf dem Record-Channel ab der Sequenz, die Codex sich am Ende des letzten Durchlaufs notiert hat. Es liefert die Events des Channels nach dieser Sequenz, sodass Codex nur die paar Items neu liest, die sich bewegt haben, statt des ganzen Trackers. Wie ein Item auf der Seite von osFoundry aussieht, mit Formularansicht und Verlauf, steht auf der Seite zu den Record-Details.