Besitz von tmux-Agent-Sitzungen: Genehmigungen und Audits

Terminal-Multiplexer lösen ein echtes Betriebsproblem: Sie halten Arbeit am Leben, wenn eine SSH-Verbindung abbricht, der Laptop in den Ruhezustand geht oder ein Terminalfenster versehentlich geschlossen wird. Dieselbe Beständigkeit kann jedoch verschleiern, wem ein KI-Agent gehört, ob seine Genehmigung noch gilt und welcher Prozess tatsächlich eine authentifizierte Anfrage gesendet hat.

Der Fehler besteht darin, ein tmux-Fenster als Sicherheitssitzung zu behandeln. Das ist es nicht. tmux ist ein Prozessmanager für Terminalsitzungen. Sein Server kann den Terminal-Client überleben, und seine Panes können länger bestehen als die Person, die sie erstellt hat. GNU screen hat dieselbe grundlegende Eigenschaft. Wenn dein Genehmigungsmodell, deine Vorfallnotizen oder dein Audit-Prozess die Formulierung «die tmux-Sitzung» so verwendet, als würde sie einen einzigen Akteur und einen einzigen Agent-Lauf identifizieren, hast du die Untersuchung bereits unnötig erschwert.

Das ist besonders wichtig, wenn ein Agent über ein von Menschen kontrolliertes Gateway APIs oder SSH-Hosts erreichen kann. Eine Person kann einen Agenten in einem Pane starten, die Sitzung für eine Weile verlassen, den Sitzungsnamen an einen Kollegen weitergeben, sich von einem anderen Rechner aus wieder verbinden und später im selben Pane einen zweiten Agenten starten. Für den Betreiber wirkt jedes Ereignis wie eine Fortsetzung. In der Prozesstabelle sind es getrennte Fakten.

Eine tmux-Sitzung ist kein Agent-Lauf

tmux bündelt in einer benannten Sitzung Fenster und Panes, die von einem langlebigen tmux-Server gehalten werden. Ein Agent-Lauf ist ein Prozess und die von ihm gestarteten Kindprozesse. Er wird durch den Prozessstart und das Prozessende begrenzt. Das sind verschiedene Objekte. Wer sie zusammenfasst, erhält Freigabebereiche, die entweder zu weit gefasst oder später nicht erklärbar sind.

Wenn du tmux new-session -s build ausführst, startet tmux einen Server oder verbindet sich mit einem vorhandenen. Der Server erstellt für das erste Pane ein Pseudoterminal und startet eine Shell. Startet diese Shell einen Agenten, wird der Agent zu einem Nachkommen der Shell. Das Ablösen trennt die Client-Verbindung zu tmux. Normalerweise beendet es weder den Server noch die Shell oder den Agenten.

Eine typische Zeitleiste wirkt harmlos:

1. Maya startet tmux new -s release und einen Agenten in Pane 0.
2. Maya löst die Sitzung für ein Meeting ab, während der Agent weiterarbeitet.
3. Ihr Kollege verbindet sich später mit release, liest die Pane-Ausgabe und startet einen Folge-Befehl.
4. Am Abend verwendet Maya Pane 0 für einen anderen Agent-Prozess.

Der Sitzungsname blieb release. Die sicherheitsrelevanten Entitäten blieben es nicht. Es gab mindestens zwei Agent-Prozesse, zwei Interaktionen mit Menschen und möglicherweise getrennte Autorisierungsereignisse. Die Terminal-Historie kann daraus keine einheitliche Identität machen.

GNU screen verhält sich ähnlich. Ein abgelöster screen-Server besitzt Terminalfenster und Kindprozesse. Die Befehle unterscheiden sich, die sicherheitsrelevante Schlussfolgerung nicht: Der Verbindungsstatus beschreibt den Zugriff auf einen Terminal-Multiplexer, nicht den Besitz jedes darin laufenden Prozesses.

Das tmux-Handbuch beschreibt ein Client-Server-Modell und erklärt, dass der Server Sitzungen, Fenster und Panes verwaltet. Diese Formulierung ist mehr als ein Implementierungsdetail. Sie zeigt, wo die Kontinuität liegt: im Server, nicht in der Terminalanwendung, die eine Person gerade sieht. Baue Autorisierung um den Prozess auf, der eine Aktion anfordert, nicht um den Multiplexer-Container, in dem er zufällig läuft.

Die Prozessabstammung beantwortet Fragen, die Pane-Namen nicht beantworten können

Ein Prozessbaum kann zeigen, wie ein Agent gestartet wurde und welche Shell und welcher tmux-Server seine Eltern waren. Ein Pane-Titel zeigt nur eine Bezeichnung, die jemand geändert, kopiert oder veraltet zurückgelassen haben kann.

Starte die Untersuchung unter macOS oder Linux mit einer eingeschränkten Prozessansicht, solange der Prozess noch läuft:

ps -axo pid,ppid,lstart,tty,stat,command | grep -E '[t]mux|[s]creen|[a]gent'

Wichtiger als die genauen Befehlsnamen ist die Form der Ausgabe:

 8421     1 Tue Mar 12 09:14:03 2025 ??       Ss   tmux new-session -s release
 8430  8421 Tue Mar 12 09:14:04 2025 ttys002  S    -zsh
 9917  8430 Tue Mar 12 10:02:51 2025 ttys002  S+   agent-tool run deploy check

PID 9917 ist der infrage kommende Agent-Prozess. PID 8430 ist die Shell, die ihn gestartet hat. PID 8421 ist der tmux-Server. Der Wert tty kann helfen, einen Prozess einem Pane zuzuordnen, solange er existiert. Verwende ihn jedoch nicht als dauerhafte Identität. Pseudoterminals können beim Ende eines Prozesses verschwinden und nach der Neuerstellung eines Terminals anders aussehen.

Unter macOS ist pstree standardmäßig nicht installiert. Dieser Befehl liefert eine brauchbare Eltern-Kind-Ansicht, ohne zusätzliche Software zu installieren:

ps -axo pid,ppid,user,lstart,command | sort -n

Für eine bestimmte PID kannst du den Elternprozess wiederholt untersuchen, bis du den tmux-Server oder einen Startdienst erreichst:

ps -p 9917 -o pid=,ppid=,user=,lstart=,tty=,command=
ps -p 8430 -o pid=,ppid=,user=,lstart=,tty=,command=

Erfasse diese Werte, bevor du etwas beendest. Wer zuerst tmux kill-session ausführt, kann die nützlichsten Live-Belege löschen: Befehlszeilen, Elternbeziehungen und Startzeiten. Das Beenden einer Sitzung kann trotzdem die richtige Maßnahme zur Eindämmung sein. Wenn es die Lage erlaubt, solltest du jedoch vorher eine kurze Momentaufnahme erstellen.

Die Prozessabstammung hat Grenzen. Ein Prozess kann sich in einen Daemon verwandeln, forken oder sich absichtlich einem anderen Elternprozess zuordnen. Ein Agent kann außerdem einen externen Helfer mit der Arbeit beauftragen, sodass der Kindbaum beim Helfer endet. Behandle die Abstammung als Beleg für den Startkontext, nicht als Beweis für die Absicht eines Menschen. Du brauchst weiterhin Aktionsaufzeichnungen, die den anfordernden Prozess und die Autorisierung nennen, durch die die Aktion erlaubt wurde.

Die Genehmigung muss dem Agent-Prozess folgen, nicht dem verbundenen Terminal

Eine Autorisierung pro Sitzung sollte für genau einen Agent-Prozesslauf gelten und enden, sobald dieser Prozess beendet wird. Verbinden, Ablösen, der Fokus eines Panes und Neustarts des Terminal-Emulators dürfen diese Genehmigung weder erteilen noch erneuern oder stillschweigend übertragen.

Die Autorisierung pro Sitzung von Sallyport folgt diesem Prinzip: Der erste Aufruf eines neuen Agent-Prozesses fordert eine Genehmigung an, identifiziert den Prozess anhand seiner Codesignatur und behält diese Genehmigung nur für diesen Prozesslauf. Die Genehmigung wird nicht zu einer Eigenschaft eines tmux-Sitzungsnamens oder eines Shell-Prompts.

Diese Grenze klärt mehrere verwirrende Fälle. Wenn sich jemand ablöst und später wieder verbindet, während derselbe Agent-Prozess weiterläuft, hat sich der Prozess nicht geändert. Seine bestehende Sitzungsautorisierung kann weiterhin sinnvoll sein, vorbehaltlich der Tresor-Sperre und aller Zugangsdaten, für die bei jedem Aufruf eine Genehmigung erforderlich ist. Wenn der Agent beendet wird, eine Shell im Pane einen neuen Agenten startet und das Pane unverändert aussieht, muss der neue Prozess eine neue Genehmigungsentscheidung erhalten.

Versuche nicht, das Verbinden mit tmux zum Genehmigungsereignis zu machen. Die Idee ist verbreitet, weil eine menschliche Aktion wie tmux attach als brauchbares Signal wirkt. Für die Nutzung von Zugangsdaten ist es das falsche Signal. Eine Verbindung kann erfolgen, nachdem der Agent gestartet wurde, von einer anderen Person mit demselben lokalen Konto kommen oder nur dazu dienen, die Ausgabe zu prüfen. Noch wichtiger: Ein Prozess kann weiterarbeiten, obwohl überhaupt kein tmux-Client verbunden ist.

Der umgekehrte Fehler kommt in Teams ebenfalls vor: Jeder in einem verbundenen Pane eingegebene Befehl wird als von einem Menschen überwacht betrachtet. Eine Person kann sich verbinden, weggehen und einen Agenten weiterarbeiten lassen. Ein sichtbares Terminal ist keine Anwesenheitsprüfung.

Bei sensiblen Zugangsdaten hat eine Genehmigung bei jeder Nutzung einen anderen Zweck. Sie legt nicht fest, wem der Prozess gehört. Sie verlangt eine menschliche Entscheidung genau in dem Moment, in dem eine bestimmte Aktion mit Zugangsdaten angefordert wird. Halte diese Punkte auseinander:

• Die Tresor-Sperre entscheidet, ob überhaupt eine Aktion ausgeführt werden darf, während Geheimnisse geschützt bleiben.
• Die Autorisierung pro Prozess entscheidet, ob dieser Agent-Lauf Aufrufe ausführen darf.
• Die Genehmigung pro Zugangsdaten entscheidet, ob eine bestimmte Nutzung eine neue menschliche Entscheidung erfordert.

Diese Kontrollen beantworten unterschiedliche Fragen. Wer nur eine umfassende Genehmigung für eine langlebige Terminalsitzung verwendet, hat Bequemlichkeit über eine belastbare Grenze gestellt.

Ein wiederverwendetes Pane kann Genehmigungsverwirrung zwischen Läufen weitertragen

Der Fehler beginnt meist mit einer dauerhaften Sitzung namens «work», die zu einer gemeinsamen Schublade für unerledigte Befehle geworden ist. Jemand startet einen Agenten, löst die Sitzung ab, kommt Stunden später zurück, beendet ihn und startet dann in derselben Shell einen weiteren Agenten. Das Pane enthält weiterhin das frühere Protokoll, Umgebungsvariablen und den Prompt. Menschen schließen daraus auf Kontinuität, die das Betriebssystem nicht kennt.

Nehmen wir einen Vorfall an, bei dem eine API um 16:43 eine destruktive Anfrage erhält. Der Aktivitätsdatensatz identifiziert einen Agent-Prozess. Das Team öffnet tmux und findet ein Pane namens prod-fix, dessen Ausgabe um 09:00 beginnt. Es nimmt an, dass der Entwickler, der prod-fix erstellt hat, die Anfrage genehmigt hat. Diese Schlussfolgerung kann aus mehreren Gründen falsch sein:

• Der ursprüngliche Agent kann um 10:15 beendet worden sein, während um 16:40 ein anderer Prozess gestartet wurde.
• Ein zweiter Entwickler kann die Sitzung verbunden und den neuen Startbefehl ausgeführt haben.
• Der Pane-Titel kann von einer früheren Aufgabe übernommen worden sein.
• Eine Shell-Startdatei kann Zugangsdaten oder eine Zielumgebung exportiert haben, die nicht mehr zur aktuellen Arbeit passen.
• Der Prozess kann außerhalb von tmux gestartet worden sein und die Ausgabe über einen anderen Mechanismus in das Pane geschrieben haben.

Die richtige Frage ist enger gefasst: Welcher ausführbare Prozess hat um 16:43 die Aktion angefordert, wer hat diesen Prozess genehmigt und welche Codesignatur wurde in der Genehmigungsoberfläche angezeigt? Danach solltest du fragen, wie dieser Prozess in den Prozessbaum des Rechners gelangt ist.

Übertreibe nicht mit einem Verbot von tmux. Eine neue, eng benannte Sitzung kann die Arbeit an einem Vorfall erleichtern, weil sie einen sichtbaren Arbeitsbereich bietet und die Ausgabe während einer instabilen Verbindung erhält. Das Risiko entsteht, wenn eine allgemeine Sitzung als Container für voneinander unabhängige Agent-Läufe wiederverwendet wird.

Verwende Namen, die Zweck und eine kurzlebige Laufkennung ausdrücken, etwa deploy-4812 statt work oder main. Der Name hilft Menschen, ist aber kein Autorisierungseingang. Beende die Sitzung, sobald der Lauf abgeschlossen ist.

Abgelöste Arbeit braucht einen Verantwortlichen und eine Ablaufentscheidung

Eine abgelöste tmux- oder screen-Sitzung kann nur dann sicher laufen, wenn jemand ausdrücklich akzeptiert hat, dass sie ohne verbundenes Terminal weiterläuft. «Ich dachte, sie wäre beendet» ist kein Verantwortungsmodell.

Bevor du einen Agenten ablöst, der authentifizierte Aktionen ausführen kann, solltest du vier Fakten im Ticket, im Vorfallprotokoll oder in der Übergabe festhalten: die PID des Agent-Prozesses, den Namen der tmux-Sitzung, die beschriebene Aufgabe und die Person, die für das Beenden verantwortlich ist. Füge außerdem einen Zeitpunkt hinzu, zu dem geprüft werden muss, ob der Agent weiterlaufen soll. Diese unspektakuläre Arbeit verhindert mehr Probleme als ausgeklügelte Namensschemata für Panes.

Ein nützliches Startmuster erstellt für einen Lauf einen neuen Socket-Namensraum, statt ein weiteres Fenster zu einem dauerhaften persönlichen Server hinzuzufügen:

tmux -L agent-4812 new-session -d -s agent-4812 \\
  'exec agent-tool run "verify deployment 4812"'

tmux -L agent-4812 display-message -p \\
  '#{session_name} #{session_created} #{pane_pid} #{pane_tty}'

Der erste Befehl startet eine abgelöste Sitzung. exec ist wichtig, weil er den Shell-Prozess durch den Agent-Befehl ersetzt. Dadurch wird die Pane-PID zu einem direkteren Ausgangspunkt für die Untersuchung. Ohne exec gehört das Pane zunächst einer Shell, die später den Agenten als Kindprozess erstellt. Das bleibt beherrschbar, fügt aber eine weitere Ebene hinzu, die geprüft werden muss.

Der zweite Befehl gibt Metadaten in einer Form wie dieser aus:

agent-4812 1731000000 9917 /dev/ttys002

Speichere diese Ausgabe dort, wo die Aufgabe verfolgt wird. Der Prozess kann später Kindprozesse forken oder beendet werden, daher ist die Ausgabe kein vollständiger Audit-Datensatz. Sie bietet Einsatzkräften einen frühen Anker, wenn sie Prozessdaten mit Aktionsprotokollen vergleichen müssen.

Wenn die Aufgabe abgeschlossen ist, beende den benannten Socket bewusst:

tmux -L agent-4812 kill-session -t agent-4812

Prüfe anschließend, ob die erwartete Agent-PID beendet wurde. Gehe nicht davon aus, dass kill-session alle Nachkommen bereinigt hat. Programme, die eigene Sitzungen oder Hintergrundhelfer erstellen, können ihr ursprüngliches Pseudoterminal überleben. Untersuche die Prozessliste erneut und widerrufe den aktiven Agent-Lauf über das Aktions-Gateway, falls dessen Aufzeichnungen zeigen, dass er weiterhin autorisiert ist.

screen hat dieselbe Identitätsfalle, aber weniger Hinweise

GNU screen erstellt eine abgelöste Sitzung, die später fortgesetzt werden kann. Die vertrauten numerischen Sitzungskennungen wirken dabei oft genauer, als sie sind. Sie identifizieren eine Instanz des screen-Servers, nicht einen bestimmten Agent-Prozess oder eine menschliche Genehmigung.

Das GNU-screen-Handbuch dokumentiert abgelöste Sitzungen und Befehle wie screen -ls und screen -r. Diese Befehle zeigen, ob ein screen-Server für eine Verbindung verfügbar ist. Sie beantworten nicht, ob der Prozess in einem Fenster derselbe ist, der zuvor ausgeführt wurde, oder ob der aktuelle Betreiber die Person ist, die eine frühere Autorisierungsentscheidung getroffen hat.

Beginne mit diesen Prüfungen, wenn screen in einen Vorfall verwickelt ist:

screen -ls
ps -axo pid,ppid,lstart,tty,stat,command | grep -E '[s]creen|[a]gent'

Ein Ergebnis wie 12345.build (Detached) identifiziert eine screen-Sitzung, die untersucht werden sollte. Gleiche sie anhand von Startzeiten und Terminals ab, bevor du dich verbindest. Das Verbinden kann die sichtbare Umgebung verändern, Shell-Hooks auslösen oder ein interaktives Programm zum Weiterlaufen bringen. Sichere bei einem sensiblen Vorfall zuerst die Beweise. Die dafür zuständige Person sollte entscheiden, ob eine Interaktion nötig ist.

Der Mehrbenutzermodus von screen erfordert besondere Vorsicht. Er kann anderen lokalen Benutzern Zugriff auf eine gemeinsam genutzte Terminalsitzung geben. Auf einem kontrollierten Rechner kann das angemessen sein. Es schwächt jedoch jede beiläufige Behauptung, dass «die Person, die sich verbunden hat», Eigentümerin der Prozesse ist. Die Autorisierung sollte weiterhin den anfordernden Agent-Prozess identifizieren und eine Entscheidung des Menschen verlangen, der das lokale Zugangsdaten-Gateway kontrolliert.

Audit-Aufzeichnungen brauchen außerhalb von tmux einen Verknüpfungspunkt

Eine belastbare Untersuchung führt drei Aufzeichnungen zusammen: den Prozessdatensatz des Betriebssystems, den Autorisierungsdatensatz und den einzelnen Aktionsdatensatz. Die Ausgabe von tmux oder screen kann diese Belege ergänzen, aber keinen davon ersetzen.

Stelle für jede untersuchte Aktion mit Zugangsdaten diese Abfolge her:

1. Identifiziere im Aktivitätsdatensatz Zeitstempel, Ziel, Methode und Ergebnis der Aktion.
2. Identifiziere den Agent-Lauf, der sie angefordert hat, und die mit diesem Lauf verbundene Autorisierungsentscheidung.
3. Vergleiche Prozessdetails und Startzeit des Laufs mit dem Live-Prozessbaum oder einer gesicherten Kopie davon.
4. Verwende Metadaten der tmux- oder screen-Sitzung nur, um den Arbeitsbereich und Übergaben des Betreibers zu rekonstruieren.
5. Prüfe, dass sich der Audit-Datensatz seit seiner Erfassung nicht verändert hat.

Der Unterschied zwischen einem Aktionsjournal und dem Terminal-Scrollback ist deutlich. Der Scrollback kann Ausgaben auslassen, rotieren, eingefügten Text aus einem anderen Prozess enthalten oder von einem Benutzer mit Zugriff auf die Sitzung verändert werden. Ein Aktionsjournal sollte die versuchte Operation und ihr Ergebnis nennen. Ist es manipulationsersichtlich, können Ermittler prüfen, ob der Datensatz intakt geblieben ist, ohne dem Terminal zu vertrauen, das ihn angezeigt hat.

Sallyport erfasst Agent-Läufe und einzelne Aufrufe in einem verschlüsselten, hashverketteten Audit-Log. sp audit verify kann diese Kette offline ohne Tresorschlüssel prüfen. Die Prüfung beweist die Integrität der aufgezeichneten Abfolge, nicht dass ein tmux-Titel den Menschen, der einen Befehl eingegeben hat, korrekt identifiziert. Halte diese Aussagen in Vorfallsberichten auseinander.

Eine nützliche Vorfallsnotiz vermeidet Formulierungen wie «die release-tmux-Sitzung hat es getan». Schreibe: «Um 16:43 hat der Agent-Lauf [Kennung] [Aktion] angefordert. Die Anfrage kam von Prozess [Kennung], der um [Zeit] gestartet wurde. Der Prozess war zum Zeitpunkt der Erfassung ein Nachkomme von [Shell oder Dienst], der dem tmux-Server [PID] zugeordnet war. [Person] genehmigte den Lauf, nachdem die angezeigte Prozessautorität geprüft worden war.» Trage nur Fakten ein, die du belegen kannst.

Diese Formulierung macht auch Lücken sichtbar. Wenn vor der Eindämmung niemand die Elternkette erfasst hat, sag das. Wenn das System die erforderliche Prozessidentität nicht speichert, fülle die Lücke nicht mit einem Pane-Namen.

Codesignatur und Identität des lokalen Kontos lösen unterschiedliche Probleme

Ein lokales macOS-Konto identifiziert einen Betriebssystembenutzer. Die Codesignatur zeigt, wer eine ausführbare Datei signiert hat. Eine tmux-Sitzung identifiziert einen Terminalserver. Keine dieser Kennungen bedeutet dasselbe. Jede deckt einen anderen Fehler auf.

Die Identität des lokalen Kontos hilft bei der Frage, welches Konto den Prozess besaß. Sie zeigt jedoch nicht, ob eine Binärdatei vom erwarteten Herausgeber stammt oder ob eine andere Person ein entsperrtes Konto verwendet hat. Die Codesignatur hilft einem Menschen, die ausführbare Datei zu erkennen, die Zugriff anfordert. Sie zeigt jedoch nicht, ob der Prozess im richtigen tmux-Pane gestartet wurde oder ob die Aufgabe selbst angemessen war.

Darum ist eine Genehmigungskarte nützlich, die bei der Anfrage eines neuen Agent-Prozesses mit der Codesignatur beginnt. Sie liefert ein stabiles Signal, das umbenannte Panes, kopierte tmux-Konfigurationen und einen Neustart des Terminal-Emulators übersteht. Außerdem werden unerwartete oder anders signierte ausführbare Dateien genau im entscheidenden Moment sichtbar.

Reduziere das nicht auf die blinde Regel «gleicher Signierer bedeutet sicher». Ein vertrauenswürdiger Signierer kann eine fehlerhafte Version ausliefern, ein lokaler Wrapper kann eine genehmigte Binärdatei in einem unsicheren Kontext aufrufen und ein signierter Prozess kann gefährliche Anweisungen erhalten. Die Prozessidentität grenzt das Genehmigungsziel ein. Genehmigungen pro Aufruf für ausgewählte Zugangsdaten und eine vollständige Aktionsspur behandeln Risiken, die die Identität allein nicht lösen kann.

Für Untersuchungen unter macOS kannst du die Signaturinformationen einer Binärdatei mit codesign prüfen:

codesign -dv --verbose=4 "$(command -v agent-tool)" 2>&1 | \\
  grep -E 'Identifier=|TeamIdentifier=|Authority='

Die Ausgabe enthält normalerweise Zeilen wie Identifier=, TeamIdentifier= und einen oder mehrere Authority=-Einträge. Erfasse diese Informationen, wenn du erklären musst, warum eine Genehmigungsoberfläche einen Prozess erkannt hat. Ersetze Belege zur Signatur nicht durch einen Pfad wie /usr/local/bin/agent-tool. Pfade lassen sich leicht überschreiben, ersetzen und über symbolische Links umleiten.

Beende die Verwendung dauerhafter gemeinsamer Sitzungen für privilegierte Agent-Arbeit

Ein dauerhafter tmux-Server namens dev, main oder shared ist kein guter Ort für Agenten, die Produktionszugangsdaten erreichen können. Er macht aktive Arbeit einfach, vermischt aber Menschen, Aufgaben, Shell-Historie, Umgebungszustand und Prozesslebenszyklen, bis niemand mehr sagen kann, wo ein Lauf endete.

Halte persönliche interaktive Multiplexer getrennt von der Agent-Ausführung. Gib jedem Agent-Lauf eine eigene Sitzung oder ein eigenes Socket. Starte ihn mit einem protokollierten Befehl, erfasse PID und Startzeit und benenne einen Verantwortlichen, bevor die Sitzung abgelöst wird. Wenn ein anderer Entwickler die Aufgabe fortsetzen muss, sollte er einen neuen Agent-Prozess starten und eine neue Autorisierungsentscheidung erhalten, statt ein altes Pane aus Gewohnheit zu übernehmen.

Teams wehren sich oft dagegen, weil die Wiederverwendung einer Sitzung effizient wirkt. Sie ist effizient, bis ein Agent nach dem Ende der ursprünglichen Aufgabe eine Anfrage sendet und das Reaktionsteam eine Stunde lang den Scrollback liest. Frische Prozessgrenzen kosten Sekunden. Eine verschwommene Grenze zu rekonstruieren dauert deutlich länger und endet häufig mit einer Annahme statt mit einer Antwort.

Die erste betriebliche Änderung ist einfach: Unbenannte, langlebige tmux- und screen-Sitzungen für Agenten mit authentifiziertem Zugriff werden untersagt. Erstelle pro Lauf eine kurzlebige Sitzung, erfasse die Startidentität und schließe sie, sobald der Lauf endet. Damit erhalten Genehmigungssysteme und Ermittler eine tatsächliche Grenze, mit der sie arbeiten können.