codex-master

The Hive (Legacy-Namen: codex-master, codex-master-mcp und Masterjet) ist die lokale MCP-Steuerungsebene für eine schlafende/skalierbare Codex-Agentinnen-Flotte. Das Fleet-Registry ist maßgeblich für aktive Serien; die Legacy-Pool-Spezifikation wird nur aus Kompatibilitätsgründen beibehalten.

Versionierte lokale Wiki-Quellen beginnen bei docs/wiki/Home.md. Sie bleiben in diesem Repository kanonisch; eine GitHub-Wiki-Veröffentlichung ist nicht impliziert. Fleet-Übersicht, G-Serie und Goddess-Reporting-Vertrag: docs/operations/goddess-reporting.md.

Lebenszyklus des Resource-Monitor-H4-Operators

codex-master-resource-monitor.service führt den argumentfreien %h/.local/bin/codex-master-resource-monitor-Einstiegspunkt aus. Er erhält nur den zentral zusammengestellten Hive-Zustandsspeicher und veröffentlicht vollständige Ein-Hz-Generationen unter seinem festen resources-Unterbaum. Der H4-Lebenszyklus ist von der Hauptinstallation getrennt.

Standardmäßig wird codex-master-resource-monitor.service ausgeliefert, aber nicht installiert oder aktiviert. Kein Installer, MCP-Tool oder Standardtest aktiviert oder startet diese Einheit implizit; nur diese expliziten Operator-Befehle tun dies:

./bin/codex-master-mcp install-resource-monitor --force
./bin/codex-master-mcp resource-monitor-status

Der Installer validiert sowohl die begrenzten regulären Repository-Einheiten als auch beide Zieleinheiten vor der Mutation. Eine kooperative Prozesssperre (install_lock()/flock) umfasst Quellvalidierung, Staging, die Transaktion, Daemon-Neuladen, Aktivierung und Rollback. Sie serialisiert kooperative Installer-Prozesse; Manipulationen mit gleicher UID/Root oder User-Systemd-Namespace außerhalb dieser Grenze sind keine gegnerische Mutex-Bedrohung, die von H4 abgedeckt wird. Quell-Lesevorgänge verwenden No-Follow-FDs mit Identitäts-/Typ-/Größen-/Modus-/mtime-Prüfungen vor und nach begrenzten Lesevorgängen. Die Zielverzeichniskette wird nur für das fehlende Suffix sicher erstellt, dann durch FD plus (dev, ino) fixiert; unsichere Vorfahren, Symlinks, oder gruppen-/weltbeschreibbare vorhandene Verzeichnisse schließen fehlgeschlagen ab. Gemeinsame Sticky- Vorfahren sind erlaubt; das endgültige ~/.config/systemd/user muss benutzergehören und nicht gruppen-/weltbeschreibbar sein.

Beide Einheiten werden vor der ersten Mutation gestaged und validiert. Vorhandene Einheiten werden FD-relativ zu eindeutigen geprüften Backups verschoben. Gestagte Einheiten werden mit No-Replace-link installiert; EEXIST bewahrt das fremde Ziel. Per-Einheit-Journale zeichnen ursprüngliche/gestagte Identitäten, Haltbarkeit, Verschiebungen, Wiederherstellungen und Bereinigung auf. Rollback entfernt nur die journalisierte installierte Identität, stellt Backups ohne Überschreiben wieder her, bewahrt fremde Dateien/Backups und meldet manuelle Wiederherstellung, wenn nötig. Beim Rollback werden keine Bytes oder Modi abgeleitet.

Nachdem beide Einheitenmutationen dauerhaft sind, öffnet der Installer den ursprünglichen Zielpfad erneut ohne Follow und validiert die fixierte (dev, ino), die gehaltene kanonische Sperridentität, und beide journalisierten installierten Einheitenidentitäten vor dem Daemon-Neuladen und erneut vor enable --now. Jede Abweichung verhindert die nächste externe Operation, einschließlich Rollback-Neulade-/Zustandsratungen; Datei-Rollback verwendet nur die fixierte FD. Eltern-Neubindung bedeutet kein primäres Neuladen und Rollback über die ursprüngliche FD. Daemon-Neuladen läuft vor enable/start, und nur codex-master-resource-monitor.service wird aktiviert/gestartet; die Slice wird nie separat aktiviert/gestartet.

Dies ist kein atomarer Paarersatz. Jede Operation ist atomar pro Datei/Name, aber ein Absturz zwischen den zwei Umbenennungen kann ein gemischtes Paar hinterlassen. Das Prozessjournal ist im Speicher und geht bei einem Absturz verloren. Die Wiederherstellung verwendet dann nur Dateisystem-Beweise, Einheiten-/systemd-Status, resource-monitor-status und manuelle Inspektion/Wiederherstellung. Status erkennt gemischten oder fremden Zustand und der Operator muss manuell wiederherstellen. Rollback versucht unabhängig beide Einheiten, Temp-/Backup-Bereinigung, Daemon-Neuladen, UnitFileState-Wiederherstellung und ActiveState-Wiederherstellung. Unbekannter Zustand verursacht keine Vermutung. Anfängliches not-found ist nur gültig mit inaktivem LoadState=not-found; andernfalls muss UnitFileState disabled, enabled oder enabled-runtime sein, und ActiveState muss aktiv/inaktiv sein. Zustandswiederherstellung verwendet exakte persistente vs. Laufzeit-Flags und überspringt nie die ActiveState-Wiederherstellung nach UnitFileState-Fehler. Öffentliche Fehler enthalten nur Codes/Rückgabecodes, nie Pfade oder Rohausgabe.

Manifest-Präsenz ist kein Hook-Vertrauen. Fehlende, fehlerhafte, nichtkanonische oder veraltete V2-native Abdeckung meldet manual_hook_trust_or_new_session_required; nur eine neue reguläre Codex-Sitzung nach explizitem Benutzer-/hooks-Vertrauen erstellt frische V2- Abdeckung. Kein Befehl automatisiert Vertrauen oder bearbeitet synthetischen nativen Zustand.

Eine inaktive kinderlose codex-master.slice wird nur mit einem echten FragmentPath und materialisierter Einheit erwartet. Fehlender oder synthetischer FragmentPath ist ein Blocker, kein installierter Status. Bereit-Status erfordert echte Fragmente für beide Einheiten, aktives Monitor-Kind und frische gültige Momentaufnahme. Live-Spawn wird nur angeboten, wenn resource-monitor-status grün ist. Das Haupt-install-Verhalten ist unverändert. ProtectHome=tmpfs und PrivatePIDs=yes verbergen nicht zusammenhängende Home- und Prozessdaten. BindReadOnlyPaths legt nur das installierte Monitor-Layout, feste Kataloge und den zentralen Hive-Zustand offen; D8 hält Schreibzugriff auf resources und die vorhandene Sperre beschränkt.

• /home/teladi/.codex-agents/a1 bis /home/teladi/.codex-agents/a100

• /home/teladi/.codex-agents/b1 bis /home/teladi/.codex-agents/b100

• /home/teladi/.codex-agents/c1 bis /home/teladi/.codex-agents/c100

Legacy-Selektoren a und b bilden auf a1 und b1 ab; both bildet auf a1,b1 ab. Serien-Selektoren a-series, b-series, c-series und all sind verfügbar für Status, Fähigkeiten, Capabilities, Leasing-Status, Start/Stopp und Watchdog-Aufrufe. Selektoren sind case-insensitiv, also A1, a1, A-Series und a-series lösen identisch auf. Numerische Einzel-Agentin-Selektoren verwenden die aktuelle Selektorpolitik. Die Standardpolitik ist abwechselnd A/B: 1=a1, 2=b1, 3=a2, 4=b2 und so weiter. Ändern Sie sie mit:

./bin/codex-master-mcp selector-policy --series a,b,c
./bin/codex-master-mcp selector-preview --series a,b,c --limit 6

Die Politik wird im privaten MCP-Zustand gespeichert und kann auch für einen Prozess mit CODEX_MASTER_AGENT_SELECTOR_SERIES=a,b,c überschrieben werden. Teamleiterinnen können fremde Bienen direkt durch den Masterjet mit agent_start, agent_claim und den strukturierten agent_assign*-Tools spawnen. Leases, Auth-Prüfungen und Schreibbereiche sind die Koordinationsgrenze; sie sind kein Grund, verfügbare fremde Bienen zu vermeiden. Die ursprünglichen authentifizierten Homes bleiben als a1 und b1 erhalten. Zusätzliche Homes sind absichtlich schlank und standardmäßig schlafend; sie haben ihr eigenes CODEX_HOME, Wrapper, Konfiguration, tmux-Sitzungsname, Lease und Metadaten, während große, meist gelesene Skill-/Plugin-/Modell-Cache-Dateien von einer Serienvorlage symlinkiert werden können. C-Serie-Homes sind absichtlich nicht authentifiziert, bis ein anderes Konto verfügbar ist.

Der Wrapper startet Instanzen über ihre pro-Home-codex-Launcher-Dateien. Bevor die zentrale Auflösung ein effektives Tupel liefert, ist seine Basisvorgabe gpt-5.6-luna mit mittlerer Argumentation:

--model gpt-5.6-luna -c 'model="gpt-5.6-luna"' -c 'model_reasoning_effort="medium"' --yolo -s danger-full-access --search

Es verwendet tmux als PTY-Backend. Die vollständige Terminalausgabe wird nur in lokale Zustandsdateien unter ~/.local/state/codex-master-mcp/raw/ geschrieben. Neue Rohprotokolle sind auf 5 MiB pro Datei begrenzt, und verwaltete Rohprotokoll-Verzeichnisse behalten standardmäßig höchstens 20 Dateien. Vorbereitete Rohprotokoll-Dateien werden mit No-Follow-Exklusiv-Semantik erstellt. Der direkte Rohprotokoll-Schreiber verlangt außerdem, dass die verwalteten Zustandsverzeichnisse und ihre übergeordneten Ketten echte Verzeichnisse sind, keine Symlinks, und veraltete Rohprotokoll-Verzeichnisse werden ignoriert, wenn sie Symlinks sind. Agentin-Runner müssen reguläre ausführbare Dateien sein, keine Symlinks. Zuordnungsprotokoll-Lesevorgänge erfordern reguläre Dateien, sind begrenzt und verwenden generische Fehler. Private Zustandsdatei- und Verzeichnisfehler sind generisch und vermeiden die Rückgabe lokaler Zustandspfade. Agentin-Metadaten-Präsenzprüfungen folgen keinen Symlinks, Metadaten-Lesevorgänge lehnen symbolisch verlinkte und überdimensionierte Dateien ab, und Metadaten-Lesefehler verwenden generische Marker anstelle lokaler Dateipfade. Safe-Tail-Protokolllesevorgänge ignorieren nicht-reguläre Rohprotokoll-Ziele. Tmux-Steuerungsfehler werden redigiert und begrenzt, bevor sie zurückgegeben oder ausgelöst werden. MCP-Tool-Antworten geben standardmäßig keine Rohausgabe zurück und legen das Vorhandensein von Rohprotokollen offen, ohne lokale Rohprotokollpfade zurückzugeben. Text wird über tmux in die Codex-TUI eingefügt und mit einfacher Enter-Taste übermittelt. Mehrzeilige Eingabeaufforderungen verwenden Klammer-Einfüge-Marker, sodass die vollständige Eingabeaufforderung vor der Übermittlung ein einziger Composer-Eintrag bleibt.

Vor dem Einfügen warten send, assign-* und report-request kurz auf einen identifizierbaren Codex-TUI-Eingabeaufforderungs-Marker im sichtbaren Pane-Ende. Wenn sich der Agentin noch in Startwarnungen befindet, nur Starttext anzeigt oder keine Eingabeaufforderung sichtbar ist, schlägt die Mutation mit wiederholbarem agent_input_not_ready, paste_attempted: false und raw_output: not_returned fehl, anstatt die Eingabeaufforderung im Startbildschirm zu verlieren. Vorhandene Metadaten unter dem alten codex-agent-mcp-Zustandsverzeichnis werden weiterhin als Migrations-Fallback gelesen. Externe tmux-, git- und codex mcp-Subprozesse sind zeitbegrenzt, sodass MCP-Aufrufe fehlschlagen, anstatt unbegrenzt zu hängen. MCP-Registrierungsprüfungen vergleichen das exakte command:-Feld aus codex mcp get, nicht eine breite Teilzeichenfolge in der Befehlsausgabe.

Agentin-Lebenszyklusoperationen, die tmux-Sitzungen mutieren oder in sie senden, werden pro Agentin mit privaten No-Follow-Sperrdateien serialisiert, sodass verschiedene Agentinnen weiterhin unabhängig laufen können, während gleichzeitige Starts/Stopps/Sendevorgänge für denselben Agentin nicht verschränkt werden können. Wenn tmux new-session fehlschlägt, bevor dieser Prozess eine Sitzung erstellt hat, entfernt die Bereinigung nur das vorbereitete Rohprotokoll und beendet keine vorhandene Sitzung, die einem anderen MCP-Prozess gehören könnte. Mutierende Tools verwenden außerdem einen Lease pro Agentin, sodass zwei Codex-CLI-Instanzen nicht gleichzeitig stillschweigend demselben Agentin zuweisen oder in ihn senden können. Lease-Konflikte geben strukturierte Wiederholungsmetadaten (error_code, retryable, retry_after_seconds und verbleibende Lease-Sekunden) zurück, ohne die Client-Identität offenzulegen. agent_claim wiederholt standardmäßig endlos, wenn eine fremde Biene beschäftigt ist; endliche wait_seconds-Werte bleiben verfügbar, sind aber nicht auf 600 Sekunden begrenzt. Verwenden Sie --no-wait für einen einzelnen sofortigen Anspruchsversuch. Das Standard-Poll-Intervall beträgt 30 Sekunden und das maximale Poll-Intervall 900 Sekunden.

Explizite Ansprüche stellen auch einen fremd gehaltenen Lease wieder her, wenn der Agentin nicht mehr läuft, kein Prozess dieses Agentin-Home verwendet und lokale Leerlauf-Beweise mindestens 120 Sekunden alt sind. Diese Wiederherstellung gestoppter Waisen kann mit --no-recover-stopped deaktiviert werden; sie gilt nicht für implizite Sende-/Berichts-/Unterbrechungs-Mutationen und überschreibt niemals einen laufenden fremden Agentin. Kurzlebige CLI-Aufrufe leiten einen stabilen, verborgenen Eigentümer aus CODEX_THREAD_ID ab, wenn Codex ihn bereitstellt, sodass dieselbe Schwesterinstanz über separate CLI-Aufrufe hinweg beanspruchen, zuweisen, Berichte anfordern und freigeben kann. CODEX_MASTER_MCP_INSTANCE_ID bleibt eine explizite Überschreibung für kontrollierte Sitzungen. Die abgeleitete Identität wird niemals in öffentlichen Antworten zurückgegeben.

agent_start verwendet nur einen transienten frischen Lease und gibt ihn nach einem erfolgreichen Start frei, sodass kurzlebige lokale CLI-Befehle den nächsten Operator-Befehl nicht blockieren. Verwenden Sie agent_claim explizit, wenn eine verbundene Codex-CLI-Instanz einen Agentin nach dem Start reserviert halten soll.

Mutierende Start-/Stopp-Selektoren, die zu mehr als 6 Agentinnen auflösen, schlagen fehl, es sei denn, allow_broad_selector=true wird übergeben. Dies verhindert, dass versehentliche all/Serien-Operationen große Teile des Pools starten oder stoppen. Arbeitsmutationen erfordern standardmäßig eine reguläre auth.json pro Agentin: agent_start, agent_claim, agent_send, agent_interrupt, agent_assign, agent_assign_readonly, agent_assign_live_data, agent_assign_write und agent_report_request schlagen fehl, wenn die Authentifizierung fehlt, symbolisch verlinkt ist, keine reguläre Datei ist, nicht lesbar ist oder zu groß ist. Status-/Fähigkeiten-/Lease-/Pool-/Stopp-/Freigabe-Operationen bleiben für Diagnose und Bereinigung verfügbar. Verwenden Sie --allow-unauthenticated nur für explizite Login-/Bootstrap-Abläufe.

Für ChatGPT-Authentifizierung prüft der Status auch den Ablauf eines JWT-Zugriffstokens, wenn vorhanden. Ein abgelaufenes Zugriffstoken wird als access_token_expired gemeldet und blockiert neue Mutationen, bis dieser Agentin wieder angemeldet ist. Das Kopieren eines rotierenden ChatGPT-Refresh-Tokens in mehrere Agentinnen wird nicht unterstützt; jeder Agentin benötigt seinen eigenen Login.

agent_status klassifiziert begrenzten Pane-/Protokolltext, ohne ihn zurückzugeben, sodass Aufrufer wahrscheinliche tägliche, wöchentliche, Token-, Kontingent- oder Ratenlimits von gewöhnlichen „noch keine Antwort"-Zuständen unterscheiden können. Die Klassifizierung hält Standard-Agentinnen-Modelllimits getrennt von Spark-Schreibmodell-Limits und meldet nur Metadaten plus evidence: not_returned. Limit-Metadaten trennen das laufende Sitzungsmodell, das neueste Zuordnungsmodell und das für das erkannte Limit abgeleitete Modell. Es klassifiziert auch einen bekannten Codex-TUI-Start-/Platzhalterkontext, ohne Pane-Text zurückzugeben, sodass Aufrufer erkennen können, wann ein Agentin die Zuordnung nicht als produktive Eingabe erhalten hat.

Öffentliche status-, skills-, capabilities-, app-bridge-status-, plugin-status-, namespace-status-, release-status-, watchdog-status-, timeout-policy- und doctor-Antworten geben keine lokalen Agentin-Home-, Runner-, Repo-, Manifest- oder Arbeitsverzeichnispfade zurück; sie geben stattdessen Zustands-/Kategoriemetadaten wie path_state, home_kind und cwd_state zurück. Öffentliche Bereichsprüfungen, Worktree-Status, Befehlsauszüge und Zuordnungs-Audit-Lesevorgänge redigieren ebenfalls absolute lokale Pfade; Zuordnungsaufforderungen erhalten weiterhin die expliziten Pfade, die die Teamleiterin zugewiesen hat.

agent_wait ermöglicht Aufrufern, auf Aktivität, Prozessbeendigung oder ein klassifiziertes Limit zu warten, ohne automatisch Agentin-Ausgabe zu erhalten. Es beträgt standardmäßig 120 Sekunden und ist auf 10 Minuten pro Aufruf begrenzt. Sein Poll-Intervall beträgt standardmäßig 30 Sekunden und ist auf 900 Sekunden begrenzt.

Zuordnungen sind asynchron. agent_wait und agent_report_request legen die relevante assignment_id auf oberster Ebene offen. Rufen Sie agent_assignment_report mit dieser ID auf, um einen kleinen ANSI-bereinigten, redigierten Terminalauszug zu erhalten. Dies ist die explizite Ausgabegrenze; Zuordnungsmetadaten und Warteergebnisse bleiben datenarm.

fleet_watchdog prüft im Leerlauf befindliche Agentinnen, ohne Rohausgabe zu lesen. Es verwendet standardmäßig einen Leerlauf-Schwellenwert von 60 Sekunden und fragt den Agentin vor jeder Eskalation nach einem prägnanten Bericht. Das Berichts-Gnadenfenster beträgt standardmäßig 15 Sekunden, sodass der nächste systemd-Timer-Durchlauf erst eskalieren kann, nachdem der Agentin ein Intervall zum Melden hatte. Der installierte systemd-Supervisor verwendet --action stop, sodass ungenutzte Agentinnen wieder in den Ruhezustand versetzt werden, anstatt aktiv zu bleiben. Standardmäßig mutiert der Watchdog nur Agentinnen, die vom aktuellen Server geleast sind; der systemd-Supervisor verwendet --manage-unclaimed --quiet, um nicht beanspruchte oder abgelaufene Leases zu behandeln, während aktive Leases anderer Clients übersprungen und erfolgreiches JSON-Rauschen im Benutzer-Journal vermieden wird.

Jeder Fleet-Watchdog-Lauf erstellt einen unveränderlichen In-Memory-Fleet-Snapshot für die verwalteten Prozess-Homes und tmux-Sitzungen. Die Agent-Bewertung verwendet diesen Snapshot wieder; eigenständige agent_status-Aufrufe behalten den Legacy-Live-Abfrage-Fallback. Lease-Freigabepfade validieren die Live-Sitzungs-/Prozessidentität unmittelbar vor der Freigabe neu. Eine nicht verfügbare tmux-Beobachtung wird als unbekannt gemeldet und überspringt Watchdog-Aktionen; sie wird niemals als gestoppte Sitzung interpretiert.

usage-watchdog konsumiert codex-usage-Snapshot-Zustand, schreibt einen lokalen codex-usage-Blockmarker und stoppt laufende Agentinnen, deren Konten ein zukünftiges verifiziertes Reset haben. Ein bereits vergangenes verifiziertes Reset hebt den Block auf; ein unbekanntes Reset bleibt Fail-Closed. agent_start-, Anspruchs-, Sende- und Berichtsanforderungsabläufe weigern sich, einen blockierten Agentin zu verwenden, bis der Watchdog ihn wieder freigibt.

Related MCP server: claude-code-mcp

Fleet-Konten, Serien und Gemini-Headless-Jobs

Die Fleet-Registry ist die Quelle der Wahrheit für jede anbieterunterstützte Serie und für native A/B/C-Materialisierung. Das Projekt trägt kanonisch den Namen The Hive; die Legacy-Namen oben bleiben gültige Aliase. Verwenden Sie zuerst die schreibgeschützten Konto-/Serienansichten und synchronisieren Sie dann Anmeldeinformationen lokal über den stdin-only-CLI-Ablauf:

python3 -m codex_master.server fleet account list
python3 -m codex_master.server fleet series list
python3 -m codex_master.server fleet provider-models --provider ollama_local
python3 -m codex_master.server fleet account sync-env --first-key 1 --last-key 30

Geheimnisse können transient im Kontrollzentrum oder im stdin-Ablauf eingegeben werden, werden aber niemals angezeigt, im UI-Zustand gespeichert oder von UI- oder normalen MCP-Ausgaben zurückgegeben. Sie werden nur in privaten Sidecars gespeichert und sind niemals Teil der Registry, von Zuordnungen oder der Shell-Historie. Kontogates erfordern ein konfiguriertes Geheimnis und eine erfolgreiche Admissionsprüfung. Veraltete oder unbekannte Gemini-Probes werden einmalig zum Aufrufzeitpunkt geprüft, sodass ein Nachbarprojekt dieses Projekt nicht veraltet macht. Gemini-RPM/TPM/RPD-Beobachtungen sind projektspezifisch; Abrechnungsstufe und Ausgabenobergrenzen können weiterhin vom Abrechnungskonto geteilt werden. Die gelieferten AI-Studio-Exporte bestätigen Tier 1 für the-hive-1 und the-hive-2 sowie Tier 0 für the-hive-3, the-hive-4, the-hive-6 und the-hive-10. Dies ist projektspezifischer Nachweis; die lokale Kontogruppe wird nicht verwendet, um die Stufe eines Projekts abzuleiten. Exakte RPM/TPM/RPD-Limits bleiben modell- und projektspezifisch; bekannte Werte werden nur für Projekte mit einer Rate-Limit-Tabelle in den gelieferten Snapshots importiert, und unbekannte Werte werden lokal niemals erraten. Die dokumentierte Ausgabengrenze von Tier 1 beträgt 10 $ pro rollierender 10-Minuten-Periode und die Abrechnungskonto-Obergrenze 250 $ pro Monat. Der lokale Nutzungsrechner meldet beobachtete RPM/TPM/RPD und verwendet jetzt die gelieferten AI-Studio-Snapshots für bekannte Projekt-/Modellpaare. Er hält die Limits modellspezifisch und gibt model_required oder limits_unknown_dashboard_required zurück, wenn kein anwendbarer Snapshot existiert. Die Ausgabenauslastung bleibt billing_export_required, da ein API-Schlüssel allein keine Abrechnungsausgaben offenlegt.

Importierte Rate-Limit-Snapshots:

Die Snapshot-Quelle ist die gelieferte Tier 0 (kostenlos).mhtml und Tier 1 (Billing).html; aktualisieren Sie sie, wenn AI Studio die aktiven Projektlimits ändert.

fleet_gemini_bootstrap_plan bleibt ein geheimnisfreier Kompatibilitäts-Dry-Plan-Helfer. Er erstellt keine ausgemusterten D/E/F-Serien; die Laufzeitaktivierung erfolgt über befüllte The_Hive_N-Einträge in der privaten Tokendatei. Schlüssel 1–10 gehören zu einem Abrechnungskonto mit einem Projekt pro Schlüssel; Schlüssel 11–20 und 21–30 sind für die nächsten beiden Konten reserviert und werden nur aktiviert, wenn ihre Werte vorhanden sind. Der optionale Installer verwendet nur den offiziellen stabilen Paketkanal:

NPM_CONFIG_PREFIX="$HOME/.local" ./scripts/install-gemini-cli
"$HOME/.local/bin/gemini" --version

Der Installer lehnt ein nicht beschreibbares System-NPM-Präfix ab, anstatt Berechtigungen zu eskalieren; setzen Sie wie oben ein explizites benutzereigenes NPM_CONFIG_PREFIX.

Gemini-Aufträge verwenden ein agentenprivates HOME/GEMINI_CLI_HOME, reine stdin-Aufgabeneingabe, begrenztes stream-json-stdout/stderr, Prozessgruppen-Abbruch und rollenspezifische Freigaben (plan für Exploriererinnen, auto_edit für Arbeitsbienen). Die CLI wird explizit in den Headless-Modus mit einem leeren --prompt versetzt; die eigentliche Aufgabe bleibt rein stdin-basiert. Sie verwenden weder yolo, -p - noch Codex-TUI-Marker. Die Zuweisungsantwort ist begrenzt und wird geparst. Prompts, Anmeldeinformationen, Tool-Ereignisse und Rohausgaben bleiben außerhalb persistenter Metadaten; Prozessausgaben bleiben begrenzt.

Produktive Headless-Aufträge akzeptieren bis zu 7200 Sekunden (120 Minuten) pro Aufruf; der Standard bleibt 600 Sekunden.

Für Gemini-Serien, deren Registry-Modell auto ist, pinnt Masterjet die Headless-CLI auf gemini-3.1-flash-lite, den kostengünstigen/High-RPM-Standard für strukturierte Bauplan-Audits. Ein schwereres Modell wird nur verwendet, wenn es explizit für diese Serie konfiguriert ist.

Jeder Gemini-API-Probe- oder Headless-Job nimmt auch eine persistente projektspezifische Anforderungsreservierung vor. Reservierungen erlauben nur eine aktive Anforderung, erzwingen einen Mindestabstand von 60 Sekunden zwischen Prozessen und Neustarts und wenden eine exponentielle Abklingzeit nach einem verifizierten 429 an (beginnend bei 15 Minuten, begrenzt auf 24 Stunden). Der private Zustand wird in fleet/rate-limits.json gespeichert; fehlerhafter Zustand schlägt fehl und wird unter Quarantäne gestellt, anstatt eine weitere Anforderung zu erlauben.

Das GTK-freie fleet_control-View-Modell und der control_center-Controller erzwingen dieselben Grenzen und Generierungsprüfungen wie der Server; die optionale GTK3-Seite wird lazy geladen, sodass Headless-Importe ohne Anzeige bleiben. Der Cinnamon-Adapter verwendet Snapshot-Schema v3, höchstens 26 Serien und 25 sichtbare Zeilen pro Serienseite; begrenzte Zeilen sind nur Statuszeilen. Echte Provider-Anmeldeinformationen, Kontoproben, Ollama-Ressourcenzulassung und Desktop-Sitzungsakzeptanz bleiben explizite lokale Tore. Ollama-Serien bleiben simple_only und lehnen komplexe oder repository-ändernde Aufgaben ab. Ihre konfigurierte separate Zwei-Agenten-Ressourcengrenze und Host-Druck-Tore werden durchgesetzt; die globale Zehn-Bienen-Grenze bleibt eine zusätzliche Obergrenze.

Tools

• agent_start: Starte ausgewählte Agentinnen; all/Serien-Selektoren erfordern allow_broad_selector=true, wenn sie mehr als 6 Agentinnen auflösen

• agent_status: strukturierter Status, Antwortzustand und Limit-Klassifizierung ohne Rohausgabe

• agent_lease_status: datensparsamer Leasing-Zustand für ausgewählte Agentinnen

• Breite Nur-Lese-Selektoren auf agent_status, agent_lease_status, agent_skills, agent_skill_match und agent_capabilities werden mit agents_limit/agents_offset paginiert; die Standardseitengröße beträgt 30 Agentinnen und Antworten enthalten total_count plus truncated-Metadaten.

• agent_claim: beanspruche oder erneuere eine Agentin, standardmäßig mit unendlichen Wiederholungen, wenn sie beschäftigt ist; explizite Ansprüche können gestoppte verwaiste Leases nach einer Gnadenfrist wiederherstellen

• agent_release: gib den Agentin-Anspruch dieses MCP-Clients frei; force nur nach Statusprüfung

• agent_wait: warte auf Aktivitäts-/Stopp-/Limit-Metadaten ohne Rohausgabe, Standard 120 Sekunden und begrenzt auf 10 Minuten pro Aufruf

• fleet_watchdog: fordere einen Bericht von untätigen Agentinnen an, warte ein Gnadenfenster, dann optional unterbrechen, stoppen oder freigeben ohne Rohausgabe

• usage_watchdog: synchronisiere codex-usage-Limitblöcke mit lokalem Agentin-Zustand, stoppe blockierte laufende Agentinnen und lösche den lokalen Blockmarker, sobald der codex-usage-Watchdog sie freigibt

• agent_send: sende Text an eine laufende Agentin

• agent_interrupt: sende Ctrl-C an eine laufende Agentin

• agent_stop: stoppe ausgewählte Agentinnen; all/Serien-Selektoren erfordern allow_broad_selector=true, wenn sie mehr als 6 Agentinnen auflösen

• agent_safe_tail: expliziter begrenzter, ANSI-bereinigter, redigierter Auszug; verweigert aktive Leases, die von anderen Clients gehalten werden, bevor Pane- oder Log-Ausgabe gelesen wird; Log-Quelle liest nur reguläre Roh-Log-Dateien

• agent_skills: datensparsames Skill-Inventar ohne Dateiinhalte

• agent_skill_match: prüfe, ob eine oder alle Agentinnen einen benannten Skill haben

• agent_capabilities: zusammengefasste Modell-, Skill- und Policy-Fähigkeiten mit einer begrenzten Plugin-Seite

• agent_scope_check: verifiziere, dass Schreibpfade innerhalb des Zuweisungsbereichs bleiben

• agent_assign: strukturierte, skill-bewusste Zuweisung mit expliziten Grenzen

• agent_assign_readonly: Abkürzung für Nur-Lese-Exploriererin-Zuweisungen

• agent_assign_live_data: Abkürzung für Nur-Lese-Web-/Live-Daten-Zuweisungen, die aktuelle Quellen oder einen expliziten Tooling-/Zugriffslimit-Bericht erfordern

• agent_assign_write: Abkürzung für Arbeitsbiene-Schreibzuweisungen

• agent_assignments: datensparsames Zuweisungs-Audit-Log

• agent_last_assignment_status: neueste Zuweisungsmetadaten für eine Agentin

• agent_report_request: bitte eine Agentin um einen prägnanten Bericht

• agent_assignment_report: lese einen begrenzten redigierten Auszug für eine bekannte Zuweisung

• agent_selector_policy: zeige oder setze die Ordinal-Selektor-Policy, z. B. a,b oder a,b,c

• agent_selector_preview: Vorschau der numerischen Selektor-Zuordnung ohne Zustandsänderung

• agent_selection_preview: Vorschau echter Fleet-Kandidaten durch den Nur-Lese-Selection-/Admission-Kern; Shadow plant, führt aber nie aus. Erzwungen bleibt geschlossen, bis autoritative Hive-Callbacks und ein operationsspezifischer Executor bereitgestellt werden; ServerAdmissionRuntime bietet die Fail-Closed-Grenze, führt aber keine Operationen aus

Das lokale codex_master.admission-Modul liefert nun diese Reservierungsgrenze als In-Process-, Fail-Closed-Vertrag: unveränderliche Datensätze binden Arbeitsversion, Grant-/Scope-Digests, Leasing-Erwartung und die ausgewählte Ressource; Zustandsänderungen verwenden eine Revisions-CAS, Reservierungs-TTLs sind auf 30–120 Sekunden begrenzt, und public() entfernt Kontoschlüssel, Scope-Pfade und andere private Bindungen. Scope-Überlappung, Agenten-/Konto-/Kontomodell-Kapazitäten und Lese-/Lese- versus Schreib-Überlappung werden atomar geprüft. FileAdmissionStore fügt ein privates Schloss plus atomaren Zustandsersatz für die Wiederherstellung frischer Prozesse hinzu; fehlerhafter, übergroßer oder symbolisch verknüpfter Zustand schlägt fehl. Es führt keine Provider-, Lebenszyklus-, Leasing- oder Netzwerkänderung durch und ist noch nicht in die erzwungene Ausführung eingebunden.

codex_master.selection_service.SelectionService ist die nächste lokale Orchestrierungsschicht. Es delegiert die Vorschau an denselben deterministischen Planer, validiert vor einem injizierten Laufzeitaufruf erneut, wiederholt höchstens dreimal mit 50/100/200 ms Backoff, kompensiert fehlgeschlagene Versuche und gleicht Absturz-Evidenz ab, ohne erneut auszuführen. codex_master.admission_runtime.ServerAdmissionRuntime bietet nun die Fail-Closed-Server-Grenze: Autoritäts-, Repository- und kanonische Scope-Callbacks müssen aus autoritativen Hive-Datensätzen stammen; bestehende Fleet-Konto-, Modell-, Usage-, Leasing-, Prozessidentitäts-, Auth- und Runner-Konfigurationsprüfungen werden in fester Reihenfolge angehängt. Fehlende Hive-Bindungen, veraltete Zulassungen, fehlerhafte Gate-Evidenz oder Callback-Fehler verweigern die Laufzeit, und eine erfolgreiche Revalidierung ist pro Zulassungsrevision nur einmalig. Der Adapter selbst beansprucht, startet, weist nie zu oder ruft keinen Provider auf. Sein privater Cross-Process-Speicher ist am zustandslokalen admission-state.json/Lock-Paar verwurzelt, wenn ein Auto-Ausführungspfad explizit current_admission_store() anfordert; produktive erzwungene Ausführung bleibt geschlossen, bis die autoritativen Hive-Callbacks und ein operationsspezifischer Executor bereitgestellt werden.

Der Applet-Status zeigt begrenzte fleet_snapshot_degraded- und watchdog_snapshot_degraded-Flags, wenn seine Nur-Lese-Quellen nicht verfügbar sind. Ein erschöpftes Usage-v2-Fenster, dessen verifizierter Reset bereits vergangen ist, blockiert das Konto nicht mehr; zukünftige oder unbekannte Resets bleiben Fail-Closed.

Hive-Kontrollebene

Das codex_master.hive-Paket enthält nun die begrenzten Kontrollebenen-Grundlagen: strenge öffentliche Konfiguration, privater Zustand, Prinzipale und Ausführungsbindungen, Repository-/Autoritätsprüfungen, typisierte Nachrichten und Dispatch-Zustandsmaschinen, append-only Entscheidungen, Provenienz-bewusster Speicher, eine DP-Arbeitswarteschlange und eine einzige Zulassungsgrenze. Das codex_master.selection-Paket ist eine Kompatibilitätsgrenze um den bestehenden deterministischen Planer und fügt typisierte Modell-Policy-, Aufgabenklassifizierungs-, Quellen-, Fairness-Zustands- und passive Anker-Verträge hinzu, ohne einen zweiten Selektor einzuführen.

Hive-Status, Validierung, Migration und Selection-Diagnosen werden als Nur-Lese-MCP-Tools bereitgestellt. Fehlende autoritative Work-/Grant-/Repository-/Scope- und Lease-Evidenz bleibt Fail-Closed; kein Hive-Diagnosetool beansprucht, startet, weist zu oder ruft einen Provider auf.

Betriebliche Details sind dokumentiert in docs/account-aware-selection.md, docs/operations/hive-operations.md, docs/operations/selection-operations.md, docs/security/hive-security.md, docs/security/selection-privacy.md und docs/migration/hive-selection-migration.md. Öffentliche, geheimnisfreie Konfigurationsbeispiele finden sich in examples/: Agentenklassen, Hive-Modus und Modell-Policy.

• worktree_create_for_agent: erstelle ein isoliertes Git-Worktree für eine Agentin

• worktree_status: begrenzter Git-Status und Worktree-Metadaten

• integration_status: Repo-Status, Diff-Statistik und aktuelle Zuweisungsmetadaten

• commit_ready_check: feste Bereitschaftsprüfungen für Integration/Commit

• master_app_bridge_status: App-Bridge-Manifest- und Connector-ID-Status

• master_plugin_status: Plugin-Paketierung, Plugin-Cache-Drift, App Bridge und MCP-Registrierungsstatus

• master_namespace_status: diagnostiziere codex-master-mcp-Registrierung, Start, Plugin-Cache-Drift und tools/list-Sichtbarkeit für neue Clients

• master_release_status: diagnostiziere Release-Drift über Paketversion, Plugin-Manifest-Version, lokale Tags und GitHub-Releases

• master_watchdog_status: diagnostiziere systemd-Fleetwatchdog-Gesundheit, installierte Unit-Härtung und aggregierten Sicherheits-Score-Status

• master_timeout_policy: melde effektive Timeout- und Polling-Policy für MCP-Start, Agentin-Anspruchs-Wiederholung, Agentin-Warten, produktive Headless-Zuweisungen, Watchdog-Überwachung und versteckte CLI-Leasing-Identitätsquelle

• master_applet_status: begrenzter Nur-Lese-Snapshot für 1–6 konkrete Agentinnen; vom Cinnamon-Applet verwendet und als applet-status in der CLI verfügbar

• agent_pool_validate: validiere eine maschinenlesbare Agentinnen-Pool-Spezifikation

• agent_pool_install: installiere oder aktualisiere schlafende Agentinnen-Homes aus einer Spezifikation

• agent_pool_status: inspiziere datensparsame Pool-Installationszahlen

• agent_pool_copy_auth: kopiere explizit eine Quell-auth.json zu vielen installierten Agentinnen, standardmäßig Trockenlauf

• agent_pool_destroy_pool: geschütztes Entfernen installierter Agentinnen-Homes

• agent_doctor: strukturierte Diagnosen ohne Rohausgabe

• agent_selection_options: konto- und autoritätsgefiltertes Erstangebot, das nur gültige Klassen-/Lebenszyklus-/Modell-/Begründungskombinationen enthält

• fleet_account_list, fleet_gemini_bootstrap_plan, fleet_series_list, fleet_account_upsert, fleet_account_set_secret, fleet_account_disable, fleet_account_probe, fleet_account_delete, fleet_provider_models, fleet_series_plan, fleet_series_apply, fleet_series_disable und fleet_series_delete: begrenzte Fleet-Konto-/Provider-/Serienverwaltung; Geheimeingabe ist nur stdin und Mutationen verwenden Generierungs-CAS

/mcp sollte codex-master-mcp nur in der Teamleiterin/Haupt-Codex-Instanz anzeigen. Verwaltete Agentinnen erhalten absichtlich keine Masterjet-MCP-Tools; sie werden von außen gesteuert und dürfen native Subagentinnen nur verwenden, wenn eine Zuweisung dies ausdrücklich erlaubt. tool_search ist nicht maßgeblich für den lokalen stdio-MCP-Namespace; verwenden Sie /mcp im betroffenen Codex-Client oder namespace-status aus diesem Repository. plugin-status und namespace-status melden auch, ob die Plugin-Manifest-Version des Repositories im lokalen Plugin-Cache installiert ist, ohne Cache-Pfade zurückzugeben. Bei namespace-status bedeutet ok auf oberster Ebene, dass der MCP-Server, der lokale Plugin-Cache, die aktive Codex-Client-Konfiguration und der aktive CODEX_HOME-Kontext bereit sind. mcp_server_ready, plugin_cache_ready, client_config_ready und active_home_ready bleiben getrennt, um den Serverstart von veraltetem Client-/Plugin-Zustand, einer nicht übereinstimmenden Konfiguration oder einem verwalteten Agentin-Home zu isolieren. running_process_summary.namespace_visibility meldet nur aggregierte Client-Home-Kategorien, damit Geschwister-Codex-Sitzungen erkennen können, wann benutzerdefinierte Homes eine eigene MCP-Konfiguration benötigen oder wann verwaltete Agentin-Homes erwartungsgemäß keine Master-MCP-Tools bereitstellen.

Lokale CLI

Zentraler Klassen-/Lifecycle-/Modellresolver

Vor dem ersten Start oder Assignment einer Serie fragt das anfordernde Modell agent_selection_options fuer eine konkrete Ziel-Agentin ab. Die Antwort enthaelt nur aktuell erlaubte Klassen, Lifecycles, Modelle, Reasoning-Stufen und deren gueltige Kombinationen. Das Angebot ist advisory und reserviert nichts. Seine generation kann bei Folgeaufrufen als known_generation mitgegeben werden; options_changed meldet account- oder katalogbedingte Aenderungen. Beim ersten Angebot fuer eine Teamleiterin muss sichtbar genau ein legales Tupel erscheinen: class=teamleiterin, lifecycle=persistent, model=gpt-5.6-terra, reasoning=xhigh. Fuer die Policy ist xhigh zugleich Minimum und Maximum. Andere Teamleiterin-Tupel duerfen nicht angeboten werden.

agent_start, agent_assign und die Assignment-Shortcuts geben ihre optionalen Felder class, lifecycle, model, reasoning_effort und complexity an denselben Resolver. Danach wird keine zweite Auswahl-Policy angewendet. Oeffentliche Lifecycles sind ephemeral, binding und persistent; invocation bleibt als Eingabealias erlaubt und wird als ephemeral zurueckgegeben.

Kompatible explizite Angaben bleiben erhalten. Klassenprofil, Lifecycle, Modellfaehigkeiten, accountbezogene Verfuegbarkeit sowie Reasoning-Minimum und -Maximum sind harte Grenzen. Fehlt die Klasse, wird eine passende delegierbare Nicht-Leitungsklasse gewaehlt; Leitungsklassen werden nie automatisch hochgestuft. Fehlt der Lifecycle, gilt das Klassenprofil. Defaults fuer Arbeiterinnen:

• einfacher Schreibjob plus ephemeral: gpt-5.3-codex-spark/low

• Read-only oder nicht einfacher Schreibjob plus ephemeral: gpt-5.6-luna/medium

• binding: gpt-5.6-luna/high

• persistent: gpt-5.6-luna/xhigh; xhigh ist hier zugleich Minimum

Ist Spark fuer den Account nicht verfuegbar oder verwirft die Task-Pruefung ihn, faellt der Default auf Luna zurueck. Spark ist nur der Default fuer einen einfachen Schreibjob ohne Modellwunsch. Ein fuer eine Arbeiterin explizit angefordertes unbekanntes oder nicht verfuegbares Modell faellt sicher auf gpt-5.6-luna, nie auf Spark; ein kompatibles explizites Effort bleibt erhalten oder wird an Ersatzmodell sowie Klassen-/Lifecyclegrenzen geklemmt. Klassenfremde oder zu schwache Angaben werden ebenfalls innerhalb der harten Grenzen ersetzt; Gottbiene und Koenigin bleiben Sol-gebunden. selection.fallback, angeforderter und effektiver Wert sowie stabile reason_codes liefern die klare Fehl-/Fallbackmeldung. Das anfordernde Modell kann danach abbrechen oder mit einer anderen angebotenen Kombination neu anfragen. Gueltige Aufstiege Spark -> Luna -> Terra -> Sol bleiben innerhalb der Klassen- und Effortgrenzen moeglich. ultra ist nie erlaubt.

Teamleiterin ist fest persistent und nutzt exakt gpt-5.6-terra mit xhigh; xhigh ist fuer sie zugleich Minimum und Maximum. Ein erforderliches Modell oder Effort, das nicht verfuegbar ist, ist ein harter Fehler ohne Fallback. required_model_unavailable:gpt-5.6-terra beziehungsweise required_model_effort_unavailable:gpt-5.6-terra:xhigh. Das gilt insbesondere fuer die Teamleiterin: Start und Assignment teilen den zentralen Resolver und duerfen niemals auf Sol, Luna, Spark oder ein anderes Effort ausweichen.

Leitungsklassen sind fest persistent und stellen sich beim ersten echten Userkontakt mit Namen vor: Gottbiene nutzt gpt-5.6-sol/max, Koenigin nutzt gpt-5.6-sol/xhigh, und Teamleiterin nutzt exakt gpt-5.6-terra/xhigh. Fuer Koenigin, Teamleiterin und alle Arbeiterklassen ist xhigh absolute Obergrenze; nur die Gottbiene darf max nutzen.

Der kanonische Betriebsablauf steht in Selection Operations. Die versionierten Kataloge codex-agent-classes.json und codex-model-policy.json bleiben autoritativ; README und Skill definieren keine zweite Auswahl-Policy.

Ressourcenbewusste Spawn-Angebote

agent_spawn_offers ist ein read-only MCP-Hinweis fuer eine moegliche lokale Kapazitaet. Beispiel fuer einen MCP-tools/call:

{"name":"agent_spawn_offers","arguments":{"required_slots":1}}

Gleiches CLI-Kommando aus diesem Worktree:

PYTHONPATH=src python -m codex_master.server spawn-offers --required-slots 1
./bin/codex-master-mcp spawn-offers --required-slots 1

PYTHONPATH=src ist fuer Python-Aufrufe dieses Worktrees erforderlich: eine lokale editable Installation kann auf einen anderen Quellstand zeigen.

Ein Offer ist advisory, gilt 5 Sekunden und reserviert nichts (reservation: "none"). start prueft freie Gesamtslots vor einem neuen tmux-Start unter dem Admission-Lock erneut. Ohne belastbare Gesamtzahl bleiben Offers leer; die data-sparse Antwort enthaelt nur Reason-Codes, keine /proc-Inhalte, tmux-Ausgabe, lokalen Pfade oder Environment-Texte. Sie ist retryable mit 15 Sekunden Wartehinweis.

Temporäre Grenzen fuer einen neuen Start:

• Ressourcendruck-Grenzen bleiben mit ihren bisherigen Werten konfiguriert und aktiv: CPU, Load, I/O-Wait und RAM können Spawn fail-closed blockieren.

• die konfigurierte Ollama-Zweiergrenze bleibt erhalten und wird vor der globalen Zehnergrenze durchgesetzt

• hoechstens 10 Bienen insgesamt; laufende Masterjet-Sessions sowie aktive und unbestaetigte native Subagentinnen zaehlen zusammen

• ab 10 Bienen wird jede weitere Biene hart abgewiesen

• required_slots liegt zwischen 1 und 10

Verweigerte Admission-Antworten enthalten neben stabilen reason_codes eine strukturierte errors-Tabelle. Jeder Eintrag liefert code, title, explanation, rule und action; Rohmetriken oder lokale Zustandsdaten werden nicht aufgenommen.

CODEX_MASTER_SPAWN_PRIORITY ist einzige Spawn-Environment-Konfiguration. Sie ist eine kommagetrennte Prioritaetsliste (Default mcp_host), wird nur als Daten gelesen, dedupliziert und niemals als Shell-Befehl oder Netzwerkziel ausgefuehrt. Ihr Text wird nicht in Antworten gespiegelt. Aktuell kann nur der exakte lokale Route-Wert mcp_host ein Offer erzeugen. developer_vm und sandbox sind nicht angeboten, selbst wenn sie in dieser Liste stehen; es gibt keine Remote-Ausfuehrung in dieser Version.

Ein Offer erzeugt keine Lease, keine Meta-Datei und keinen Assignment-Audit- Eintrag. Auth-, Scope-, Routing-, Modell-, Nutzungs- und bestehende Admission- Gates bleiben beim eigentlichen Start beziehungsweise bei Assignments wirksam. Ein sauberer tmux-Zustand ohne Server oder Sessions zaehlt als null laufende Agentinnen. Messfehler, /proc-Fehler und alle anderen tmux-Fehler fail-closed; ihre oeffentlichen Fehler bleiben begrenzt und redigiert.

Native Subagentinnen melden Starts und Stops an den Masterjet. Aktive und unbestaetigte Eintraege zaehlen deshalb in jede folgende Slotentscheidung ein. Die Assignment-Prompt-Policy verlangt den frischen Gesamtcheck vor jedem weiteren Spawn. Ein Modell, das diesen MCP-Pfad umgeht, kann der Masterjet ohne Codex-eigenen Pre-Spawn-Hook weiterhin nicht technisch intercepten. developer_vm darf erst offerable werden, wenn alle folgenden Voraussetzungen erfuellt sind:

• real reachability/health probe against the actual VM

• authenticated transport and host-key verification/pinning

• distributed leases/reservations across hosts

• bounded remote execution (timeouts and bounded output)

• end-to-end integration testing against the real target

Bis dahin bleibt ein VM-Backend vollstaendig weggelassen.

cd /home/teladi/codex-master
python3 -m codex_master.server install          # create ~/.local/bin/codex-master-mcp + codex mcp add
python3 -m codex_master.server doctor          # smoke check (codex, tmux, state path, JSON result)
python3 -m codex_master.server uninstall       # remove mcp registration and local symlink
python3 scripts/codex-master-cinnamon-applet install --dry-run
python3 scripts/codex-master-cinnamon-applet install --no-reload
python3 scripts/codex-master-cinnamon-applet verify

python3 -m codex_master.server start both --cwd /home/teladi/codex-master
python3 -m codex_master.server status
python3 -m codex_master.server selector-policy
python3 -m codex_master.server selector-policy --series a,b,c
python3 -m codex_master.server selector-preview --limit 6
python3 -m codex_master.server selection-preview --series d --task-kind simple --admission-mode shadow --sp1a --limit 8
python3 -m codex_master.server lease-status all --agents-limit 30
python3 -m codex_master.server claim b --forever --poll-interval-seconds 30
python3 -m codex_master.server claim b --no-wait
python3 -m codex_master.server claim b --no-recover-stopped
python3 -m codex_master.server wait a --timeout-seconds 120 --poll-interval-seconds 30
python3 -m codex_master.server watchdog active --idle-seconds 60 --poll-interval-seconds 15 --report-grace-seconds 15 --action stop --manage-unclaimed --quiet
python3 -m codex_master.server capabilities all --agents-limit 30
python3 -m codex_master.server skills all --agents-limit 30
python3 -m codex_master.server skills a --include-names --limit 20 --names-offset 20 --plugins-offset 20 --plugins-limit 20
python3 -m codex_master.server skill-match all codex-security:security-scan --agents-limit 30
python3 -m codex_master.server scope-check --scope src/codex_master --write-path src/codex_master/server.py
python3 -m codex_master.server assign-readonly a --skill codex-security:security-scan --scope src/codex_master/server.py --task "Pruefe nur lesend und berichte knapp."
python3 -m codex_master.server assign-live-data a --task "Wie ist das Wetter gerade in Berlin?" --live-data-topic "Wetter Berlin heute"
python3 -m codex_master.server assign-write b --scope .github/workflows --write-path .github/workflows/ci.yml --task "Haerte nur die CI-Datei."
python3 -m codex_master.server assignments all --limit 20
python3 -m codex_master.server last-assignment a
python3 -m codex_master.server assignment-report a ASSIGNMENT_ID --source pane --lines 40 --chars 4000
python3 -m codex_master.server integration-status
python3 -m codex_master.server commit-ready-check
python3 -m codex_master.server app-bridge-status
python3 -m codex_master.server plugin-status
python3 -m codex_master.server namespace-status
python3 -m codex_master.server release-status
python3 -m codex_master.server watchdog-status
python3 -m codex_master.server timeout-policy
python3 -m codex_master.server fleet-recovery-status
python3 -m codex_master.server fleet-recovery-retry
python3 -m codex_master.server pool validate --spec codex-agent-pool.json
python3 -m codex_master.server pool install --spec codex-agent-pool.json --target-dir "$HOME/.codex-agents" --codex-bin /usr/local/bin/codex
python3 -m codex_master.server pool status --spec codex-agent-pool.json
python3 -m codex_master.server pool copy_auth --spec codex-agent-pool.json --from-agent a1 --to a-series
python3 -m codex_master.server pool destroy_pool --spec codex-agent-pool.json --yes
python3 -m codex_master.server send a "Kurzer Auftrag"
python3 -m codex_master.server release b
python3 -m codex_master.server tail a --source pane --lines 20 --chars 2000
python3 -m codex_master.server stop both

Agentinnen-Pool-Spezifikation

Das Repository enthält eine generische, maschinenlesbare codex-agent-pool.json sowie schemas/codex-agent-pool.schema.json. Der aktuell installierte native Pool verwendet fünf A-Homes, drei B-Homes und drei C-Homes. a1 und b1 bleiben die authentifizierten Quell-Homes; b92 ist ein separat erhaltenes aktives Home und wird im zusammengeführten Fleet-Inventar angezeigt. Gemini-Serien werden über die Fleet-Registry verwaltet und sind nicht Teil dieser nativen Pool-Spezifikation. Pool-Spezifikations-Lesevorgänge akzeptieren nur reguläre UTF-8-JSON-Dateien, lehnen symbolisch verlinkte oder überdimensionierte Spezifikationsdateien ab und halten Spezifikationspfade aus öffentlichen Fehlerantworten heraus. Die Pool-Validierung gibt nur Zählungen und Zustandsmarkierungen für Serien, Aliase und authentifizierte Agentinnen zurück; konkrete Namen werden nicht wiedergegeben. Die Pool-Installation behält auch generierte codex-Wrapper und config.toml-Dateien als reguläre Dateien pro Agentin, ersetzt symbolisch verlinkte Einträge, ohne deren Ziele zu berühren, validiert Laufzeitverzeichnisse als echte Verzeichnisse und schreibt einen regulären Marker für den installierten Pool. Der Pool-Status meldet ok nur, wenn der Marker, alle erwarteten Homes, Wrapper, Konfigurationen und erforderlichen Shared-Asset-Links vorhanden und gültig sind. Shared-Asset-Diagnosen sind nur Zählungen; lokale Link-Ziele und Pool-Pfade werden nicht zurückgegeben. Der Pool-Status gibt auch Serienzählungen zurück, ohne konkrete Seriennamen zu nennen.

Die Spezifikation ist nur die Karte. Das eigentliche Authentifizierungsmaterial ist weiterhin das auth.json pro Home, zum Beispiel ~/.codex-agents/a1/auth.json. Eine normale Installation kopiert niemals Authentifizierungsmaterial.

Zwei Installationspfade werden unterstützt:

./bin/codex-master-mcp pool install --spec codex-agent-pool.json --target-dir "$HOME/.codex-agents"
./scripts/install-agent-pool --spec codex-agent-pool.json --target-dir "$HOME/.codex-agents"

Verwenden Sie --codex-bin, wenn die Codex-CLI-Binärdatei nicht /usr/local/bin/codex ist. Eine normale Installation kopiert niemals Authentifizierungsmaterial. Für die Massen-Authentifizierungsweitergabe führen Sie zuerst pool copy_auth ohne --yes aus, um die Zählungen zu prüfen, und wiederholen Sie dann mit --yes, wenn dies beabsichtigt ist. copy_auth kopiert nur auth.json, überspringt die Quell-Agentin, wenn sie Teil des Zielselektors ist, erfordert, dass das Quell-Agentin-Home ein echtes Verzeichnis ist, und gibt niemals Authentifizierungsinhalte, die Quell-Agentin-ID oder den angeforderten Zielselektor zurück.

Verwende keine symbolischen Links oder Hardlinks für auth.json im normalen Pool-Modell. Auth-Dateien sind klein; Kopien halten jede Agentin isoliert. Symlinks überschreiten die No-Follow-Vertrauensgrenze, und Hardlinks teilen einen Inode über mehrere Agentinnen.

Siehe docs/agent-pool.md für den vollständigen Befehlssatz und docs/auth-copy.md für das Auth-Copy-Sicherheitsmodell.

Der Cinnamon-Installer kopiert das Applet in das benutzerspezifische Xlet-Verzeichnis mit einem atomaren Austausch, einem validierten Rollback-Baum, einer privaten Operationssperre und begrenzter Quell-/Zielverifikation. install --dry-run führt keine Dateisystem- oder D-Bus-Mutation durch; --no-reload ist nützlich für CI- und temporäre Home-Smoke- Tests. verify prüft zusätzlich das laufende Cinnamon-Xlet, wenn eine Desktop-Sitzung verfügbar ist.

Cinnamon-Applet: Flottenmanagement

codex-master@H234598 ist das schreibgeschützte Status-Applet P3/P3a. Sein sichtbarer Panel- Titel ist immer Flottenmanagement. Es fordert explizit das Applet-Status- Schema v4 an; die Schemata v1 bis v3 bleiben für ältere Aufrufer unverändert.

Jede Schema-v4-Aktualisierung verwendet eine begrenzte tmux-Sitzungsinventur. Jede bekannte laufende codex-master-Agentin wird automatisch erkannt und angezeigt, bis zum festen Sechs-Zeilen-Limit. Fremde tmux-Sitzungen werden ignoriert. tracked-agents definiert nicht mehr die sichtbare Flotte: Es pinnt nur schlafende Agentinnen in Zeilen, die von aktiven Agentinnen freigelassen werden. Sein Standardwert a1,b1 begrenzt daher die automatische Erkennung nicht. Mehr als sechs aktive verwaltete Agentinnen erzeugen einen begrenzten Überlaufmarker anstelle eines unbegrenzten Menüs.

Native Codex-Subagentinnen werden nicht mit verwalteten tmux-Agentinnen gemischt. Offizielle SessionStart-, SubagentStart-, SubagentStop- und SessionEnd-Hooks pflegen ein privates begrenztes Register. Das Applet rendert dieses Register nur im separaten Untermenü Native Bienen (N) mit sechs festen, nicht reaktiven Kindzeilen. Native Zeilen sind nur Status und enthalten kein Aktions- oder Kontext-Token.

Das Applet startet höchstens einen begrenzten codex-master-mcp applet-status-Kindprozess und liest nie den Ressourcen-Snapshot oder startet einen Ressourcen-Monitor. Schema v4 fügt nur den begrenzten Ressourcen-Gate-Zustand, Engpass, Trend, Konfidenz, Profilhinweise und Snapshot-Generation hinzu. Ungültige oder regressive Ressourcen-Generationen werden als nicht verfügbar dargestellt. Das Applet ruft nie eine Shell auf.

Das Statusmodell trennt drei Belange:

• activity_state: running, sleeping, mixed oder unknown;

• backend_state: ok, degraded oder unavailable;

• control_state: ready, blocked, mixed oder unknown.

Eine schlafende Agentin ist normal und verschlechtert nicht von selbst die Backend-Gesundheit. Fehlgeschlagene Aktualisierungen behalten den letzten gültigen Snapshot und markieren ihn als veraltet. Antworten enthalten nur feste Zustandsfelder und Zähler; Eingabeaufforderungen, Protokolle, Prozess-IDs, Pfade, Lease-Besitzer, Lease-IDs und Rohausgabe werden nicht zurückgegeben.

resource-status --format compact|json|markdown ist eine lokale Operator-CLI, nicht ein MCP-Tool. Es rendert nur die validierte ResourceOperatorStatus-Projektion; Sensor-Labels, cgroup-Scope-IDs, Pfade, PIDs, Rohverlauf, stdout, stderr, Anmeldeinformationen und absolute Beweise für verfügbaren Speicher werden nie zurückgegeben.

Die vier Applet-Einstellungen sind:

• tracked-agents: kommagetrennt a1 bis c100; 1–6 konkrete IDs zum Anpinnen als schlafende Zeilen, wenn die automatische aktive Erkennung Kapazität lässt, case-normalisiert und dedupliziert; Standard a1,b1;

• refresh-on-open: Aktualisierung beim Öffnen des Menüs; Standard an;

• background-refresh: optionale periodische Aktualisierung; Standard aus;

• refresh-interval-seconds: 15–3600 Sekunden; Standard 60.

Fehlerhafte Agent-, Schalter- oder Intervallwerte zeigen einen Konfigurationsfehler, fallen auf sichere Standardwerte zurück, deaktivieren Hintergrundarbeit und erreichen nie die Prozess-argv. Endliche Aktualisierungsintervalle außerhalb des zulässigen Bereichs werden auf 15–3600 Sekunden begrenzt. Das Menü enthält eine manuelle Aktualisierung, Applet-Verwaltung, eine Zusammenfassung, höchstens sechs verwaltete Zeilen und das separat begrenzte Native-Bienen- Untermenü.

Nur die Koenigin darf Masterjet neu starten oder neu laden, es installieren oder den Plugin-Cache synchronisieren. Andere Rollen dürfen den Zustand prüfen und verifizieren und diese Aktionen der Koenigin empfehlen, dürfen sie aber nicht ausführen.

Installiere MCP/Plugin und Applet mit den repository-eigenen Installern:

./bin/codex-master-mcp install
./scripts/codex-master-cinnamon-applet install --dry-run
./scripts/codex-master-cinnamon-applet install
./scripts/codex-master-cinnamon-applet verify

Die vollständige CLI-Referenz ist die Repository-Manpage codex-master-mcp(1). Erzeuge deterministische komprimierte Ausgabe ohne Installation oder rendere die Quelle direkt:

./scripts/codex-master-manpage build --output-dir /tmp/codex-master-man
groff -man -Tutf8 man/man1/codex-master-mcp.1

codex-master-mcp install synchronisiert das Plugin, einschließlich der regulären hooks/hooks.json-, hooks/native_spawn_admission.py- und hooks/native_bee_event.py-Dateien, in den persönlichen Plugin-Cache. Es verändert den Codex-Hook-Trust-Zustand nicht und darf ihn nicht verändern. In der aktuellen übergeordneten Codex-Sitzung öffne /hooks, inspiziere die fünf codex-master-Definitionen und vertraue ihnen explizit: einen blockierenden PreToolUse-Admissions-Hook plus vier Lebenszyklus-Hooks. Starte dann eine völlig neue übergeordnete Codex-Sitzung im Repository. MCP- Wiederverbindung, Status oder Agent-Start ersetzt diese neue Sitzung nicht. Bis dieser manuelle Schritt erfolgreich ist, behaupte nicht, dass native Spawn-Admission oder Native-Bienen-Lebenszyklus-Abdeckung aktiv ist.

Rolle den aktiven Applet-Baum zurück mit:

./scripts/codex-master-cinnamon-applet rollback

install stagt und hasht reguläre, nicht-hardlinkte Quelldateien, lehnt symlinkte Quell-/Zielpfade ab, lädt nur diese UUID über Cinnamons ReloadXlet neu und stellt den vorherigen Baum wieder her und lädt ihn neu, wenn die Bereitstellung fehlschlägt. verify erfordert byte-identische installierte Dateien und eine laufende UUID von GetRunningXletUUIDs applet. rollback erfordert validierte installierte und Rollback- Bäume, aber kein intaktes Repository-Quellverzeichnis. Es schlägt geschlossen fehl, wenn ein erforderlicher Baum fehlt oder unerwartet ist. Install, Verify und Rollback werden durch eine private Per-UUID-Sperre serialisiert. --no-reload ist für kontrollierte Offline-Install-/Rollback-Tests verfügbar. Kein Befehl verwendet Eval oder startet Cinnamon global neu.

Nützliche Diagnosen:

./bin/codex-master-mcp resource-status --format compact
./bin/codex-master-mcp resource-status --format json
./bin/codex-master-mcp resource-status --format markdown
./bin/codex-master-mcp applet-status --schema-version 4
gdbus call --session --dest org.Cinnamon --object-path /org/Cinnamon \
  --method org.Cinnamon.GetRunningXletUUIDs applet
journalctl --user -b | grep -F codex-master@H234598

Ein unavailable- oder veralteter Applet-Zustand bedeutet, dass die begrenzte schreibgeschützte Aktualisierung fehlgeschlagen ist. Überprüfe zuerst die installierten Dateien und die CLI; interpretiere gewöhnliche sleeping-Aktivität nicht als Backend-Fehler.

Install-Vertrag (CLI)

install

• erstellt ~/.local/bin/codex-master-mcp als Symlink zu bin/codex-master-mcp

• verifiziert, dass der Repo-Wrapper eine MCP-initialize-Sonde beantworten kann, bevor er bei Codex registriert wird

• verifiziert, dass der installierte Befehlspfad dieselbe Sonde vor der Registrierung beantwortet

• registriert den Befehl über codex mcp add codex-master-mcp -- <link>

• stellt sicher, dass die aktive Codex-MCP-Konfiguration startup_timeout_sec = 120 hat

• synchronisiert den persönlichen codex-master-Plugin-Cache aus einer Laufzeit-Allowlist (.codex-plugin, .app.json, .mcp.json, bin, docs, examples, schemas, scripts, skills, src, systemd, README, codex-agent-pool.json und Paketmetadaten) unter Ausschluss von .git, Tests, Bytecode, Test-Caches, versteckten Dateien, Editor-Swap-Dateien und Backup/Patch- Resten

• lehnt hardlinkte Plugin-Quelldateien ab und behält nur die aktuelle plus die neueste gültige gecachte Plugin-Version, ohne ungültige oder symlinkte Cache-Einträge zu bereinigen

• kopiert reguläre Plugin-Cache-Quelldateien über No-Follow-Dateideskriptoren und verifiziert die Quellidentität nach dem Öffnen, sodass ein Quellentausch den Cache-Inhalt nicht umleiten kann

• erstellt Nonce-suffigierte Plugin-Cache-Temp-Verzeichnisse und entfernt nie ein bereits vorhandenes Temp-Verzeichnis, das diese Synchronisierung nicht erstellt hat

• weigert sich, den Master-MCP aus einem verwalteten Agentinnen-CODEX_HOME zu registrieren

• verlangt, dass die übergeordnete Kette des Installationspfads echte Verzeichnisse sind, keine Symlinks

• erstellt oder ersetzt den Installations-Symlink über einen atomaren temporären Symlink im selben Verzeichnis und eine Verzeichnis-fd-gebundene Umbenennung

• behandelt defekte, schleifende oder unlesbare Installations-Symlinks als nicht übereinstimmend, anstatt beim Auflösen abzustürzen

• gibt JSON ohne Agent-Ausgabe, Installationspfad, Repo-Wrapper-Zielpfad oder Plugin-Cache-Pfade zurück

• akzeptiert --no-plugin-cache nur für explizite Diagnose-Installationen, die den persönlichen Plugin-Cache unberührt lassen sollen

uninstall

• deregistriert von codex mcp remove codex-master-mcp

• entfernt ~/.local/bin/codex-master-mcp

• verlangt, dass die übergeordnete Kette des Installationspfads echte Verzeichnisse sind, wenn entfernt wird

• entfernt den Installations-Symlink über den verifizierten übergeordneten Verzeichnis-fd, sodass ein übergeordneter Austausch nach der Validierung das Unlink nicht umleiten kann

• lässt defekte, schleifende oder unlesbare Installations-Symlinks an Ort und Stelle, es sei denn, sie lösen sich zum Repo-Wrapper auf

• gibt JSON und kein rohes geheimes Material zurück

doctor

• prüft die Verfügbarkeit erforderlicher Werkzeuge (codex, tmux) und des MCP-Zustandsverzeichnisses

• meldet ein strukturiertes checks-Objekt

• verifiziert den installierten MCP-Befehl mit einer datensparsamen initialize-Sonde

• meldet, ob die aktive Codex-MCP-Registrierung startup_timeout_sec >= 120 hat

• meldet, ob das aktive CODEX_HOME wie das Haupt-Standard-Home, ein verwaltetes Agentinnen-Home oder ein benutzerdefiniertes Home aussieht, ohne den Pfad zurückzugeben

• verbirgt lokale Wrapper-, Installations-, Agentin-Home- und Agentin-Runner-Pfade hinter Zustands-/Kategoriefeldern, während Existenz- und Gesundheitsprüfungen erhalten bleiben

• meldet Aufbewahrungszahlen und -größen von Rohprotokollen, ohne verwaltete Rohprotokoll- Verzeichnispfade zurückzugeben

• warnt, ohne Dateipfade zurückzugeben, wenn der installierte MCP auf dieses Repo zeigt, während der Worktree verfolgte oder unverfolgte Änderungen hat

• meldet defekte, schleifende oder unlesbare Installations-Symlinks als fehlgeschlagene installed_symlink-Prüfung mit einem unlesbaren Zielmarker

• behandelt gestoppte Agentinnen als informativen Sitzungszustand, nicht als fehlgeschlagene Gesundheitsprüfung

• schwärzt bekannte Geheimnisformen in der Ausgabe

watchdog

• klassifiziert den Leerlaufzustand aus strukturierten status-Metadaten und Rohprotokoll-Metadaten nur; es ruft nicht tail auf und gibt keine Agentin-Ausgabe zurück

• standardmäßig idle_seconds=60, poll_interval_seconds=15, report_grace_seconds=15 und action=interrupt

• fragt die Agentin immer nach einem prägnanten Bericht vor interrupt, stop oder release

• speichert nur einen Metadatenmarker mit Anforderungszeit, Zuordnungs-ID, geplanter Aktion und Rohprotokoll-Zählern; kein Eingabeaufforderungstext, keine Antworten oder Rohprotokolle werden im Marker gespeichert

• überspringt aktive Leases, die von anderen Clients gehalten werden; --manage-unclaimed darf nur nicht beanspruchte oder abgelaufene Leases zusätzlich zum eigenen Lease dieses Servers überwachen

• unterstützt --quiet für systemd-Ausführungen; erfolgreiche Watchdog-Durchläufe erzeugen keine JSON-Ausgabe, während Fehler weiterhin den normalen CLI-Fehlerpfad verwenden

• wird als optionale systemd --user-Top-Schicht installiert über systemd/user/codex-master-watchdog.service und systemd/user/codex-master-watchdog.timer

• der Benutzerdienst läuft mit konservativen Härtungsrichtlinien: leere CapabilityBoundingSet, privater Keyring/tmp/Geräte, ein schreibgeschütztes Bind des tmux-Socket-Verzeichnisses des Benutzers, Kernel- und Uhrschutz, schreibgeschützte Systemhierarchie, expliziter Schreibzugriff nur auf die verwalteten Zustands- und Benutzer- Laufzeitverzeichnisse, keine IP-Sockets, keine Namespaces, NoNewPrivileges, MemoryDenyWriteExecute, native Syscall-Architektur, und UMask=0077; es behält absichtlich normalen Lesezugriff auf das Benutzer-Home, weil der Watchdog Codex-Konfiguration, tmux-IPC und verwaltete Zustandsdateien benötigt

• codex-usage speichert seine aktuellen Snapshots standardmäßig unter ~/.local/share/codex-usage/current/<account>.json; der Leser akzeptiert das ältere snapshots/-Layout nur, wenn die aktuelle Datei fehlt, und schlägt geschlossen fehl, wenn eine vorhandene aktuelle Datei fehlerhaft ist. usage_watchdog normalisiert aktuelle 5-Stunden-/Wochenfenster in geheimnisfreie Usage-v2-Daten, schreibt den lokalen codex-usage-Blockmarker und verweigert neue agent_start-/Claim-Flows, während ein zukünftiges Reset-Fenster aktiv bleibt; vergangene verifizierte Resets löschen den Block, und unbekannte Resets bleiben fail-closed

watchdog-status

• berichtet, ob der systemd-Timer aktiv ist und ob der letzte Dienstlauf erfolgreich war, ohne die rohe systemctl-Ausgabe zurückzugeben

• prüft, ob der installierte Watchdog-Dienst und der Timer mit den Repo-Kopien übereinstimmen und ob der Dienst weiterhin die erforderlichen Härtungsdirektiven und Watchdog-Flags enthält

• parst nur den aggregierten systemd-analyze security-Expositionswert und die Stufe; rohe Analyzer-Ausgabe und lokale Unit-Pfade werden nicht zurückgegeben

goddess report run verarbeitet alle berechtigten UTC-Berichts-Buckets in chronologischer Reihenfolge, füllt bis zu 24 Stunden nach und wiederholt Buckets, die nicht finalisiert wurden. Für den stündlichen Betrieb aktivieren Sie den gehärteten optionalen Benutzer-Timer:

systemctl --user daemon-reload
systemctl --user enable --now codex-master-goddess-report.timer

timeout-policy

• berichtet, dass agent_claim standardmäßig für beschäftigte fremde Bienen endlos wiederholt, während endliche Claim-Wartezeiten weiterhin ohne 600-Sekunden-Obergrenze akzeptiert werden

• berichtet, dass das Claim-Polling standardmäßig 30 Sekunden beträgt und auf 900 Sekunden begrenzt ist

• berichtet Standardwerte für die Wiederherstellung gestoppter fremder Leases bei expliziten Claims: nur gestoppte Agentinnen, kein verwalteter Home-Prozess und ausreichende Leerlauf-Hinweise

• hält agent_wait als begrenzte Aktivitätswartezeit getrennt: Standard 120 Sekunden, Maximum 600 Sekunden

• berichtet produktive Headless-Zuweisungen mit einem Standard von 600 Sekunden und einem Maximum von 7200 Sekunden (120 Minuten)

• berichtet das TUI-Eingabebereitschafts-Gate für send/assign-*/report-request: Standard 15 Sekunden, 0,5 Sekunden Polling, sichtbare Eingabeaufforderung erforderlich, Fail-Closed ohne Einfügen über wiederholbaren agent_input_not_ready

• berichtet, ob die aktuelle CLI/MCP-Owner-Identität über Aufrufe hinweg stabil ist, ohne die Identität selbst zurückzugeben

skills

• scannt jedes Agentin-Home nach SKILL.md-Dateien in skills/, plugins/cache/ und .tmp/plugins/

• ignoriert symbolisch verknüpfte Skill-Roots und symbolisch verknüpfte SKILL.md-Dateien, anstatt ihnen zu folgen

• gibt Zählungen, Roots, System-Skill-Namen und begrenzte Plugin/Name-Seiten zurück

• berichtet plugin_count, plugins_offset, plugins_limit und plugins_truncated, anstatt jeden Plugin-Namen auszugeben, wenn viele installiert sind

• unterstützt bewusste Aufzählung über plugins_offset/plugins_limit und, mit include_names, names_offset/limit

• gibt keine Skill-Dateiinhalte und keine Agentin-Terminalausgabe zurück

capabilities

• gibt die Modellrichtlinie, die Gesamtzahl der Skills, die System-Skill-Namen und eine begrenzte erste Plugin-Seite zurück

• berichtet plugin_count, plugin_page_count, plugins_limit und plugins_truncated, anstatt jeden Plugin-Namen auszugeben, wenn viele installiert sind

App Bridge

Das Plugin enthält .app.json und deklariert es über .codex-plugin/plugin.json:

{
  "apps": {
    "codex-master": {
      "id": "connector_26697a678b7ec999dc005131eb5c087c"
    }
  }
}

Dies ist die lokale App-Bridge-Identität für das codex-master-Plugin. Es behält die bestehende datensparsame MCP-Tool-Oberfläche bei und ermöglicht Codex, das Plugin mit einer stabilen Connector-ID zu verknüpfen. Die ID ist bewusst kein Geheimnis.

Für einen ChatGPT-Developer-Mode-Connector muss ChatGPT den Connector weiterhin gegen einen erreichbaren öffentlichen HTTPS-/mcp-Endpunkt erstellen oder aktualisieren. Der aktuelle Masterjet-MCP läuft als lokaler stdio-MCP für Codex, daher organisiert .app.json die Plugin-seitige Bridge-Identität; es veröffentlicht das Repo nicht in einem Marketplace und verwandelt den lokalen stdio-Befehl nicht von selbst in einen gehosteten HTTP-Connector.

Prüfen Sie den Bridge-Zustand ohne lokale Pfade:

python3 -m codex_master.server app-bridge-status

Steuerungs-Skills

Skills werden nicht als separate MCP-Funktionen aufgerufen. Sie sind Anweisungsbündel, die eine Codex-Agentin verwendet, wenn die Aufgabe den Skill benennt oder klar zu seiner Domäne passt.

python3 -m codex_master.server skills all --agents-limit 30
python3 -m codex_master.server send a "Nutze codex-security:security-scan. Pruefe src/codex_master/server.py nur lesend und berichte knapp."
python3 -m codex_master.server send b "Nutze github:gh-fix-ci. Pruefe die CI-Konfiguration nur lesend und berichte knapp."
python3 -m codex_master.server tail a --source pane --lines 20 --chars 2000

Für sicherere Delegation bevorzugen Sie assign-readonly, assign-live-data und assign-write gegenüber freiformigem send:

python3 -m codex_master.server assign-readonly a \
  --skill codex-security:security-scan \
  --scope src/codex_master/server.py \
  --task "Pruefe nur lesend und berichte knapp."

python3 -m codex_master.server assign-live-data a \
  --task "Wie ist das Wetter gerade in Berlin?" \
  --live-data-topic "Wetter Berlin heute"

python3 -m codex_master.server assign-write b \
  --skill github:gh-fix-ci \
  --scope .github/workflows \
  --write-path .github/workflows/ci.yml \
  --task "Haerte nur die CI-Datei und berichte Root Cause, Aenderung, Tests, Risiken."

assign validiert benannte Skills anhand des Inventars, verweigert Schreibpfade für Exploriererinnen und erfordert explizite Schreibpfade für Arbeitsbienen. Es sendet den generierten Prompt über tmux, gibt aber weder den Prompt noch die Agentin-Antwort zurück.

Verwenden Sie assign-live-data für Wetter, Nachrichten, Preise, Zeitpläne oder jede andere Aufgabe mit aktuellen Daten. Es ist schreibgeschützt, verwendet dieselben Auth- und Lease-Schutzmechanismen wie andere Zuweisungen und fügt eine explizite Anforderung ein, aktuelle Suchquellen zu verwenden oder eine Tooling-/Zugriffsbeschränkung zu melden, anstatt zu raten. Das konkrete Live-Daten-Thema wird nur an den Agentin-Prompt gesendet; öffentliche Antworten und Zuweisungs-Audit-Datensätze halten das Thema und den Antwortinhalt aus den zurückgegebenen Daten heraus.

assign-write schützt Schreibpfade ebenfalls durch agent_scope_check; ein Schreibpfad außerhalb des deklarierten Bereichs wird abgelehnt, bevor etwas an eine Agentin gesendet wird. Die Worktree-Erstellung verweigert vorhandene Ziele, einschließlich defekter symbolischer Links, und erfordert, dass jedes übergeordnete Verzeichnis im Zielpfad ein echtes Verzeichnis ist. Worktree-Erstellung und -Status sind repo-bezogen: relative Ausbrüche und absolute Ziele außerhalb des Repos werden abgelehnt, bevor git ausgeführt wird, und Erstellungsantworten geben höchstens einen repo-relativen Pfad zurück, niemals einen absoluten lokalen Pfad. Der Worktree-Status verweigert auch symbolische Links und Nicht-Verzeichnis-Ziele, bevor git status ausgeführt wird. Zuweisungs- und Send-Eingaben werden vor der tmux-Interaktion begrenzt: freie Sends und Start-Prompts sind auf 12.000 Zeichen begrenzt, Zuweisungsaufgaben auf 4.000 Zeichen, Namen auf 80 Zeichen, Skill-Referenzen auf 300 Zeichen, pfadartige Felder auf 1.000 Zeichen und Zuweisungslisten auf 50 Einträge. MCP-Boolesche und -Integer-Argumente werden typgeprüft; stringifizierte Werte werden abgelehnt, anstatt umgewandelt zu werden. Eingehende MCP-Frames sind vor der JSON-Parsung auf 1 MiB begrenzt. Tool- und RPC-Fehlertexte werden vor der Rückgabe von ANSI befreit, redigiert und in der Länge begrenzt. tools/call validiert Tool-Namen, objektförmige Parameter und Argumente, unbekannte Argumentnamen, Pflichtfelder, Werttypen, Enums und deklarierte Grenzen vor dem Dispatch. Lokale CLI-Tool-Befehle durchlaufen dieselbe Schema-Validierung, wobei weggelassene optionale Argumente vor der Validierung entfernt werden. Mehrzeilige send- und assign-*-Nutzlasten werden vor dem tmux-Einfügen mit Klammer-Einfüge-Markern umschlossen, damit die Codex-TUI die Vorlage als einen Prompt behandelt und nicht als separate übermittelte Zeilen.

Vor der Mutation einer Agentin prüfen oder erneuern start, assign-*, send, report-request, interrupt und stop ein Pro-Agentin-Lease. Ein zweiter MCP-Client erhält einen strukturierten wiederholbaren Fehler, anstatt in dieselbe tmux-Sitzung zu schreiben. Frische start-Leases werden nach einem erfolgreichen Start wieder freigegeben; dies hält die lokale CLI über separate Aufrufe hinweg nutzbar, während die Start-Operation selbst serialisiert bleibt. Bestehende Claims desselben verbundenen Clients bleiben erhalten. Verwenden Sie claim, wenn eine Codex-CLI-Instanz auf eine beschäftigte Agentin warten soll; es wiederholt standardmäßig endlos mit begrenzten Polling-Intervallen. Verwenden Sie claim --no-wait für einen einzelnen sofortigen Versuch oder claim --wait-seconds ... für ein explizites endliches Limit. Ein expliziter claim stellt ein gestopptes fremdes Lease nur nach der gestoppten Gnadenfrist wieder her, standardmäßig 120 Sekunden, wenn die Agentin nicht läuft und kein Prozess dieses verwaltete Agentin-Home verwendet. Verwenden Sie claim --no-recover-stopped, wenn ein Operator striktes TTL-only-Verhalten wünscht. Lease-Zustand ist nur Metadaten und gibt weder die Client-Identität, den Prompt-Text, die Agentin-Ausgabe noch den lokalen Zustandspfad zurück.

Rohe Logs sind lokale Debug-Artefakte, keine normalen API-Daten. Die tmux-Pipe schreibt über einen begrenzten lokalen Writer, doctor berichtet die konfigurierte Roh-Log-Richtlinie, und tail --source log verweigert Metadatenpfade außerhalb des verwalteten Roh-Log-Zustands. Verwaltete Roh-Logs müssen reguläre Dateien sein; symbolische Links werden nicht verfolgt und aus Roh-Log-Verzeichnissen entfernt. Der versteckte Roh-Log-Writer lehnt --max-bytes-Werte außerhalb der aktiven Roh-Log-Richtlinie ab, bevor er Zustand oder Pfade berührt. Verwenden Sie tail nur, wenn ein expliziter, begrenzter, ANSI-befreiter, redigierter Auszug benötigt wird. Fehlgeschlagene Starts entfernen ihre vorbereitete Roh-Log-Datei, bevor sie einen Fehler zurückgeben.

Die Modellrichtlinie wird einmal über den zentralen Klassen-/Lebenszyklus-/Modell-/Aufwands-Resolver aufgelöst, der oben dokumentiert ist. Start- und Zuweisungsantworten legen die effektive Auswahl, den Fallback-Zustand und die Grundcodes offen; Zuweisungs-Audit-Metadaten zeichnen das effektive Modell auf, ohne Prompts oder Antworten zu speichern.

Agentinnen dürfen eigene native Subagentinnen nur starten, wenn die Zuweisung --allow-subagents verwendet. Ohne dieses Flag verbietet die generierte Zuweisung explizit verschachtelte Delegation. Selbst mit dem Flag bleiben verschachtelte Agentinnen innerhalb des zugewiesenen Bereichs und der Schreibpfade; sie verwenden nicht codex-master-mcp und committen, pushen oder veröffentlichen nicht.

Starten Sie eine verwaltete Agentin nicht manuell mit demselben CODEX_HOME, während der Masterjet für sie verantwortlich ist. start weigert sich, eine Agentin zu starten, wenn ihr Home bereits von einem externen Codex-Prozess verwendet wird, und doctor meldet solche Home-Konflikte, bevor sie zu tmux- oder Lock-Konflikten werden. start weigert sich auch, eine bereits laufende Masterjet-Sitzung zu starten, wenn ein zweiter externer Prozess dasselbe Home verwendet. install weigert sich, codex-master-mcp aus einem verwalteten Agentinnen-Home zu registrieren, damit die Masterjet-Tools in der Teamleiterin/Hauptinstanz bleiben.

Zuweisungen werden als Metadaten an ~/.local/state/codex-master-mcp/assignments.jsonl angehängt: Zuweisungs-ID, Agentin, Rolle, ausgewähltes Modell, Skill-Match-Status, Bereich, Schreibpfade, Zählungen und Flags. Prompt-Text und Agentin-Antworten werden nicht gespeichert oder zurückgegeben, und Zuweisungsabfrageantworten geben nicht den lokalen Audit-Dateipfad zurück. Die Audit-Datei wird als begrenztes lokales JSONL-Ledger aufbewahrt: die neuesten 500 gültigen Metadaten-Datensätze werden behalten, ungültige Legacy-Zeilen werden beim Bereinigen verworfen, und die Datei wird mit 0600-Berechtigungen neu geschrieben. Private Zustandsanfügungen verweigern Symlink-Pfade, Agentin-Metadaten werden atomar geschrieben, und mit Nonce versehene temporäre Ersetzungsdateien werden mit no-follow-exklusiver Semantik erstellt. Verwaltete Zustandsverzeichnisse und ihre übergeordneten Ketten müssen echte Verzeichnisse sein, keine symbolischen Links oder regulären Dateien. Externe Prozessaufrufe sind zeitbegrenzt und geben strukturierte Timeout-Fehler zurück, anstatt den MCP-Server unbegrenzt zu blockieren. agent_doctor berichtet auch den aktiven CODEX_HOME-Kontext, ohne den Pfad zurückzugeben, und prüft, dass codex-master-mcp in der aktiven Codex-MCP-Konfiguration einen startup_timeout_sec von mindestens 120 Sekunden hat.

Verwenden Sie tail nur, wenn ein expliziter, begrenzter Auszug benötigt wird. Normale Status- und Send-Operationen geben keine Agentin-Ausgabe zurück. tail weigert sich, Pane- oder Log-Ausgabe zu lesen, während die ausgewählte Agentin ein aktives Lease hat, das von einem anderen MCP-Client gehalten wird; beanspruchen Sie die Agentin zuerst oder warten Sie auf den Ablauf des Leases.

Plugin

Dieses Repo ist auch ein lokales Codex-Plugin:

• .codex-plugin/plugin.json: Plugin-Metadaten und Codex-UI-Informationen

• .mcp.json: startet codex-master-mcp aus diesem Repo ohne Paketinstallation und deklariert startup_timeout_sec = 120

• skills/codex-master-fleet/SKILL.md: Teamleiterin-Skill für den Masterjet

Das Plugin ist für die Haupt-/Teamleiterin-Codex-Instanz gedacht. Verwaltete Agentinnen sollten ihren separaten Worker-Skill behalten und keine Masterjet-MCP-Tools erhalten.

Ein Marketplace-Eintrag ist optional. Das Repo enthält die Plugin-Artefakte, und die bestehende codex-master-mcp-Registrierung kann den MCP-Server direkt ausführen. Fügen Sie einen persönlichen/lokalen Marketplace-Eintrag nur hinzu, wenn Sie möchten, dass die Codex-Plugin-UI es als Plugin entdeckt und installiert.

Checks

git diff --check
PYTHONPATH=src python3 -m compileall -q src tests
PYTHONPATH=src python3 -m unittest discover -s tests -v
./bin/codex-master-mcp tools

./bin/codex-master-mcp commit-ready-check führt das lokale Release-Gate für git diff --check, compileall und die Unit-Tests aus.

GitHub Actions verwendet .github/workflows/ci.yml, um dieselben Quell- und Unit-Test-Gates auszuführen, plus Plugin-/App-/MCP-Manifest-Validierung, Committed-Whitespace-Prüfungen für den gepushten oder Pull-Request-Commit-Bereich, einen CLI-Wrapper-Smoke-Test, Full-SHA-Pinning-Prüfungen für externe Workflow-Aktionen und einen temporären Agent-Pool-Installer-Smoke für validate, install, status und destroy_pool.