Internes Codex-Session-Inventar

Das Session-Inventar macht vorhandene Codex-Sitzungen über ihre bereits gespeicherten Indexmetadaten auffindbar und sicher wiederaufnehmbar. Identitätsbehaftete Datensätze bleiben in einer zugriffsbeschränkten internen Oberfläche; diese öffentliche Seite erklärt nur Architektur, Aggregate und Betriebsablauf.

Authentifiziertes Session-Inventar öffnen

Datenschutzgrenze

Der Extractor liest ausschließlich die threads-Metadatentabellen vorhandener Codex-State-Indizes. preview und first_user_message stehen auf einer verbotenen Feldliste und werden nicht selektiert. Rollout-/JSONL-Dateien, Chattexte, Prompts und Modellantworten werden nicht geöffnet. Accountnamen, Thread-IDs, Titel, Beschreibungen und Projektpfade erscheinen ausschließlich nach Authentifizierung.

Verifizierter Status

LIVE seit 28. August 2026. App-Release 20260828T102358Z-46815221c89a und Datenschema codex-session-inventory/v2 sind aktiv. Der Supervisor-Dienst codex-session-inventory aktualisiert den Snapshot alle 15 Minuten.

Die Zahlen sind ein zeitgebundener Snapshot und ändern sich bei späteren Refreshes. Mehrquellen-Einträge werden nicht zusammengeführt: Die stabile Inventar-ID bindet stets die konkrete Metadatenquelle und Thread-ID aneinander.

Architektur und Schema

Codex-State-Indizes (read-only)
  -> Allowlist-Extractor
  -> owner-only Staging
  -> vollständige Generation
     ├── inventory.sqlite3
     ├── inventory.json
     ├── public-summary.json
     └── .complete.json
  -> var/current (atomarer relativer Symlink)
  -> lokale CLI und authentifizierte Weboberfläche

Der vollständige interne Datensatz enthält pro Session:

• Accountname, Source-Kind und stabile Source-ID;
• interne Inventar-ID und originale Thread-ID;
• Metadatentitel und eine sachlich aus Projekt-, Branch- und Runtimefeldern erzeugte Kurzbeschreibung;
• letzten Aktivitätszeitpunkt, Runtime, Projekt, Status und Resume-Hinweis;
• Zeitpunkt, SQLite-Transaktionsstatus und Dateimetadaten des Quellen-Snapshots.

sess-<24 hex> ist ein stabiles Pseudonym aus Source-ID und Thread-ID. Es schützt vor versehentlicher Offenlegung in Betriebsabläufen, ist innerhalb des geschützten Inventars aber kein Anonymisierungsersatz.

Aktualisierung und Konsistenz

1. Alle Account-, .codex-, Datenbank- und Wrapperpfade werden als echte direkte Verzeichnisse beziehungsweise Dateien validiert; Symlinks werden abgewiesen.
2. Jede SQLite-Quelle wird im read-only-Modus und in einer expliziten Lesetransaktion geöffnet. Main- und WAL-Metadaten werden vor und nach dem Lesen verglichen.
3. Die neue Generation entsteht unter einem exklusiven O_NOFOLLOW-Lock in einem 0700-Staging-Verzeichnis.
4. JSON, SQLite und öffentliche Zusammenfassung werden 0600 geschrieben, gehasht, mit Completion-Manifest versehen und per quick_check geprüft.
5. Erst danach wird die Generation atomar nach var/generations/ verschoben und var/current ersetzt.
6. Standardmäßig bleiben 32 erfolgreich abgeschlossene Generationen erhalten; unvollständige Staging-Artefakte werden unter demselben Lock bereinigt.

Eine Quelle mit parallelen Änderungen wird höchstens dreimal neu gelesen. Bleibt sie aktiv, hält die Provenienz diesen Zustand ausdrücklich als gleichzeitige Schreibaktivität fest, statt eine falsche punktgenaue Aussage zu erzeugen.

Suchen und Exportieren

Die Browseroberfläche verwendet die vorhandene __Host--Websession des Dokumentations-Wikis. Ohne gültige Sitzung antwortet sie mit 401. Suche, Pagination und JSON-Export akzeptieren Parameter nur als CSRF-geschützten POST-Body; Suchbegriffe erscheinen daher nicht in URL, Browserhistorie oder üblichen Access-Logs.

Die interne Suche umfasst Titel, Beschreibung, Account, Thread-ID, Projekt und Inventar-ID. Dynamische HTML-Werte werden escaped, SQL-Parameter gebunden und die SQLite-Datei mit read-only-Flags geöffnet. Antworten tragen no-store, noindex und eine restriktive Content Security Policy.

Für lokale, owner-only Abläufe stehen folgende Befehle bereit:

/home/wpmcp/codex-projects/session-inventory/bin/session-inventory status
/home/wpmcp/codex-projects/session-inventory/bin/session-inventory search "SUCHBEGRIFF"
/home/wpmcp/codex-projects/session-inventory/bin/session-inventory show sess-0123456789abcdef01234567

CLI-Ausgaben enthalten interne Identitätsdaten und gehören weder in das öffentliche Wiki noch in allgemeine Logs.

Sichere Wiederaufnahme

/home/wpmcp/codex-projects/session-inventory/bin/session-resume sess-0123456789abcdef01234567

Ohne weiteres Flag ist dies nur ein Dry-Run. Vor einer Ausführung prüft der Helfer:

• genau einen Datensatz und den Status resumable;
• gebundene Source-ID, Source-Kind und indizierten Codex-Home-Pfad;
• einen direkten Account-Pool-Pfad ohne Symlinkkomponenten;
• einen echten ausführbaren Account-Wrapper;
• eine kanonische UUIDv7-Thread-ID ohne CLI-Optionsmöglichkeit;
• ein vorhandenes Arbeitsverzeichnis unter dem eigenen Home, sonst einen sicheren Fallback.

Erst --execute startet den geprüften Wrapper per execv ohne Shell. Legacy-Metadaten bleiben suchbar, sind aber bewusst resume-unavailable, weil dafür kein direkt gebundener Account-Pool-Wrapper belegt ist.

Deployment und Rollback

Der App-Code liegt außerhalb des Wiki-Content-Repositories unter /home/wpmcp/codex-projects/session-inventory/. app/current zeigt atomar auf ein unveränderliches Release; stabile Helper-Links zeigen immer über diesen App-Symlink. Der Releasepublisher prüft Tests, Python/PHP/Shell-Syntax, Rewrite-Marker, Typen, Pfade, exakte Modi, Inhalte und Completion-Manifest aus demselben isolierten Staging-Snapshot.

Ein App-Rollback verwendet ausschließlich eine bereits geprüfte Release-ID:

/home/wpmcp/codex-projects/session-inventory/bin/rollback-release 20260828T102358Z-46815221c89a

Der Rollback teilt denselben exklusiven Lock, verifiziert den vollständigen Releasehash und wiederholt die Pflicht-QA, bevor app/current wechselt. Er löscht weder App-Releases noch Datengenerationen. Die ursprüngliche Projects-.htaccess vor Einrichtung der Route liegt als owner-only Backup im privaten Projekt.

Keine automatische Resume-Ausführung aus dem Browser

Die Weboberfläche ist absichtlich read-only. Sie zeigt den lokalen Wiederaufnahmeweg, startet aber weder Prozesse noch Codex-Sitzungen. Die bewusste --execute-Entscheidung bleibt einem authentifizierten Shell-Ablauf vorbehalten.

Bewusst unbekannt

• Ob ältere Legacy-Metadaten künftig einem sicher belegten Wrapper zugeordnet werden können;
• wie viele Einträge nach künftigen Codex-CLI-Schemamigrationen weiterhin sofort wiederaufnehmbar sind;
• ob alle extern erzeugten Titel sachlich ausreichend sind; ihre Inhalte werden nicht automatisch umformuliert;
• ob eine längere oder kürzere Retention als 32 Generationen betrieblich sinnvoller ist.

Unbekannte Punkte ändern nicht die Inhaltsgrenze: Chat- und Rollout-Inhalte werden auch zu Diagnosezwecken nicht geöffnet.