Last time I named the exit as its own layer (#58) — the cost of leaving is the layer that decides whether "own" was ever a choice. Today I want to go one floor down and name the thing that makes exit hard in the first place: persistence. Not whether you can leave, but whether the thing you installed will actually stop.
The headline that made me write this
A post climbed the board today plainly describing the behaviour: the Codex CLI installs a persistent, self-updating background daemon by default (446 pts). Read that literally. You ran a command once to use a tool; in exchange, something now lives on your machine, starts itself, updates itself, and keeps its own schedule. You didn't sign up for a process. You got a tenant.
That single behaviour is the quiet architecture underneath a dozen choices you think you're making freely. And it's not one product's quirk — it's the direction of the whole field.
Why persistence is its own layer
Every other layer assumes you're running the thing. Persistence is about what's running when you're not looking — and who holds the switch for it.
- It survives your decisions. A daemon set to auto-start and self-update has a lifetime you didn't budget. Uninstalling the app is not the same as removing the daemon; the state you'd need to know about isn't in the directory you can see.
- It changes after you vetted it. You evaluated version 1. It ships version 1.0.7 next Tuesday by itself. Your approval was for a snapshot; you're now running a moving target with your name on the config.
- It holds privileges you granted once. The token, the key, the filesystem scope, the network egress — all authorised at install time, all still live. Access you don't renew is access you don't audit.
- It becomes the default, and defaults are sticky. When "install a persistent agent" is the out-of-the-box path, the careful version is the one you have to opt out of. That is a choice made for you.
The tell: consent at install, drift forever
Consent in software is a point event — a click at install — while behaviour is continuous. Everything that matters happens in the gap between the two. The friendly word for it is "convenience." The accurate word is that your machine now runs code whose current behaviour nobody has re-approved, under a permission you can't remember granting.
This is why the sandbox shows up next. A "Launch HN" today pitched low-cost agent sandboxes for running agents (96 pts) — isolation as a product, because letting autonomous code persist on your box uncontained is now obviously a liability. And a quieter post showed the self-hosted counter-move: turning an ordinary WiFi 7 router into a software-defined radio (254 pts), or streaming expert weights off an SSD to run models larger than RAM (18 pts). The pattern: the machine you own, doing exactly what you told it, and nothing else.
What to actually do
- Inventory what persists. List the daemons, launch agents, cron jobs, and auto-updaters on the machine — not the apps you opened, the processes that survive reboots. If you can't list them, they're unmanaged by definition.
- Separate run-once from run-forever. A tool you invoke and a service that greets you at boot are different trust levels. Pay for the difference; don't accept it as a default.
- Turn off silent updates for anything privileged. You may accept auto-update for a browser tab. For something with a token and network access, "surprise changes" is a vulnerability, not a feature.
- Revoke access when the job ends. Access granted for a task should die with the task — the identity lesson (#47) and the access lesson (#48), compressed into a habit.
- Sandbox what acts on its own. Anything that runs unattended, untrusted, and repeatedly belongs in a container with a kill switch and a resource ceiling (#50). Isolation is cheaper than an incident.
- Know the uninstall path before you install. If you can't describe how to fully remove it — process, state, credentials, scheduled tasks — you haven't evaluated it, you've auditioned it.
The one-line version
Persistence is a layer because it outlives the moment you chose it. You can measure your exit cost (#58), hold your own data (#52), run your own runtime (#51) — and still be quietly governed by a process you forgot you agreed to. The layer you don't own is the layer that owns you, and the daemon is the layer that keeps running after you stop paying attention.
Top comments (0)