dev-bricks · lukisch · Sep 26, 2026 · Sep 26, 2026 · Sep 5, 2026 · Sep 20, 2026
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
@@ -37,6 +37,7 @@ jobs:
         run: |
           python -m pip install --upgrade pip
           python -m pip install "safe-start-for-codex @ git+https://github.com/dev-bricks/safe-start-for-codex.git@dcb369a64f403f6551bcb3bac16565c56ec79474"
+          python -m pip install "zombie-killer-tray @ git+https://github.com/dev-bricks/zombie-killer-tray.git@039b4f2c7acd69063b39d6168c757b0b2fca2438"
           python -m pip install -e ".[dev]"
 
       - name: Lint with ruff
@@ -45,5 +46,8 @@ jobs:
       - name: Compile sources
         run: python -m compileall -q src tests
 
+      - name: Lint sources and tests
+        run: python -m ruff check src tests
+
       - name: Run tests
         run: python -m pytest -q
diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md
@@ -12,12 +12,12 @@ kann die Logik getestet werden, ohne die Tray-App zu starten (der interne Python
 |---|---|
 | `config.py` | lokale Konfiguration, Standardpfade (aus `%LOCALAPPDATA%`/`%APPDATA%`/`~/.codex`), Schwellwerte |
 | `i18n.py` | leichtgewichtige DE-/EN-Lokalisierung und persistierte Sprachauswahl |
-| `processes.py` | Codex-Prozessprüfung über PowerShell/CIM; Klassifikation (`--type`), exaktes Exe-Matching, Prozessbaum, Parent-/Altersprüfung für Runtime-Waisen und fail-closed Erkennung wiederholter Runtime-MCP-Launcher |
+| `processes.py` | Codex-Prozessprüfung über PowerShell/CIM; Klassifikation (`--type`), exaktes Exe-Matching, Prozessbaum, tote-Parent-/Altersprüfung für allowlist-basierte MCP-/Language-Server-Waisen und fail-closed Erkennung wiederholter Runtime-MCP-Launcher |
 | `maintenance.py` | Backup + Retention, Integritätscheck, WAL-Checkpoint, `PRAGMA optimize`, `VACUUM`, Protokolle |
 | `health.py` | Startup-Diagnose (`diagnose`) und gezielte Reparatur (`repair_start`) — getrennt vom Wartungsblocker |
 | `orchestrator.py` | Autonome Wartung (`auto_maintain`): Aktivitätsmessung (CPU+DB des ganzen Baums), zwei Modi (safe/fast) |
 | `automation_control.py` | aktive Codex-Automatisierungen pausieren, CareCenter-eigene Pausen nachhalten und gezielt reaktivieren |
-| `watchdog.py` | Hintergrund-Wächter: reapt idle Ghosts, alte Runtime-Waisen ohne Lebenszeichen und sicher wiederholte, CPU-inaktive Runtime-MCP-Prozessbäume; erfolgreiche Waisen-Kills landen mit PID, Commandline und Kriterium im App-Log |
+| `watchdog.py` | Hintergrund-Wächter: reapt idle Ghosts und alte, CPU-inaktive MCP-/Language-Server-Waisen nur mit totem Parent; Live-Cohorts werden nicht gekillt, erfolgreiche Waisen-Kills landen mit Kind-/Parent-Identität und Kriterium im App-Log |
 | `start_repair.py` | Klassifikation der Start-Lage für die zusammengefasste „Codex reparieren"-Eskalation |
 | `repair_workflow.py` | Hang-sichere S1–S7-Eskalationsengine (rein, injizierbare Bausteine) |
 | `repair_live.py` | Echte Windows-/AppX-Implementierungen der Reparatur-Bausteine (P11 absent-Erkennung, Reinstall-Prävention) |
@@ -115,7 +115,7 @@ nicht in bereits laufende Datenbankoperationen ein.
 - Ohne explizite Archivkonfiguration werden keine Logdaten gelöscht.
 - Thread-Archivierung ist separat konfiguriert (`auto_archive_threads_days=0` bedeutet aus), wartet beim Empty-Thread-Autofix mindestens 300 Sekunden und sichert `state_5.sqlite` vor Änderungen. Ein breiter Prozess-Snapshot blockiert bei Desktop oder npm-Codex-CLI und wird unmittelbar vor Backup sowie Move erneut erhoben.
 - Startup-Reparatur beendet ausschließlich Zombie-Hauptprozesse (kein Renderer); aktive Sitzungen nie.
-- Runtime-MCP-Bereinigung gilt nur für direkte Launcher unter dem Store-Desktop-App-Server: der neueste Start-Cohort bleibt immer bestehen, mindestens zwei verschiedene Signaturen müssen exakt wiederholt sein, die Karenzzeit muss abgelaufen sein und der vollständige Kandidatenbaum darf im CPU-Sample nicht arbeiten.
+- Runtime-MCP-Erkennung gilt nur für direkte Launcher unter dem Store-Desktop-App-Server: der neueste Start-Cohort bleibt immer bestehen, mindestens zwei verschiedene Signaturen müssen exakt wiederholt sein, die Karenzzeit muss abgelaufen sein und der vollständige Kandidatenbaum darf im CPU-Sample nicht arbeiten. Für den mutierenden Reap muss zusätzlich der Parent tot sein; eine lebende Parent-Beziehung sperrt den Kill.
 - Runtime-Waisen müssen einen toten oder nach dem Kind neu belegten Parent haben, mindestens 30 Minuten alt sein und in zwei Messpunkten CPU-inaktiv bleiben. Bei `codex exec` blockieren zusätzlich ein Session-Rollout jünger als 120 Sekunden, ein noch fehlendes `--output-last-message`-Ziel oder das vollständige Fehlen dieser Output-Option den Kill. Der systemweite externe Task-Schutz pausiert außerdem die Runtime-MCP-Bereinigung bei `codex-companion.mjs` oder laufendem `codex exec`.
 - npm-/CLI-app-server, der Desktop-App-Server selbst, fremde Kindprozesse und Kandidaten mit unvollständigen Zeitdaten werden fail-closed ausgeschlossen.
-- Ghost-Targeting nutzt den exakten konfigurierten Exe-Pfad plus Prozessbaum. Runtime-Waisen nutzen stattdessen enge Typ-Signaturen: Companion-app-server, Prozessnamen mit Präfix `language_server` oder den exakten Prozessnamen `codex.exe` mit `exec`-Subcommand.
+- Ghost-Targeting nutzt den exakten konfigurierten Exe-Pfad plus Prozessbaum. Runtime-Waisen nutzen allowlist-basierte Typ-Signaturen: Companion-app-server, gängige Language-Server, MCP-Nodes oder der exakte Prozessname `codex.exe` mit `exec`-Subcommand. Die letzte bekannte Parent-Identität wird nur protokolliert und niemals als Kill-Grundlage erfunden.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -2,9 +2,9 @@
 
 ## Deutsch
 
-Vielen Dank fuer Ihr Interesse, zu diesem Projekt beizutragen!
+Vielen Dank für Ihr Interesse, zu diesem Projekt beizutragen!
 
-### Wie Sie beitragen koennen
+### Wie Sie beitragen können
 
 1. **Bug melden:** Erstellen Sie ein Issue mit dem Label `bug`
 2. **Feature vorschlagen:** Erstellen Sie ein Issue mit dem Label `enhancement`
@@ -14,27 +14,29 @@ Vielen Dank fuer Ihr Interesse, zu diesem Projekt beizutragen!
 
 1. Forken Sie das Repository
 2. Erstellen Sie einen Feature-Branch: `git checkout -b feature/mein-feature`
-3. Committen Sie Ihre Aenderungen: `git commit -m "Beschreibung der Aenderung"`
+3. Committen Sie Ihre Änderungen: `git commit -m "Beschreibung der Änderung"`
 4. Pushen Sie den Branch: `git push origin feature/mein-feature`
 5. Erstellen Sie einen Pull Request
 
 ### Code-Richtlinien
 
-- Python: PEP 8 Stil, Python 3.10+
-- Encoding: UTF-8 fuer alle Dateien
+- Python: PEP 8 Stil, Python 3.12+
+- Encoding: UTF-8 für alle Dateien
 - Sprache: Code und Kommentare auf Deutsch oder Englisch
 - Keine hardcoded Pfade oder API-Keys
-- Tests muessen gruen sein: `python -m pytest`
+- Ruff muss erfolgreich sein: `python -m ruff check src tests`
+- Tests müssen grün sein: `python -m pytest`
 
 ### Erste Schritte
 
 ```powershell
 $env:PYTHONPATH="$PWD\src"
+python -m ruff check src tests
 python -m pytest
 python -m codex_logdatenbank_wartung.cli status
 ```
 
-Ohne ausdrueckliche Zusatzregel gelten Pull Requests unter der Lizenz des Projekts (MIT).
+Ohne ausdrückliche Zusatzregel gelten Pull Requests unter der Lizenz des Projekts (MIT).
 
 ---
 
@@ -58,10 +60,11 @@ Thank you for your interest in contributing to this project!
 
 ### Code Guidelines
 
-- Python: PEP 8 style, Python 3.10+
+- Python: PEP 8 style, Python 3.12+
 - Encoding: UTF-8 for all files
 - Language: Code and comments in German or English
 - No hardcoded paths or API keys
+- Ruff must pass: `python -m ruff check src tests`
 - Tests must pass: `python -m pytest`
 
 Unless stated otherwise, pull requests are understood to be submitted under the

diff --git a/README.de.md b/README.de.md
@@ -236,7 +236,7 @@ Die folgende Matrix vergleicht CareCenter for Codex mit alternativen Betriebsans
 <a id="sec-08"></a><a id="features"></a><a id="funktionen"></a>
 ## Funktionen
 
-- Hintergrund-Wächter: prüft alle 60 Sekunden auf alte Startblocker, abgelöste Runtime-Waisen und doppelte Runtime-MCP-Prozessgenerationen. Die Waisenbereinigung verlangt einen toten Parent, eine feste Karenzzeit von 30 Minuten und zwei CPU-Messpunkte. Abgelöste `codex exec`-Läufe bleiben geschützt, solange CPU-Zeit wächst, ein Session-Rollout jünger als zwei Minuten ist oder ihr `--output-last-message`-Ziel noch fehlt; inaktive `language_server*`-Waisen bleiben bereinigungsfähig. Jeder erfolgreiche Waisen-Kill schreibt PID, Commandline und Kriterium in `app.log`. Die Runtime-MCP-Bereinigung erfasst weiterhin nur inaktive Launcher-Bäume unter demselben Store-Desktop-App-Server und behält immer den neuesten Start-Cohort.
+- Hintergrund-Wächter: prüft alle 60 Sekunden auf alte Startblocker, abgelöste Runtime-Waisen und doppelte Runtime-MCP-Prozessgenerationen. Die Waisenbereinigung verlangt einen toten Parent, eine feste Karenzzeit von 30 Minuten und zwei CPU-Messpunkte. Allowlist-basierte MCP-Nodes und gängige Language-Server werden erfasst. Abgelöste `codex exec`-Läufe bleiben geschützt, solange CPU-Zeit wächst, ein Session-Rollout jünger als zwei Minuten ist oder ihr `--output-last-message`-Ziel noch fehlt. Jeder erfolgreiche Kill beendet den vollständigen Prozessbaum (`taskkill /T`) und schreibt Kind, letzte bekannte Parent-Identität und Kriterium in `app.log`. Eine lebende Parent-Beziehung bedeutet aktive Cohort und ist immer ein Nicht-Kill.
 - Spracheinstellung im Tray: Im Bereich Einstellungen kann zwischen Deutsch und Englisch gewechselt werden. Die Auswahl wird in `config.json` gespeichert und die sichtbare Tray-Oberfläche wird sofort neu beschriftet.
 - Automatisierungssteuerung im Tray: alle aktuell aktiven Codex-Automatisierungen ausschalten, nur von CCC ausgeschaltete Automatisierungen wieder aktivieren oder Automatisierungen sofort beziehungsweise gestaffelt nacheinander einschalten. Der Abstand ist über `automation_stagger_delay_seconds` konfigurierbar (Standard: 60 Sekunden).
 - Thread-Postfachpflege: alle als gelesen markieren, ungelesene Threads älter als X Tage markieren und Threads nach einem getrennt einstellbaren Alter automatisch archivieren. Der Empty-Thread-Autofix wartet mindestens 300 Sekunden, damit neue CLI-/Desktop-Threads ihren ersten Schreibvorgang abschließen können. Änderungen werden bei Desktop- oder npm-Codex-CLI-Aktivität blockiert, unmittelbar vor Backup/Move erneut geprüft und nur mit Backups, atomarem State-Schreiben und transaktionaler Archivierung ausgeführt.
@@ -309,6 +309,8 @@ $env:CARECENTER_SAFE_START_SOURCE = "C:\Pfad\zu\REL-PUB_safe-start-for-codex"
 build_exe.bat
 ```
 
+Dasselbe Muster gilt für die optionale [zombie-killer-tray](https://github.com/dev-bricks/zombie-killer-tray)-Integration (konservative Bereinigung verwaister MCP- und Language-Server-Prozesse, gestartet als eigener Subprozess über `zombie-killer-watch`): standardmäßig auf einen exakten Commit gepinnt, überschreibbar für einen lokalen Schwester-Checkout via `$env:CARECENTER_ZOMBIE_KILLER_SOURCE`.
+
 <a id="sec-12"></a><a id="cli-usage"></a><a id="cli-befehle"></a>
 ## CLI-Befehle
 
@@ -328,6 +330,10 @@ python -m codex_logdatenbank_wartung.cli store-repair --level repair --execute
 python -m codex_logdatenbank_wartung.cli store-materials
 python -m codex_logdatenbank_wartung.cli safe-start-report
 python -m codex_logdatenbank_wartung.cli safe-start-install
+python -m codex_logdatenbank_wartung.cli zombie-killer-report
+python -m codex_logdatenbank_wartung.cli zombie-killer-install
+python -m codex_logdatenbank_wartung.cli zombie-killer-watch
+python -m codex_logdatenbank_wartung.cli zombie-killer-stop
 python -m codex_logdatenbank_wartung.cli schedule install --interval-minutes 180
 ```
 
@@ -353,12 +359,13 @@ database: %USERPROFILE%\.codex\logs_2.sqlite
 
 Codex-Pfade werden aus `%LOCALAPPDATA%`, `%APPDATA%` und `CODEX_HOME` erkannt. Neue Installationen legen auch die CareCenter-Daten standardmäßig unter `%LOCALAPPDATA%\CareCenterForCodex` ab. Bestehende lokale Setups unter `C:\_Local_DEV\codex-maintenance\` werden als Legacy-Fallback automatisch weiterverwendet. Alle Pfade lassen sich in `config.json` überschreiben.
 
-Die Runtime-MCP-Bereinigung ist über `reap_runtime_mcp_duplicates` standardmäßig
-aktiv. Ihre konservativen Vorgaben sind ein konfigurierbares Mindestalter von 3600 Sekunden
-(einer Stunde) für jeden Kandidaten-Root, 90 Sekunden Start-Cohort-Abstand, ein
-30-Sekunden-Launcherfenster, mindestens zwei verschiedene
-wiederholte MCP-Signierung und eine Sekunde CPU-Aktivitätsmessung. Alle Schwellen
-lassen sich in `config.json` anpassen.
+Die Runtime-MCP-Kandidatenerkennung ist über `reap_runtime_mcp_duplicates`
+standardmäßig aktiv. Ihre konservativen Vorgaben sind ein konfigurierbares
+Mindestalter von 3600 Sekunden (einer Stunde) für jeden Kandidaten-Root, 90
+Sekunden Start-Cohort-Abstand, ein 30-Sekunden-Launcherfenster, mindestens zwei
+verschiedene wiederholte MCP-Signaturen und eine Sekunde CPU-Aktivitätsmessung.
+Für einen Kill muss zusätzlich der Parent tot sein; eine aktive Store-App-Server-
+Cohort wird nie beendet. Alle Schwellen lassen sich in `config.json` anpassen.
 
 Die Runtime-Waisenbereinigung behält aus Kompatibilitätsgründen das Präfix
 `reap_companion_orphans`. Für `companion_orphan_min_age_seconds` gilt eine feste
@@ -382,9 +389,9 @@ größere Werte verlängern sie.
 - Safe Auto-Maintain schließt Codex erst, wenn der gesamte Prozessbaum im Leerlauf ist.
 - Der Safe-Abbruch stoppt nur das Warten vor dem Schließen von Codex; laufende Datenbankoperationen werden nicht hart unterbrochen.
 - Der Wächter beendet inaktive Ghosts ohne Renderer nur nach der konfigurierten Altersschwelle.
-- Die Runtime-MCP-Bereinigung behält immer den neuesten Start-Cohort und überspringt Kandidaten, deren CPU-Zähler noch steigen.
-- Die Runtime-Waisenbereinigung verlangt einen toten Parent sowie Alters- und CPU-Leerlaufbelege. Ein abgelöster `codex exec` bleibt zusätzlich ausgeschlossen, solange ein CPU-, Rollout- oder ausstehendes Output-Lebenszeichen vorliegt; ohne `--output-last-message`-Vertrag wird er fail-closed ausgeschlossen. Inaktive `language_server*`-Prozesse mit totem Parent bleiben Bereinigungsziele.
-- Der Codex-Desktop-App-Server, fremde Kindprozesse, aktive Codex-CLI-Arbeit und aktive Desktop-Arbeit sind von Prozessbeendigungen ausgeschlossen. Der breite read-only Detektor behandelt Desktop- und npm-CLI-Arbeit dennoch als Blocker für Thread-Store-Mutationen.
+- Die Runtime-MCP-Kandidatenerkennung behält immer den neuesten Start-Cohort und überspringt Kandidaten, deren CPU-Zähler noch steigen; ein lebender Parent ist ein unbedingtes Nicht-Kill-Kriterium.
+- Die Runtime-Waisenbereinigung verlangt einen toten Parent sowie Alters- und CPU-Leerlaufbelege. Ein abgelöster `codex exec` bleibt zusätzlich ausgeschlossen, solange ein CPU-, Rollout- oder ausstehendes Output-Lebenszeichen vorliegt; ohne `--output-last-message`-Vertrag wird er fail-closed ausgeschlossen. Inaktive MCP-Nodes und gängige Language-Server mit totem Parent bleiben Bereinigungsziele; die letzte bekannte Parent-Identität landet im Audit-Log.
+- Der Codex-Desktop-App-Server, fremde Kindprozesse, aktive Codex-CLI-Arbeit und aktive Desktop-Arbeit sind von Prozessbeendigungen ausgeschlossen. Der breite read-only Detektor behandelt Desktop- und npm-CLI-Aktivität dennoch als Blocker für Thread-Store-Mutationen.
 - Destruktive Pfade wie Store-Reset, Admin-Reparatur, Neuinstallation und Reboot sind Vorschläge oder ausdrückliche Nutzeraktionen, keine automatischen Überraschungen.
 - Der [CareCenter-Gesundheitsaustauschvertrag v1](CARE_CENTER_EXCHANGE_CONTRACT.md)
   definiert einen datensparsamen, ausschließlich lesenden Schnappschuss für
@@ -441,7 +448,7 @@ CareCenter for Codex gewährleistet vollständige Lizenztransparenz und strikte
 - **Hauptanwendung:** Lizenziert unter der freien und permissiven [MIT-Lizenz](LICENSE).
 - **GUI-Subsystem:** Entwickelt mit **PySide6** (`>=6.7`), dynamisch eingebunden unter vollständiger Einhaltung der **GNU Lesser General Public License v3 (LGPL-3.0-only)**. Es werden keine Qt6/PySide6-Quelltexte modifiziert oder in proprietärer Form verteilt. Nutzer behalten die Freiheit, die installierten PySide6-Laufzeitbibliotheken zu ersetzen oder neu zu binden.
 - **Konfigurations-Engine:** Basiert auf **tomlkit** unter der **MIT-Lizenz**.
-- **Build- & Integrationswerkzeuge:** Safe-Start-Integration (`safe-start-for-codex`, MIT), PyInstaller-Kompilierung (GPLv2 mit PyInstaller-Ausnahme) und Hatchling (MIT).
+- **Build- & Integrationswerkzeuge:** Safe-Start-Integration (`safe-start-for-codex`, MIT), zombie-killer-tray-Integration (`zombie-killer-tray`, MIT), PyInstaller-Kompilierung (GPLv2 mit PyInstaller-Ausnahme) und Hatchling (MIT).
 - **Audit- & Invarianten-Dokumentation:** Ein detaillierter Prüfbericht aller Laufzeit-, Entwicklungs- und Standardbibliotheks-Abhängigkeiten sowie der 10 Governance- und Sicherheits-Laufzeitinvarianten ist in [THIRD_PARTY_LICENSES.md](THIRD_PARTY_LICENSES.md) dokumentiert. Das historische Textformat wird in [THIRD_PARTY_LICENSES.txt](THIRD_PARTY_LICENSES.txt) weitergeführt.
 
 <a id="sec-17"></a><a id="development--license"></a><a id="entwicklung--lizenz"></a>