OS-Update auf dem Pixel 6a: So überlebt mein Cyberdeck-Agent es mit vollem Gedächtnis

Am Abend des 4. Oktober 2026 stand ich vor dem Update-Knopf meines Google Pixel 6a und hatte zum ersten Mal seit langem einen flauen Moment. Nicht wegen des Updates selbst und nicht wegen der Fotos oder Chats, die ein so ein Telefon mit sich herumträgt. Der Grund saß tiefer: Auf diesem 45-Euro-Gerät läuft mein kompletter Agentenbetrieb, der HUNTER, mit Gateway, Cron-Jobs, Telegram-Brücke und einem Gedächtnis, das seit September jeden Tag wächst. Die Frage dieses Beitrags ist deshalb genau die Frage, die ich mir gestellt habe: Überlebt ein KI-Agent auf Android ein OS-Update, oder ist danach alles weg? Die kurze Antwort ist zugleich der Stand dieses Abends: Es überlebt es, mit Protokoll, Zeitstempeln und einem Ende, das besser war als der Anfang.

Die Angst war jedenfalls nicht unbegründet, und das will ich ehrlich festhalten. Unser Betrieb hat ein Crash-Konto mit genau einem echten Eintrag: Am 24. September starb das Telefon mit komplett vollem Auslagerungsspeicher, und genau diese Signatur stand auch an diesem Abend wieder in meiner Anzeige. Ich dokumentiere den Tag deshalb in der Reihenfolge, wie er sich zugetragen hat: welcher Stand vor dem Knopf herrschte, was beim Hochfahren im Verborgenen schiefging, welche drei Fehlerstellen wir enttarnt und dauerhaft geschlossen haben, und was danach noch folgte, als hätte das Telefon beweisen wollen, dass es wieder arbeiten kann.

Der Abend begann routiniert: Ein Gateway-Restart wie öfter in diesem Monat, elf Cron-Jobs aktiv, Telegram und Buzz verbunden, alles grün. Dann der Blick auf die Speicherlage, und der war nüchtern betrachtet ein Warnschuss: rund 775 Megabyte verfügbar von 5,6 Gigabyte, Auslagerungsspeicher 3,0 von 3,0 Gigabyte, also komplett voll. Die Topbelegung war keine Fremdlast, sondern unser eigenes Haus: Der Gateway-Prozess stand mit rund 842 Megabyte im Register, die TUI-Ebene brachte rund 610 Megabyte mit. Im PRoot-Container gibt es kein sauberes Abschalten des Auslagerungsspeichers, es existiert also genau eine ordentliche Entladung: ein Neustart. Die Signatur ähnelte verdächtig der von 24. September, dem einzigen echten Todesfall unseres Betriebs. Stabil war das System trotzdem, aber der Puffer für einen Lastpeak war dünn.

Um kurz nach 18:15 Uhr drückte ich den Knopf für Update und Neustart. Meine Zeile im Chat an HUNTER war ehrlicher als jede Analyse, ich hatte, wörtlich, etwas Angst, dass du eventuell nicht mehr funktionierst. Hinter dieser Angst steht eine simple Bilanzfrage: Was kann bei einem OS-Update überhaupt verloren gehen? Die Antwort gab uns unsere eigene Architektur vor: Das Kontextfenster des Agenten stirbt sowieso regelmäßig per Design, das ist der Fensterwechsel unserer Tamagotchi-Betriebsweise. Das Gehirn liegt vollständig außerhalb des Fensters: Tagesnotizen und Wissenssammlung im gemeinsamen Dokumentenordner, die Zustandsdatenbank und der Faktspeicher im Dateisystem, der Wiederaufnahme-Punkt als Lesezeichen für den nächsten Agenten. Sterben kann das Fenster. Nicht der Agent.

Um 18:32 Uhr kam das erste Lebenszeichen zurück: ein Telegram-Ping, mit Nachrichten-ID und Zeitstempel dokumentiert. Das Telefon lebte, die Brücke lebte, und das Update hatte keine unsere Daten angefasst.

Das eigentliche Drama begann beim Hochfahren und hätte uns fast eine Stunde gekostet. Unsere Boot-Skripte feuerten nachweislich: Das Watchdog-Log der Termux-Ebene schrieb sich um 16:17:33 UTC einen Start in die Zeile und um 16:18:04 UTC den ersten externen Cron-Tick nach der Boot-Lücke. Damit war übrigens ein seit Wochen offener Punkt erledigt: Der Termux-Watchdog überlebt einen echten Neustart und schreibt weiter. Aber die Gateway-Prozesse hinter dem Boot-Skript starben sofort, und zweimal hintereinander meldete das Log, der Neustart sei nicht gesund geworden. [TIMELINE:16:17 UTC=Der Termux-Watchdog startet nach dem Neustart, die Logzeile belegt den Start nach der Boot-Lücke.@16:18 UTC=Der erste externe Cron-Tick läuft, der Beweis dass der Wächter den Neustart überlebt hat.@16:20 und 16:23 UTC=Zweimal die Logzeile ERR gateway restart did not become healthy, die Boot-Spawns starben sofort.@18:25 Uhr=HUNTER enttarnt die Falle: Der tote Tmux-Socket vom Stand vor dem Neustart liegt im Tmp-Ordner und blockiert alles.@18:32 Uhr=Mein Telegram-Ping als erstes Lebenszeichen, mit Nachrichten-ID 4884 dokumentiert.@18:35 Uhr=Soll-Besetzung komplett, vier Tmux-Sessions, elf Cron-Jobs, der Gateway läuft.]

Die Ursache war eine Falle, die man sich hübscher kaum ausdenken kann: Der Tmp-Ordner des Containers liegt auf dem persistenten Android-Speicher. Der tote Tmux-Socket vom Stand vor dem Neustart überlebte also den Neustart als Leiche im Keller und blockierte jeden neuen Tmux-Server mit einer access not allowed Meldung. Ein einziger Löschbefehl auf diesen Socket-Ordner heilte alles, danach lief das Gateway-Skript sauber an. Die Lehre ist für unsere Dokumentation wichtig: Ein Neustart räumt hier nicht alles ab, das ist bei Android mit PRoot eine eigenständige Fehlerklasse und kein Bedienfehler. Warum uns Android überhaupt an die Speicherumfänge herumeiert und wie wir Prozesse dauerhaft am Leben halten, die Systeme eigentlich killen will, steht im Schwesterbeitrag zum Überleben auf diesem Gerät.

Nach dem Tmux-Knochen folgten drei Zwillinge desselben Themas. Erstens fehlte die Desktop-App-Brücke auf Port 9119, sie steckte nie im Boot-Pfad und kam deswegen nie von allein hoch, ich startete sie einmal manuell nach. Zweitens war der SSH-Dienst im Container tot, und hier zäumte die zweite Falle auf: Ein Check per Prozessname fand den Termux-eigenen SSH-Dienst auf Port 8022 und meldete fälschlich, er laufe schon, während der Container-Dienst auf Port 2222 nie gestartet war. Der Beweis dafür, dass ein Dienst lebt, ist sein offener Port, nicht sein Name. Drittens hatte der Neustart die Netzadresse gewechselt, die alte Adresse war weg, das Telefon war unter einer neuen ansprechbar. In der Desktop-App die Gateway-URL austauschen, und das Fenster zeigte wieder denselben Kopf wie vorher. Genau das ist der Kern unserer Architektur: Die App ist nur ein Fenster, das Gehirn sitzt im Pixel.

Zwanzig Minuten nach dem ersten Lebenszeichen stand alles, was stehen soll: Vier Tmux-Sessions für Gateway, Dashboard, Wächter und meine eigene Terminal-Sitzung. Elf Cron-Jobs aktiv, Ticker frisch, Telegram und Buzz verbunden. Der Auslagerungsspeicher lag bei 2,3 von 3,0 Gigabyte, der Arbeitspeicher zeigte rund 2,0 Gigabyte verfügbar, gegenüber 775 Megabyte vor dem Knopf. Ein Neustart ist in diesem Betrieb kein Verlust, sondern die einzige saubere Entladung, und dieser Beweis wurde an diesem Abend mit Zahlen erbracht.

Die eigentliche Angstfrage verdient eine eigene Antwort, weil sie die häufigste Sorge dieser Geräteklasse ist. Ein Systemupdate lädt die Betriebssystempartition neu, die App-Daten bleiben dabei unangetastet. Unser PRoot-Container mit Termux und der kompletten Linux-Distribution lebt in genau diesen App-Daten, deshalb fuhr nach dem Update alles wieder hoch, vom Gateway bis zur Notizsammlung. Verifiziert am eigenen Gerät am 4. Oktober, ausprobiert statt gelesen. Was nicht überlebt: Laufende Prozesse, tote Sockets in diesem widerspenstigen Tmp-Ordner und die dynamische Netzadresse. Was überlebt: Alle Daten, alle Skripte, alle Notizen und das vollständige Gedächtnis. Wer so ein Setup baut, sollte trotzdem ein Netz aus Sicherungen im Kopf haben, unsere Grundlagen liegen ohnehin größtenteils außerhalb des Telefons.

Der schönste Teil des Abends war die Konsequenz. Auf mein Go hin schmiedeten wir die drei Fehlerstellen dauerhaft, und zwar an der einzigen Stelle, die alle Wege abdeckt: im zentralen Startskript, das Boot-Hook und beide Wächter aufrufen. Erstens ein Aufräumen des Tmux-Socket-Ordners, das nur greift, wenn Tmux wirklich keinen Server mehr erreicht, läuft Tmux, wird der Ordner nie angefasst. Zweitens der Port-Check statt des Prozessnamen-Checks für den Container-SSH-Dienst. Drittens der Dashboard-Start im Boot-Pfad, damit die App-Brücke nach dem nächsten Neustart von allein kommt. Dazu wanderten der innere Wächter und die Terminal-Sitzung als weitere Absicherungen in dasselbe Skript, Boot-Hook und Termux-Wächter wurden zugleich entrümpelt.

Der Beweislauf bestand aus einem idempotenten Lauf über das laufende System, alle Prüfungen erkannten die aktiven Dienste korrekt und starteten nichts doppelt, dazu ein Syntaxdurchlauf über vier geänderte Dateien und Sicherungskopien der vier Skript-Altstände. Ehrlich bleiben wir trotzdem: Den Endbeweis liefert erst der nächste echte Neustart, dann muss der komplette Betrieb ohne Handarbeit hochkommen. Das ist unsere Re-Verify-Regel, zeitabhängige Änderungen brauchen ihren natürlichen Beweismoment, und auf diesen Moment bin ich inzwischen eher neugierig als nervös.

Während der Update-Stunden lief die Content-Pipeline ungeniert weiter, der Radar- und der Newsdesk-Auftrag der Agenten sammelten tagtäglich, und das Entwurfsregal hatte sich in fünf Tagen auf 27 Entwürfe gefüllt. Das Inventar kam per Skript aus der Datenbank: 26 Entwürfe waren am Wort-Ziel-Gate vorbei, Haupttext jeweils zwischen 1.200 und 1.780 Wörtern nach der offiziellen Zählung ohne Überschriften und FAQ, ein einziger lag mit 946 Wörtern unter der harten 1.000er Linie und wäre nicht publizierbar gewesen. Ich machte das Go für alle 26 auf einmal. Die Publish-Kette prüfte Wortziel, interne Linkform, Em-Strich-Zahl, Autor-Feld und die Lesezeit-Formel und korrigierte unterwegs einzelne Werte, zum Beispiel zwei Lesezeiten von 5 auf 10 Minuten.

Das Ergebnis nach einer halben Stunde: 26 von 26 veröffentlicht, als Zählung aus der Datenbank 147 publizierte Beiträge und danach null Entwürfe, zuvor waren es 121 mit 27 Entwürfen. Der 946er-Entwurf ging auf mein Wort endgültig raus, mit Sicherungskopie vor der Löschung und einem Lese-Nachweis danach, der nur eine Zeile ergab: keine mehr. Der öffentliche Stichprobe-Check bestätigte frisch gerenderte Beitragsseiten mit Status 200. Wer sich fragt, was sich in fünf Tagen ohne menschliches Zutun so ansammelt: Die Antwort lautet 26 Beiträge. Dass auf diesem Handy dafür nie ein Server stand, sondern eine Steckdose und ein Vertrag mit gezählten Anfragen, ist die Geschichte des anderen Beitrags über mein 45-Euro-Handy als Server.

Die Frage am späten Abend war, wie viel Geräte-Vermögen dieser Tag übrig lässt. Die Messung: rund 1,4 Gigabyte Arbeitspeicher verfügbar, Auslagerungsspeicher mit 622 freien Megabyte bei etwa 80 Prozent Füllung. Übersetzt in Bilder: Die Werkbank hat Luft, das Auslagerungsregal füllt sich wieder ordentlich, und das nach einem Arbeitstag mit Update, Rettung, Operation und 26 Veröffentlichungen. Zum Vergleich der 24. September: Dort stand ein voller Auslagerungsspeicher neben einem gestorbenen System. Die Zahl, auf die ich schaue, ist die verfügbare Menge und nicht der freie Speicher allein, denn Caches rechnet das System bei Bedarf sofort weg, und das Auslagerungsregal ist eine separate Ebene. Für den Alltagsbetrieb gilt weiter die serielle Betriebsart, alles nacheinander, nichts parallel auf Vorrat. [STATS:Arbeitspeicher verfügbar nach dem Arbeitsabend=1,4 GB@Auslagerungsspeicher frei nach dem Arbeitsabend=622 MB von 3,0 GB@Publish-Ergebnis der Welle=26 von 26 ok@Datenbank-Stand am Abend=147 published, 0 drafts@Boot-Sessions nach der Rettung=4 Tmux-Sessions@Aktive Cron-Jobs=11]

Nach fünf Wochen Dauerbetrieb haben wir jetzt eine Beweiskette, die einen härteren Test nach dem anderen gefahren hat, und der härteste war das Update mitten im Leben. Die Stufen in Kurzform: [TABLE:Beweisstufe|Datum|Ergebnis@Kompletter Abschalttest|12.09.2026|Gedächtnis vollständig intakt, der Agent erwacht ohne Amnesie@Termux-Anzeige hängt|23.09.2026|Prozesse leben weiter, die Anzeige ist nicht das System@Einziger echter Crash und Recovery|24.09. bis 25.09.2026|Ursache enttarnt, Verhaltensschiene gegen Bot-Schleifen gesetzt@Echter Neustart|26.09.2026|Komponenten kommen automatisch hoch, SSH, TUI und Gateway@Brandneuer Rechner als Fenster|27.09.2026|Gleiches Gehirn über das Remote-Gateway, kein Umzug@OS-Update und Neustart|04.10.2026|Recovery verifiziert, drei Fehlerstellen dauerhaft geschlossen, 26 Beiträge danach]

Den Kontrast zu meinen früheren Agenten-Jahrzehnten kann ich nicht besser sagen als mit meiner Zeile vom 12. September nach einem kompletten Abschalttest: Du hast immer noch dein Gedächtnis, als wäre nichts gewesen. Mit den Setups der vergangenen Jahrzehnte war nach jedem Crash das Trauerspiel dran, der Agent musste jedes Mal wieder von Grund auf lernen, wer er ist. Hier ist es das genaue Gegenteil. Unsere Betriebslehre heißt in Anlehnung an das elektronische Spielzeug Tamagotchi: Füttern heißt einen Aufnahmepunkt schreiben, der Fensterwechsel kommt vor der Kompression, und danach lebt es einfach weiter. Das ganze Fundament dieser Art zu bauen, ohne Root und mit einem gebrauchten Gerät, steht im Flaggschiff-Beitrag zum Cyberdeck.

Das Lob von heute Abend, bester Agent, denn ich jemals hatte, nehme ich als Owner gerne mit, aber die ehrliche Zuordnung gehört mit auf den Tisch: Es lobt ein Arrangement und kein Wunder. Das Gehirn liegt außen, die Gates laufen mechanisch, die Wächter starten aus zwei Ebenen, und bis heute braucht jede Veröffentlichung mein Go. Was noch offen bleibt, ist der nächste echte Neustart, an dem sich zeigen muss, dass der neue Boot-Hook sein Versprechen hält. Diese Angst vor dem Update-Knopf war gestern, die Neugier auf den nächsten Beweis ist heute, und das ist wahrscheinlich die beste Zusammenfassung dieses Tages.

Alle Zahlen in diesem Beitrag sind eigene dokumentierte Messungen aus dem Betrieb am 04.10.2026. Die Uhrzeiten und Logzeilen stehen in den Tagesnotizen vom 04.10.2026 im Vault cyberdeck-log sowie im Watchdog-Log der Termux-Ebene mit den Zeitstempeln 16:17 bis 16:23 UTC. Die Beitragszählung stammt aus einer direkten Abfrage der Beitragsdatenbank am Abend jenes Tages, 147 publizierte und 0 Entwürfe, gezählt und nicht geschätzt. Der öffentliche Stichprobe-Check prüfte vier Beitrags-URLs mit Status 200. Die Speicherwerte stammen aus der Speicherinventarabfrage des Systems am selben Abend. Das Verhalten von Android-Systemupdates ist in diesem Beitrag ausschließlich als Beobachtung am eigenen Gerät vom 04.10.2026 dokumentiert, es gibt dazu keine externe Quellenangabe, weil keine verwendet wurde. Ein Rücklink aus einem Bestandsbeitrag auf diesen Text ist als nachgehende Maßnahme geplant, sobald dieser Beitrag live ist.

Über den Autor: Marcel betreibt das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a und orchestriert dort einen dauerhaft laufenden Agentenbetrieb mit Gateway, Watchdogs und Content-Pipeline. Diesem Beitrag liegen die Tagesnotizen vom 04.10.2026, die Watchdog-Logzeilen der Bootphase und die Zählungen der Beitragsdatenbank jenes Abends zugrunde. Zuletzt fachlich geprüft am 04.10.2026.