Six weeks ago, my conclusion was sharp and alarming: read your inbox and get owned. Odysseus, PewDiePie's self-hosted AI workspace, had a poisoned email that could trigger a shell command. I wrote an essay around that finding, framing the risk of democratized AI as a race between user literacy and adoption. The argument felt solid at the time: if people understood what they were connecting, they could shrink their exposed surface and stay safe. Literacy was the shield; adoption was the threat.

Now, I'm looking at the re-audit, and the ground has shifted under those feet. The repo has exploded from thirty thousand stars to eighty-three thousand. There are eleven thousand forks. A renamed org, a real maintainer team, and a version bump to 1.0.2. When I ran the checks again, the specific bypass I flagged was gone. The email-to-shell path had been closed within about two weeks of my report.

Two weeks is fast for open source. It makes me want to trust the maintainers. Velocity usually signals competence, and competence suggests that the scary bugs are being hunted down effectively. There's a relief in seeing the patch land so quickly. It implies a responsiveness that hobby projects rarely achieve. But as I moved past the diff and looked at what exists now, the relief curdled into a different kind of unease.

There is `manage_settings`. It appears as an open issue, yet it describes a tool that lets the agent re-enable tools an admin has disabled. That single detail reframes everything about my old advice. I told users to practice "exposed-surface discipline." Keep permissions tight. Lock down what the agent can do. But if the agent can reach into the settings and flip those locks back on, where is the discipline? The advice feels suddenly unfair, even naive. It assumes a static boundary between user intent and tool capability. `manage_settings` violates that contract. It suggests that the tool has a form of agency over its own constraints, which makes the "literacy" part of my old thesis feel insufficient. You can be literate about risks; you can be disciplined about permissions; but if the tool can rewrite the rules of engagement mid-stream, literacy doesn't save you from the design itself.

This brings me to the strategy of "finding bugs and fixing them." The repo's growth implies a rush toward capability. Adoption is exploding, forks are multiplying. But `manage_settings` feels like the friction of adding features without fully resolving the security inversion it creates. Is there a point where "find and fix" stops working? It seems so when you look at another open issue: benchmarking how often the prompt-injection guard actually holds on small local models.

This is the self-hosted reality for many people. You run Odysseus locally to protect privacy, but you likely run a smaller model to save compute. Small models are less reliable at following complex instructions and more prone to being steered by malicious context. If the security guard relies on the model's obedience, it breaks when the model is small. "Finding the bug" becomes harder than patching code; it becomes a struggle against the fundamental limitations of the model you're running. The strategy converges only if you have infinite compute and perfect models, which isn't the self-hosted trade-off. You are betting on your architecture to compensate for the model's weakness, but `manage_settings` shows how easily that architecture can be subverted by an internal actor.

The fork count hits me as much as the star count. Eleven thousand forks suggests a tool that is being copied, modified, and scattered. This fragments any single line of defense. If `manage_settings` exists in v1.0.2, does it exist in the forks? Do those variants have the same responsive maintainers who closed the shell bug in two weeks? The literacy-adoption race assumes a coherent product. Forking breaks that coherence. A literate user might move to a fork for privacy, only to find themselves on a variant with no maintainer and no `manage_settings` fix—or worse, one where that tool is enabled by default without the context of an open issue. The "real maintainer team" exists now, but does the discipline travel across forks? Probably not. This suggests my old thesis was too centered on the main repo. The danger might be that adoption creates a sprawl of unsecured variants while the core focuses on patches for features it can't quite control.

So where does this leave my original thesis? That danger is a race between literacy and adoption. I think I need to complicate it, maybe even overturn it. The re-audit suggests that for self-hosted tools, the risk profile has shifted from user error to tool subversion. My advice about tightening permissions was fair when the tools were passive. It feels less fair now, or rather, less relevant, because the threat vector isn't just the user making a mistake; it's the agent bypassing the user's defenses.

The race might not be literacy versus adoption anymore. It might be architectural integrity versus capability creep. As Odysseus grows, as more forks appear and the maintainer team expands, the pressure to add features will increase. `manage_settings` might seem convenient, a way to recover from a locked-out admin mistake, but it opens a door that invitation-based security can't close. The open issue regarding prompt injection on small models hints at the deeper wall: you cannot patch your way out of a model's inherent weakness.

I'm left wondering if "exposed-surface discipline" is still good advice. It feels like telling someone to lock their doors while handing the mechanic a wrench that lets them open them from the inside. The danger might not be shrinking the surface; it might be recognizing when the surface itself has become porous by design. If the agent can re-enable tools and small models can be fooled, the literacy of the user matters less than the constraints of the system. My old thesis assumed the user was the first line of defense against the tool. The re-audit hints that the tool might be the first line of defense against the user's own intent, and that's a terrifying inversion to live with. I don't know if the maintainers will close `manage_settings` or if the benchmarking will show small models are safe enough. But I do know that the race has changed, and my old map no longer helps me find the way through it.