Wenn der Agent auf Freigabe oder Anmeldung wartet: Anweisung sichern und Sitzung fortsetzen

Sie öffnen auf dem iPhone ein Projekt Ihres Rechners und schreiben: „Anmeldeseite reparieren, sodass sie scrollt; bestehende Anmeldemethoden beibehalten“. Nach dem Antippen von Senden meldet die App, dass der Agent die Nachricht derzeit nicht annehmen kann. Das Terminal zeigt jedoch eine aktive Oberfläche und es gibt keinen Hinweis darauf, dass der Prozess beendet wurde.

Hier müssen zwei Fragen geklärt werden: Worauf wartet der Agent? Und was ist mit der Anweisung geschehen? Nur eine Frage zu klären reicht nicht aus. Nach Abschluss der Anmeldung wartet eventuell noch eine gesicherte Nachricht auf Ihre Entscheidung; und nach Wiederherstellung des Netzwerks läuft die soeben gesendete Anfrage womöglich bereits auf dem Rechner.

Tactic Remote 1.11 erklärt im Zusammenspiel mit einem aktualisierten Host-Companion erkannte Eingabeblockaden und sichert abgewiesene Nachrichten. Die folgenden drei Szenarien zeigen das konkrete Vorgehen. Sie dienen der Veranschaulichung der Wiederherstellungsschritte und stellen weder reale Vorfälle dar noch beschreiben sie alle Agentenoberflächen einheitlich.

Laufenden Prozess, Eingabebereitschaft und Aufgabenerledigung trennen

Dass ein Terminalprozess läuft, bedeutet nicht automatisch, dass er Programmierbefehle entgegennehmen kann. Er könnte auf die Projektbestätigung warten, eine Provider-Anmeldung verlangen oder seine Eingabemaske initialisieren. Umgekehrt beweist eine untätige Oberfläche nicht, dass der Code repariert ist; es kann lediglich bedeuten, dass gerade keine Aufgabe ausgeführt wird.

Werkzeugberechtigungen regeln Aktionen während einer Aufgabe; sie bedeuten nicht zwangsläufig, dass das Senden abgewiesen wurde. Je nach Agent, Modus und Version variieren die Meldungen. Maßgeblich sind die tatsächliche Terminalausgabe und die Hinweise der App.

Szenario 1: Ein neues Projekt wartet auf die Verzeichnisbestätigung

Sie wechseln in ein neues Repository und das Terminal fragt, ob Sie dem Verzeichnis vertrauen. In interaktiven Sitzungen zeigt Claude Code bei noch nicht als vertrauenswürdig bestätigten Verzeichnissen einen Workspace-Trust-Dialog an; die offizielle Sicherheitsdokumentation beschreibt dieses Verhalten.

Prüfen Sie zuerst den vollständigen Pfad im Terminal. Ist es das beabsichtigte Repository? Eigener Code, das Projekt eines Kollegen oder unbekannte Inhalte aus einem Download? Gleichnamige Verzeichnisse können zu verschiedenen Branches, Kopien oder separaten Workspaces gehören; der Sitzungstitel allein genügt nicht.

Erkennt 1.11 diese Wartesituation, leitet die Wiederherstellungsaktion Sie direkt ins Terminal. Reagieren Sie auf die angezeigten Optionen. Prüfen Sie nach Ihrer Entscheidung, ob der Agent seine Eingabemaske erreicht hat. Das Neustarten eines wartenden Prozesses führt meist nur zur erneuten Abfrage desselben Dialogs.

Prüfen Sie anschließend die gesicherte Anweisung. Forderte sie Änderungen oder Commits, können Sie sie ins Eingabefeld zurückholen und präzisieren:

Untersuchen Sie schreibgeschützt, wie dieses Repository startet, welche Anmeldeseiten relevant sind und welche Tests existieren. Listen Sie potenziell betroffene Dateien und beizubehaltendes Verhalten auf. Schlagen Sie zuerst ein Konzept vor; keine Dateien bearbeiten, Abhängigkeiten installieren oder committen.

Prüfen Sie, ob die Pfade in der Antwort mit dem aktuellen Repository übereinstimmen, bevor Sie die Umsetzung freigeben. Nachfolgende Werkzeugberechtigungen müssen weiterhin im Einzelfall bewertet werden; die Verzeichnisfreigabe autorisiert nicht automatisch alle Folgeschritte. Die Berechtigungsdokumentation erläutert die Autorisierungsregeln.

Szenario 2: Computer ist verbunden, aber der Agent verlangt eine Anmeldung

Ihr Tactic-Konto verwaltet die Verbindung und Autorisierung zum Entwicklungsrechner. Claude Code, Codex, Amp und Droid nutzen eigene Provider-Konten auf diesem Rechner. Dass ein Projekt auf dem Smartphone geöffnet werden kann, bedeutet nicht, dass alle diese Provider-Identitäten bereitstehen.

Ermitteln Sie zuerst, welches Programm die Anmeldung verlangt. Ist es eine Terminalabfrage des Agenten, folgen Sie dessen Authentifizierungsablauf. Erfordert der Vorgang den Browser des Rechners, schließen Sie ihn dort ab und kehren Sie zur selben Sitzung zurück. Fügen Sie keine Anmelde-URLs, Einmal-Codes oder Zugangsdaten in gewöhnliche Chatnachrichten ein.

Vergewissern Sie sich nach der Anmeldung, dass das Terminal die Maske verlassen hat und Eingaben annehmen kann. Liegt der eigentliche Fehler bei Berechtigungen, Abonnements, Netzwerkzugriff oder Konfiguration, beheben Sie diesen gezielt. Mehrmaliges Anmelden bei Tactic oder Neukoppeln des Rechners ersetzt die Authentifizierung beim Modellanbieter nicht.

Prüfen Sie danach die gesicherte Nachricht, das Eingabefeld und die Warteschlange. Wurde die Anweisung noch nicht gesendet, wählen Sie, wie Sie fortfahren. Entspricht eine neue Ausgabe bereits dieser Anweisung, werten Sie das Ergebnis aus. Dass der Bildschirm nach der Anmeldung kurz stillsteht, ist kein Grund, die Gesamtaufgabe erneut einzufügen.

Bei der Wiederherstellung prüfen, was mit der Nachricht geschieht

Version 1.11 stellt je nach erkanntem Zustand passende Aktionen bereit. Ist der Agent nachweislich nicht aktiv, steht Start & Send (Starten & Senden) zur Verfügung. Bei erkannten Wartezuständen führt Open Terminal (Terminal öffnen) direkt zur anstehenden Abfrage.

Für dieselbe gesicherte Nachricht können Sie zudem Queue (In Warteschlange einreihen) oder Edit (Bearbeiten) wählen:

Enthält das Eingabefeld bereits Text, ist die Schaltfläche Edit deaktiviert, damit neue Entwürfe nicht überschrieben werden. Ist die Warteschlange pausiert, eine Genehmigung offen oder der Aufgabenstatus unklar, belegt eine reine Wiederverbindung nicht, dass eingereihte Nachrichten bereits gesendet wurden.

Ältere Host-Companions liefern möglicherweise keine vollständige Zustandsklassifizierung, sodass die App eine generische Start & Send-Schaltfläche anzeigt. Diese Schaltfläche belegt nicht, dass der Prozess gestoppt ist. Prüfen Sie den Status im Terminal, bevor Sie starten, und aktualisieren Sie den genutzten Host-Companion.

Szenario 3: Verbindungsabbruch nach dem Senden – Zustellung zuerst prüfen

Erhält die App eine ausdrückliche Ablehnung vom Rechner, kann die Nachricht als nicht angenommene Anfrage wiederhergestellt werden. Ein Timeout oder Abbruch während des Sendens ist jedoch anders zu bewerten: Die Anfrage kann den Rechner erreicht haben, obwohl das Smartphone das Ergebnis nicht empfangen hat.

Kehren Sie zu Rechner, Projekt und Sitzung zurück und suchen Sie nach der neuesten Ausgabe zu dieser Anfrage. Bearbeitet der Agent gerade die Anmeldeseite, lassen Sie ihn fortfahren. Liegt bereits ein Ergebnis vor, prüfen Sie dieses zuerst. In der Chat-Ansicht beweist das Fehlen einer neuen Sprechblase oder das Verharren auf altem Verlauf keineswegs, dass die Anfrage nicht ausgeführt wurde; der Host kann sie im Hintergrund bereits verarbeiten.

Lautete die Anweisung beispielsweise „Reparieren und committen“, könnte ein erneutes Senden unerwünschte Doppeländerungen, einen zweiten Commit oder doppelte Ausführungen rechenintensiver Befehle auslösen. Bis Klarheit herrscht, sollte „Erneut versuchen“ nicht die Standardreaktion sein.

Ist die Sitzung nachweislich untätig, können Sie den Fortschritt abfragen:

Erläutern Sie, ob die vorherige Aufgabe bereits begonnen hat, welche Dateien bisher geändert wurden, welche Prüfungen tatsächlich liefen und ob ein Commit erstellt wurde. Führen Sie die vorherige Aufgabe nicht erneut aus und nehmen Sie keine weiteren Änderungen oder Veröffentlichungen vor.

Dies ist eine reine Statusabfrage. Wartet das Terminal noch auf Freigaben, Logins oder Berechtigungen, lösen Sie zuerst diesen Zustand; andernfalls kann auch die Abfrage blockiert werden. Lässt sich die Sitzung nicht einsehen, prüfen Sie Projekt und Prozesse direkt am Rechner.

Nach der Wiederherstellung: Arbeit anhand von Ergebnissen statt Statusanzeigen überprüfen

Prüfen Sie zuerst mit einer kleinen Anfrage, ob die Original-Sitzung normal reagiert, bevor Sie Umsetzungsaufträge erteilen. Für das Scroll-Problem aus dem Eingangsbeispiel formulieren Sie Ziel und Rahmenbedingungen gemeinsam:

Beheben Sie das Problem, dass die Anmeldeseite auf kleinen Bildschirmen nicht scrollt. Behalten Sie bestehende Anmeldemethoden, den Rückkehrprozess und den Hinweis bei abgebrochener Verifizierung bei. Erläutern Sie zuerst den minimalen Änderungsumfang. Listen Sie nach Abschluss die tatsächlichen Änderungen, durchgeführten Prüfungen, Fehler und noch manuell zu prüfenden Schritte auf. Noch nicht veröffentlichen.

Stellen Sie bei der Abnahme sicher, dass Änderungen im richtigen Repository erfolgten, die Seite tatsächlich scrollt und bestehende Anmelde- sowie Abbruchabläufe intakt sind. Testergebnisse müssen zu den aktuellen Änderungen passen; wurden nach Tests nochmals Dateien geändert, prüfen Sie betroffenes Verhalten erneut. Dass eine Antwort eintrifft, zeigt lediglich Kommunikationsbereitschaft, ersetzt aber keine Prüfung.

Erstellen Sie eine neue Sitzung erst, wenn feststeht, dass die alte nicht mehr existiert oder unbrauchbar ist. Sichern Sie zuvor Zusammenfassung, geänderte Dateien, Tests und offene Fragen. Eine neue Sitzung im selben Verzeichnis oder mit einem anderen Agenten übernimmt den bisherigen Kontext nicht automatisch.

Ist der Rechner wieder nicht erreichbar, nutzen Sie die Verbindungsfehlerbehebung. Verbindet er zwar, liefert aber keine brauchbaren Antworten, notieren Sie Agentennamen, Versionen beider Geräte, die konkrete Warteaufforderung sowie den letzten Nachrichtenstatus und kontaktieren Sie den Support. Voraussetzungen und weitere Neuerungen finden Sie in der Übersicht zu Tactic Remote 1.11.