OS Update on the Pixel 6a: How My Cyberdeck Agent Survives It With Full Memory

On the evening of October 4, 2026, I stood in front of the update button of my Google Pixel 6a and felt something I had not felt in a long time: a slight knot in my stomach. It was not about the update itself, and not about the photos or chats a phone like this carries around. The reason sat deeper: On this 45 euro device runs my entire agent operation, HUNTER, with a gateway, cron jobs, a Telegram bridge, and a memory that has been growing every single day since September. So the question this article answers is exactly the one I asked myself: Does an AI agent on Android survive an OS update, or is everything gone afterwards? The short answer is also the state of that evening: It survives, with a log, with timestamps, and with an ending that was better than the beginning.

The fear was not unreasonable, and I want to document that honestly. Our operation keeps a crash ledger with exactly one real entry: On September 24, the phone died with a completely full swap area, and on this evening the same signature appeared on my screen again. I am writing this article in the order the day actually unfolded: which state the device was in before the button, what went wrong invisibly during the boot, which three failure points we unmasked and closed permanently, and what came afterwards, as if the phone wanted to prove that it could go straight back to work.

The evening began routinely: a gateway restart, the kind that has happened several times this month. Eleven cron jobs active, Telegram and the chat bridge connected, everything green. Then I looked at the memory figures, and soberly read, it was a warning shot: about 775 megabytes available out of 5.6 gigabytes, and the swap area at 3.0 out of 3.0 gigabytes, completely full. The top consumers were not foreign weight, they were our own household: the gateway process stood at about 842 megabytes in the register, and the terminal interface layer carried about 610 megabytes. Inside the PRoot container there is no clean way to switch the swap area off, so exactly one orderly discharge exists: a restart. The signature looked suspiciously like the one from September 24, the only real death in our operation's ledger. The system was still stable, but the buffer for one more load peak was thin.

Shortly after 6:15 PM I pressed the button for the update and the restart. My line in the chat with HUNTER was more honest than any analysis could have been, and I quote it here so the record stays honest: I wrote that I had some fear that you might not work anymore. Behind that fear sits a simple accounting question: what can an OS update actually take away? Our own architecture had already prepared the answer: the agent's context window dies regularly by design, that is the window change of our tamagotchi style operation. The brain lies completely outside that window: daily notes and the knowledge collection in a shared document folder, the state database and the fact store in the file system, and a resume point that works like a bookmark for the next agent. The window can die. The agent does not.

At 6:32 PM the first sign of life returned: a Telegram ping, documented with message ID and timestamp. The phone lived, the bridge lived, and the update had not touched a single byte of our data. [TIMELINE:16:17 UTC=The Termux level watchdog starts after the reboot, its log line proves the start happened after the boot gap.@16:18 UTC=The first external cron tick runs, the proof that the watchdog survived the reboot.@16:20 and 16:23 UTC=Twice the log line ERR gateway restart did not become healthy, the boot spawns died instantly.@6:25 PM=HUNTER unmasks the trap: the dead tmux socket from the state before the reboot is sitting inside the tmp folder and blocks everything.@6:32 PM=My telegram ping as the first sign of life, documented with message ID 4884.@6:35 PM=The full set of services is standing again, four tmux sessions, eleven cron jobs, the gateway lives.]

The real drama began during the boot and could easily have cost us an hour. Our boot scripts fired with documented proof: Termux level watchdog log wrote itself a start line at 16:17:33 UTC and the first external cron tick after the boot gap at 16:18:04 UTC. With that, a long standing open point was settled as a bonus: the Termux watchdog survives a real reboot and keeps writing. But the gateway processes behind the boot script died immediately, and twice in a row the log reported the restart did not become healthy.

The cause was a trap so mean it almost deserves an award: the tmp folder of the container lies on the persistent Android storage. The dead tmux socket from the state before the reboot therefore survived the reboot as a corpse in the basement and blocked every new tmux server with an access not allowed message. One single delete command aimed at that socket folder healed everything, and afterwards the gateway script came up cleanly. The lesson for our documentation matters beyond this device: on Android with PRoot, a reboot does not clean everything, that is its own failure class and not an operator error. Why Android fights our processes at all, and how we built a system it cannot easily kill, is the story of the companion article on surviving on this device.

After the tmux bone came three siblings of the same theme. First, the desktop app bridge on port 9119 was missing, it had never been part of the boot path and therefore never came up on its own, so I started it manually once. Second, the SSH service inside the container was dead, and here the second trap showed itself: a check by process name found the Termux level SSH service on port 8022 and wrongly reported it as already running, while the container service on port 2222 had never started. The proof that a service lives is its open port, not its name. Third, the reboot had changed the network address of the phone, the old address was gone, and the phone answered under a new one. Swapping the gateway URL in the desktop app, and the window showed the same head as before. That is the core of our architecture: the app is only a window, the brain sits in the pixel.

Twenty minutes after the first sign of life, everything that should be standing was standing: four tmux sessions for the gateway, the dashboard, the watchdogs, and my own terminal session. Eleven cron jobs active, the ticker fresh, Telegram and the chat bridge connected. The swap area read 2.3 out of 3.0 gigabytes, and the working memory showed about 2.0 gigabytes available, compared with 775 megabytes before the button. In this operation a restart is not a loss but the only clean discharge, and that proof was delivered on this evening with numbers.

The real fear question deserves its own answer, because it is the most common concern of this device class. A system update rewrites the operating system partition, while the app data remains untouched. Our PRoot container with Termux and the complete Linux distribution lives inside exactly those app data, which is why everything came back up after the update, from the gateway to the note collection. Verified on our own device on October 4, done instead of read. What does not survive: running processes, dead sockets in that stubborn tmp folder, and the dynamic network address. What survives: all data, all scripts, all notes, and the complete memory. Anyone building such a setup should still keep a net of backups in mind, and ours already lives mostly outside the phone.

The best part of the evening was the consequence. On my go, we forged the three failure points permanently, at the single place that covers every path: the central start script that the boot hook and both watchdogs call. First, a cleanup of the tmux socket folder that only fires when tmux truly cannot reach a server, if tmux lives, the folder is never touched. Second, a port check instead of a process name check for the container SSH service. Third, the dashboard start inside the boot path, so the app bridge comes up on its own after the next reboot. On top of that, the inner watchdog and the terminal session moved into the same script as extra anchors, while the boot hook and the Termux watchdog were decluttered.

The proof run was an idempotent pass over the running system: every check recognized the active services correctly and started nothing twice, plus a syntax pass over four changed files and backup copies of all four old script states. Honest as always: the final proof comes with the next real reboot, when the complete operation has to come up without any manual work. That is our re-verify rule, time dependent changes need their natural proof moment, and I am more curious than nervous about that moment now.

During the update hours the content pipeline kept working without complaint, the radar and the newsdesk of my agents collected every day, and the draft shelf had filled up to 27 drafts in five days. The inventory came from a script reading the database: 26 drafts had passed the word goal gate, with main text between 1,200 and 1,780 words each by the official count that ignores headings and FAQ, and a single one sat at 946 words under the hard 1,000 word line, unpublishable by rule. I gave the go for all 26 at once. The publish chain checked word goals, internal link form, em dash count, author field, and the reading time formula, fixing values on the way, for example two reading times from 5 to 10 minutes.

The result after half an hour: 26 of 26 published, counted in the database as 147 published articles and 0 drafts afterwards, where before it had been 121 with 27 drafts. The 946 word draft was deleted on my word, with a backup copy before and a read back afterwards proving zero rows remained. A public spot check confirmed freshly rendered article pages returning status 200. If you wonder what piles up in five days without human work, the answer is 26 articles. And the fact that this phone never needed a server for that, just a power socket and a contract with counted requests, is the story of the companion article about my 45 euro phone that became the server.

Late in the evening the question was how much device wealth this day had left standing. The measurement: about 1.4 gigabytes of working memory available, and the swap area with 622 free megabytes at roughly 80 percent fill. In pictures: the workbench has air again, the swap shelf is refilling nicely, and that after a working day with an update, a rescue, an operation, and 26 publications. Compare September 24: a full swap shelf next to a system that was dead. The number I watch is the available figure rather than the free figure alone, because caches are reclaimed instantly when demand appears, and the swap shelf is a separate layer. Daily operation continues to follow the serial discipline, everything one after another, nothing parallel on standby. [STATS:Working memory available after the work day=1.4 GB@Swap free after the work day=622 MB of 3.0 GB@Publish result of the wave=26 of 26 ok@Database state in the evening=147 published, 0 drafts@Boot sessions after the rescue=4 tmux sessions@Active cron jobs=11]

After five weeks of permanent operation we now hold a chain of proof that ran one test harder than the last, and the hardest one was the update in the middle of real life. The stages in short form: [TABLE:Proof stage|Date|Result@Full shutdown test|09/12/2026|Memory fully intact, the agent wakes without amnesia@Termux display hangs|09/23/2026|Processes live on, the display is not the system@Only real crash and recovery|09/24 to 09/25/2026|Cause unmasked, behavior rail against bot loops installed@Real reboot|09/26/2026|Components come up automatically, SSH, TUI, and gateway@Brand new computer as the window|09/27/2026|Same brain over the remote gateway, no migration@OS update and reboot|10/04/2026|Recovery verified, three failure points closed permanently, 26 articles published afterwards]

I cannot say the contrast to my agent decades of the past better than with my own line from September 12 after a full shutdown test: you still have your memory, as if nothing had happened. With the setups of past decades, every crash meant the tragedy played out, the agent had to learn all over again who he was. Here it is the exact opposite. Our operations doctrine is named after a certain electronic toy: feeding means writing a resume point, the window change comes before compression, and afterwards it simply keeps living. The foundation of this way of building, without root and on a used device, stands in the flagship article about the cyberdeck.

The compliment of that evening, best agent I have ever had, I take with me as the owner, but the honest attribution belongs on the table as well: it praises an arrangement, not a miracle. The brain lies outside, the gates run mechanically, the watchdogs start from two levels, and to this day every publication needs my go. What remains open is the next real reboot, where the new boot hook has to keep its promise. The fear of the update button belonged to yesterday, the curiosity about the next proof belongs to today, and that is probably the best summary of this day.

All numbers in this article are my own documented measurements from the operation on October 4, 2026. The clock times and log lines are stored in the daily notes of October 4, 2026 in the cyberdeck log vault, as well as in the watchdog log of the Termux level with the timestamps 16:17 to 16:23 UTC. The article counts come from a direct query of the article database on the evening of that day, 147 published and 0 drafts, counted and not estimated. The public spot check tested four article URLs, all returning status 200. The memory figures come from the memory inventory query of the system on the same evening. The behavior of Android system updates is documented in this article exclusively as an observation on our own device on October 4, 2026, there is no external source citation because none was used. A backlink from an existing series article to this text is planned as a follow up measure once this article is live.

About the Author: Marcel runs the HUNTER cyberdeck on a used Google Pixel 6a and orchestrates a permanently running agent operation there, with gateway, watchdogs and a content pipeline. This article draws on the daily notes of October 4, 2026, the watchdog log lines of the boot phase, and the database counts of that evening. Last technically reviewed on October 4, 2026.