Stage-Codex-Plugin: Rollen- und Workspace-Policy

Das Plugin mcp_codex_cli_plugin läuft auf stage.webdevmedia.de in Version 1.10.1. Ein serverseitig authentifizierter Principal mit der exakt wirksamen Rolle admin umgeht die Tool-, Capability-, Profil- und Workspace-Allowlists dieses Plugins. Die Ausnahme erweitert weder Betriebssystemrechte noch die rollenunabhängigen Sicherheitsgrenzen.

LIVE seit 1. September 2026. Codex CLI 1.10.1 stammt aus stage_mcp_plugins-Commit 282b52b2a471 und wurde als Release mcp-codex-cli-1.10.1-282b52b2 mit Tree-SHA-256 2817c89200dc…7da23d atomar veröffentlicht. Telegram Support 1.2.0 blieb unverändert.

Ursache der früheren Admin-Ablehnung

Bis Version 1.7.1 wählte Annahme und Worker den Quick-Sonderpfad allein anhand des Profils. Dadurch galt auch für Admins die Nicht-Admin-Quick-Prüfung. Diese verlangte ein beschreibbares, kanonisches inaktives Theme oder freigegebenes Plugin und lehnte jede Symlink-Eingabe pauschal mit folgender Meldung ab:

Quick requires a writable canonical directory without symlinks.

Die Meldung entstand damit aus einer Kombination: Der Admin wurde fälschlich in die rollenbasierte Quick-Workspace-Allowlist eingeordnet, und dieser Pfad enthielt zusätzlich eine pauschale Symlink-Sperre. Weder Principal-Auflösung noch Stage-Drift oder der zentrale Account-Dispatcher waren die Ursache. Der vor dem Rollout aktive Pluginbaum war vollständig Git-identisch mit dem damaligen main.

Version 1.8.0 bündelt die Entscheidung in einer gemeinsamen Policy für Discovery, Annahme und Worker. Der Fehlertext wurde nicht bloß verändert; der Admin nimmt den Quick-Sonderpfad nicht mehr.

Rollen- und Profilvertrag

Admin sieht alle 14 registrierten Codex-Plugin-Tools und darf sie aufrufen. Dazu gehören Profilstart, Polling, Resume, Jobverwaltung, Status, Site Locator sowie die getrennten Auth-Funktionen. Ein serverweiter Schreib-Not-Aus bleibt der Plugin-Policy übergeordnet.

Getrennter Site-Locator-Profilvertrag

Die Profilnamen des Site Locators sind nicht mit den allgemeinen Codex-Ausführungsprofilen in der vorigen Tabelle gleichzusetzen. Für codex_cli__locate_site_implementation gilt:

Ohne search_mode gilt LLM-first. llm und deterministic erzwingen den jeweiligen Pfad. Der deterministische Fallback ist nur bei einem technischen LLM-Ausfall und nur für eine hochkonfidente lokale Fundstelle zulässig. reasoning_effort und detail akzeptieren low, medium, high, xhigh und ultra; ohne detail entspricht der Umfang dem wirksamen Reasoning. Die tatsächliche Modellunterstützung bleibt adapterabhängig.

Der parameterlose Stage-E2E-Smoke endete mit resolution_mode: remote_llm, dispatch_state: accepted, search_mode: llm_preferred, Profil quick und low für Reasoning und Umfang. Beim vollständigen Snapshot wurde Spark technisch abgelehnt und Luna übernahm nachvollziehbar als model_fallback: quick_spark_to_fast_luna. Explizite deterministische Suche blieb not_dispatched; der simulierte LLM-Ausfall führte zu deterministic_fallback.

Für Nicht-Admins bleiben Rollenrang, Tool-/Capability-Filter, Profilgrenzen und konfigurierte Arbeitswurzeln unverändert:

• Customer darf Quick und die vorgesehenen Lese-/Komfortfunktionen verwenden.
• Developer erhält zusätzlich Balanced, aber weder Heavy noch Ultra.
• Heavy und Ultra bleiben Admin-Funktionen; Ultra akzeptiert nur xhigh.
• Nicht-Admin-Quick behält seinen ausführlichen, redigierten Content-, Datenbank- und Codekontext sowie die Begrenzung auf ein inaktives Theme oder ausdrücklich freigegebenes unkritisches Plugin.
• Nicht-Admins verwenden weiterhin die rollenabhängigen sicheren Git-Komfortfunktionen statt git__command_run.
• Leere, unbekannte, anders geschriebene oder requestseitig behauptete Rollen werden zu guest, niemals zu Admin.

Kanonischer Workspace-Snapshot

Für Admin-Arbeitsverzeichnisse gilt folgender gemeinsamer Ablauf:

1. Eingabe auf leeren Wert, NUL, Existenz und Verzeichnistyp prüfen.
2. Den Requestpfad genau einmal mit realpath auflösen. Ein kontrollierter Deployment-Symlink ist als Eingabe zulässig; Dangling Links bleiben ungültig.
3. Nur den realen Zielpfad und seine Dateisystemidentität aus Device und Inode in den Policy-Snapshot übernehmen.
4. Die Identität nach Queue-Annahme, im Worker vor und nach dem Account-Preflight sowie unmittelbar vor Prozessstart erneut prüfen.
5. Bei fehlendem oder ausgetauschtem Ziel mit einem stabilen Policy-Fehler abbrechen. Ein später umgehängter Request-Symlink verändert den bereits gebundenen Job nicht.

Admin überspringt dabei nur die konfigurierten Produkt-Arbeitswurzeln. Nicht-Admins müssen weiterhin innerhalb ihrer Rollenwurzeln bleiben; Quick behält zusätzlich seine Theme-/Plugin- und Aktivierungsprüfung. Traversal, Stringpräfix-Tricks und Shell-/CLI-Flag-Injektion werden nicht durch die Admin-Ausnahme erlaubt.

Einheitlicher Jobvertrag

Jeder neue lokale Job bindet unveränderlich:

• Principal und wirksame Rolle;
• Policy-Version und Admin-/Quick-Entscheidung;
• Profil, Modell, Reasoning-Effort und Sandboxentscheidung;
• kanonischen Workspace und Dateisystemidentität;
• den unter gemeinsamem Lock validierten Account-/Registry-/Runtime-Snapshot.

Discovery, Annahme, Worker, Polling und Resume verwenden dieselbe Entscheidung. Resume übernimmt Principal, Rolle, Policy, Profil, Modell, Effort, Workspace und Account-Snapshot des Ursprungsjobs; requestseitige Modell- oder Effort-Wechsel werden abgewiesen. Eine spätere zentrale Account-Auswahl hängt einen bestehenden Job nicht um.

Admin behält den bereits dokumentierten administrativen Einblick in lokale und historische Jobs. Diese Einsicht überträgt weder Eigentum noch Principal-Bindung auf andere Rollen. Nicht-Admins dürfen ausschließlich ihre eigenen principalgebundenen Jobs lesen, pollen, abbrechen oder fortsetzen.

Asynchrone Annahme, Korrelation und JSONL-Härtung

Der Korrelationskandidat übernimmt ausschließlich eine gültige kanonische X-Correlation-ID und die positive Versuchszahl aus X-Correlation-Attempt. Die Korrelation wird in redigierten Stage- Betriebsereignissen, unveränderlichen Jobmetadaten und den relevanten Dispatch-/Terminalereignissen geführt. Sie ersetzt weder die Stage-Request-ID noch die Job-ID. Der vollständige Header- und Fehlervertrag steht unter Codex REST & MCP.

Balanced, Heavy und Ultra sind echte asynchrone Übergaben: Nach atomarer Jobannahme antwortet der Start mit job_id, Korrelation und eindeutigem dispatch_state, ohne auf erste Workerereignisse zu warten. Eine ausdrücklich angeforderte Vorschau bleibt kurz und transportgebunden; ihr Ausbleiben ändert eine bereits bestätigte Annahme nicht. Polling ist der kanonische Weg zum terminalen Ergebnis.

Die Start-Idempotenz bindet Principal, Operation, stabile Idempotenz und einen Hash der sicherheitsrelevanten Startparameter. Ein identischer Retry liefert denselben Job mit already_accepted; abweichende Parameter unter derselben Idempotenz enden stabil als Konflikt. Ein Read-Timeout nach möglicher Annahme gilt außen als unknown_after_timeout: Der Client fragt mit derselben Korrelation/Idempotenz erneut an und startet keinen Ersatzjob.

Dieser neue Vertrag gilt ausschließlich für lokale Profilstarts über Quick, Balanced, Heavy und Ultra. Die weiterhin Master-fähigen Werkzeuge prompt, start ohne lokales Profil und resume verwenden ihren bestehenden Relay- Vertrag und bewerben deshalb keine lokale idempotency_key-Semantik. Eine Ausweitung auf den Master-Relay wäre ein eigener Rollout mit eigener Persistenz- und Timeoutprüfung.

Event-JSONL wird pro Job unter Lock und mit einer vollständigen Write-Schleife geschrieben. Ein abgebrochener partieller Datensatz wird nicht als Erfolg behandelt. Leser melden beschädigte physische Zeilen mit einem redigierten jsonl_corruption-Hinweis und Zähler, statt sie still zu verschlucken. Gültige Ereignisse vor und nach der Stelle werden weiter geliefert; wiedergewinnbare, aneinandergeklebte JSON-Objekte werden einzeln ausgewertet. Rohzeile und privater Speicherpfad erscheinen weder in der Antwort noch im allgemeinen Log.

LIVE: Korrelationshärtung ausgerollt

Der Vertrag läuft aus Commit 3f9585569a00 als Releases mcp_codex_cli_plugin-1.9.0-3f9585569a00 und mcp-telegram-support-plugin-1.2.0-3f9585569a00. Ein echter korrelierter Start mit Idempotenz-Replay und Polling endete erfolgreich. Beide Plugins wurden danach atomar auf ihre exakten Vorgänger zurückgetauscht, gesund geprüft und als dieselben Kandidaten reaktiviert. Active und Fallback blieben unverändert.

Sicherheitsinvarianten für alle Rollen

• Authentifizierung und ausschließlich serverseitige Rollenableitung;
• Principal-/Mandantenisolation, opake Job-IDs und Job-Eigentum;
• confirm=true und Admin-Gate für Accountwechsel, Reset-Credits und vergleichbare destruktive Accountaktionen;
• Request-Schema, Größen-, Queue-, Laufzeit- und Retentiongrenzen, Idempotenz sowie atomare Jobdateien;
• kanonische Pfad- und Typprüfung, Prozessgruppen, Cancel und Timeout;
• vollständiges versionsgleiches CLI-/Companion-/Runtime-Bundle und Betriebssystemrechte;
• Secret-/PII-Redaction sowie Audits mit Hashes statt Prompt, Antwort, Accountidentität oder privatem Pfad.

MCP-Status und Jobantworten bestätigen Account- und Workspace-Bindung nur mit Booleschen Werten beziehungsweise nicht umkehrbaren Fingerabdrücken. Prompt, Resultat, Authorization-Header, Credentialwerte und private absolute Account-/Queuepfade gehören nicht in allgemeine Logs oder öffentliche Antworten.

Account-Auswahl und Runtime

Neue Codex-Prozesse beginnen ausschließlich über den kanonischen Dispatcher codex-current. Vor einem risikobehafteten Wechsel müssen codex-current --status und codex-current --preflight erfolgreich sein. Eine Session wählt weder selbstständig ein Accountprofil noch einen direkten Account-, Binary- oder Companion-Pfad.

Der Dispatcher liest die bewusst gewählte Registryposition unter dem gemeinsamen Lock, prüft das vollständige Runtime-Bundle und friert Wrapper, Laufzeit und Profil für den gestarteten Prozess ein. Ein Auswahlwechsel gilt nur für spätere Prozesse. Dokumentierte Standalone- und Direktwege bleiben Diagnose- und Rollback-Fallbacks, nicht der normale Auswahlmechanismus.

Bekannter fail-closed Quick-Runtimezustand

Die Nicht-Admin-Quick-Policy wird auf Stage korrekt angenommen und der redigierte Content-/Datenbankkontext erzeugt. Die echte Prozessprobe endet derzeit jedoch mit quick_enforcement_unavailable, weil weder ein nutzbares Bubblewrap noch unprivilegierte User-Namespaces verfügbar sind. Version 1.7.1 zeigte denselben Zustand. Es gibt absichtlich keinen danger-full-access-Fallback für Nicht-Admins; eine spätere Behebung benötigt einen getrennten, versionierten Runtime-/Kernel-Entscheid.

Release, Smoke und Rollback

Der aktive Codex-Baum für Commit 282b52b2a471 besitzt den Publisher-Hash 2817c89200dc…7da23d. Der direkte Vorgänger 1.10.0 bleibt im geprüften Austauschverzeichnis erhalten. Der unveränderte Telegram-Support-Baum besitzt weiterhin den Publisher-Hash e666e1fac958…eeec72. Konfiguration, Queue und Secrets sind nicht Teil der Bäume.

Der Stage-Publisher tauscht das direkte aktive Pluginverzeichnis und ein vorbereitetes Geschwisterverzeichnis mit Linux RENAME_EXCHANGE. Das aktive Plugin ist selbst kein Symlink. Ältere geprüfte Bäume, darunter Codex CLI 1.9.0 und 1.8.0 sowie Telegram Support 1.1.1, bleiben als getrennte historische Rückwege erhalten; ein Rücktausch verwendet immer ein zuvor gehashtes exaktes Paar.

Vor jedem Tausch:

1. aktuellen Commit, Version, Baumhash, WordPress-Aktivierung und laufende Worker prüfen;
2. altes Plugin zusätzlich als owner-only Archiv sichern;
3. neues Verzeichnis ausschließlich aus dem versionierten Commit bauen und gegen den sauberen Worktree vergleichen;
4. PHP-Syntax, Unit-/Policy-/Runner-Tests und Secret-/PII-Scan ausführen;
5. codex-current --status und --preflight ohne Ausgabe von Accountdetails prüfen.

Nach dem Tausch sind mindestens erforderlich:

• WordPress-Pluginstatus und HTTP 200;
• MCP-Discovery aller 14 Codex-Tools sowie Status admin_allowlist_bypass: true;
• Admin Quick über einen kontrollierten Off-Allowlist-Symlink, Polling und Resume;
• negative Customer-/Developer-Fälle für Symlink, Workspace, Ultra und fremdes Job-Eigentum;
• Developer Balanced, Admin Heavy/Ultra, Master-Relay, Site Locator und Runtime-Code-Mode;
• git__command_run als harmloser strukturierter git status --short in einem isolierten Stage-Testrepository;
• Bestätigungsgates und Redaction ohne Accountidentitäten oder private absolute Pfade.

Schlägt ein Health- oder Policy-Gate fehl, wird sofort atomar zurückgetauscht und der Rückweg erneut geprüft. Beim Rollout von 1.9.0/1.2.0 wurde dieser Rückweg praktisch und kontrolliert ausgeführt: Beide Vorgänger waren mit WordPress-Aktivierung, HTTP 200 und MCP-Katalog gesund; danach wurden dieselben Kandidaten reaktiviert und mit Discovery, korreliertem Job-Smoke sowie lokalem Fake-Transport ohne externe Nachricht freigegeben.