Hintergrundprozesse werden beim Exit von Hermes/Claude Code/opencode gekillt #15

New issue

Closed

opened 2026-06-13 12:57:55 +00:00 by alf · 2 comments

alf commented

2026-06-13 12:57:55 +00:00

Owner

Problem

Wenn Iris (via Hermes, Claude Code oder opencode) einen Prozess startet (z.B. ein Spiel, einen Server), wird der Prozess beendet sobald der Agent-Job abgeschlossen ist.

Ursache: Hermes läuft als One-Shot-Prozess (hermes chat -Q --yolo -q). Nach der Antwort exitiert Hermes. Kindprozesse, die nicht korrekt vom Bash-Subshell abgetrennt wurden, sterben mit.

Dasselbe gilt für Claude Code und opencode — die Agenten-Jobs laufen als Subprozesse von Iris und beenden sich nach Abschluss.

Teilfix (Hermes)

In ~/.hermes/SOUL.md neue Pflicht-Direktive hinzugefügt: iris-background-process-directive

Hermes muss ab sofort für alle Hintergrundprozesse:

nohup ... & verwenden (ignoriert SIGHUP)
disown $PID ausführen (entfernt aus Bash-Jobtabelle)
PID in ~/.hermes/processes.json speichern (für spätere Verwaltung)

Offen

Claude Code und opencode haben noch keine entsprechende Anweisung in CLAUDE.md / System-Prompt
Architektonisch wäre eine bessere Lösung: Iris startet den Agenten-Prozess mit setsid / eigener Process-Group, sodass Child-Prozesse beim Agent-Exit nicht automatisch beendet werden

## Problem Wenn Iris (via Hermes, Claude Code oder opencode) einen Prozess startet (z.B. ein Spiel, einen Server), wird der Prozess beendet sobald der Agent-Job abgeschlossen ist. **Ursache:** Hermes läuft als One-Shot-Prozess (`hermes chat -Q --yolo -q`). Nach der Antwort exitiert Hermes. Kindprozesse, die nicht korrekt vom Bash-Subshell abgetrennt wurden, sterben mit. Dasselbe gilt für Claude Code und opencode — die Agenten-Jobs laufen als Subprozesse von Iris und beenden sich nach Abschluss. ## Teilfix (Hermes) In `~/.hermes/SOUL.md` neue Pflicht-Direktive hinzugefügt: **`iris-background-process-directive`** Hermes muss ab sofort für alle Hintergrundprozesse: 1. `nohup ... &` verwenden (ignoriert SIGHUP) 2. `disown $PID` ausführen (entfernt aus Bash-Jobtabelle) 3. PID in `~/.hermes/processes.json` speichern (für spätere Verwaltung) ## Offen - Claude Code und opencode haben noch keine entsprechende Anweisung in CLAUDE.md / System-Prompt - Architektonisch wäre eine bessere Lösung: Iris startet den Agenten-Prozess mit `setsid` / eigener Process-Group, sodass Child-Prozesse beim Agent-Exit nicht automatisch beendet werden

alf commented

2026-06-13 13:04:54 +00:00

Author

Owner

Architektonischer Fix implementiert — Commit `2c8ec57`

Neuer Helper wrapProcessInNewSession() in AgentJob.swift. Alle drei Agenten (Hermes, Claude Code, opencode) werden via Python3 in einer neuen Unix-Session gestartet: os.setsid() trennt den Agenten von Iris, os.execvp() ersetzt Python3 mit dem Agenten (gleiche PID, alle Pipes bleiben intakt). Kindprozesse des Agenten erben die neue Session und werden beim Exit des Agenten zu launchd-Waisen — sie laufen weiter.

## Architektonischer Fix implementiert — Commit 2c8ec57 Neuer Helper wrapProcessInNewSession() in AgentJob.swift. Alle drei Agenten (Hermes, Claude Code, opencode) werden via Python3 in einer neuen Unix-Session gestartet: os.setsid() trennt den Agenten von Iris, os.execvp() ersetzt Python3 mit dem Agenten (gleiche PID, alle Pipes bleiben intakt). Kindprozesse des Agenten erben die neue Session und werden beim Exit des Agenten zu launchd-Waisen — sie laufen weiter.

alf commented

2026-06-13 14:45:49 +00:00

Author

Owner

Gelöst

Das Problem wurde mit einem zweiteiligen Ansatz behoben:

1. POST /notify Endpunkt im IrisRemoteServer (`abab531`)

IrisRemoteServer hat einen neuen POST /notify-Endpunkt (localhost-only, kein Auth) bekommen. Hintergrundprozesse können dort eine Completion-Notification einstellen. RemoteServerClient pollt alle 15 s via GET /notify und zeigt eingehende Signale als macOS-UNNotification an.

2. notify-iris.sh + watch_local.py (`3256416`)

Ein generelles Shell-Hilfsskript skills/notify-iris.sh wurde angelegt, das beliebige Skills via POST /notify an Iris melden können. watch_local.py (videowatch) sendet am Ende automatisch eine solche Notification.

Warum dieser Ansatz

Der ursprüngliche Versuch, Agenten-Prozesse in einer eigenen Unix-Session zu starten (setsid, 2c8ec57), musste wieder rückgängig gemacht werden (be43fcd), weil setsid die macOS-TCC-Vererbung bricht und Skills dann keine Screenshots oder Dateizugriffe mehr durchführen konnten.

Statt die Prozessgruppe zu entkoppeln, werden Hintergrundprozesse nun via HTTP-Notification gemeldet. Skills starten ihre Langläufer mit nohup/disown und rufen am Ende notify-iris.sh auf — Iris bekommt eine Benachrichtigung, sobald der Job fertig ist.

## Gelöst Das Problem wurde mit einem zweiteiligen Ansatz behoben: ### 1. POST /notify Endpunkt im IrisRemoteServer (`abab531`) `IrisRemoteServer` hat einen neuen `POST /notify`-Endpunkt (localhost-only, kein Auth) bekommen. Hintergrundprozesse können dort eine Completion-Notification einstellen. `RemoteServerClient` pollt alle 15 s via `GET /notify` und zeigt eingehende Signale als macOS-UNNotification an. ### 2. notify-iris.sh + watch_local.py (`3256416`) Ein generelles Shell-Hilfsskript `skills/notify-iris.sh` wurde angelegt, das beliebige Skills via `POST /notify` an Iris melden können. `watch_local.py` (videowatch) sendet am Ende automatisch eine solche Notification. ### Warum dieser Ansatz Der ursprüngliche Versuch, Agenten-Prozesse in einer eigenen Unix-Session zu starten (`setsid`, `2c8ec57`), musste wieder rückgängig gemacht werden (`be43fcd`), weil `setsid` die macOS-TCC-Vererbung bricht und Skills dann keine Screenshots oder Dateizugriffe mehr durchführen konnten. Statt die Prozessgruppe zu entkoppeln, werden Hintergrundprozesse nun via HTTP-Notification gemeldet. Skills starten ihre Langläufer mit `nohup`/`disown` und rufen am Ende `notify-iris.sh` auf — Iris bekommt eine Benachrichtigung, sobald der Job fertig ist.

alf closed this issue

2026-06-13 14:45:52 +00:00

alf referenced this issue

2026-10-16 18:34:02 +00:00

Plugin-Marktplatz: Katalog mit Kategorien, Grafiken und Ein-Klick-Installation #57