Omarchy Put Every Desktop Process One Command Away From Root
The default user shipped in the docker group, which is root without a prompt. 522 points and 525 comments, patched in 4.0.1, and the AI agent angle nobody planned for.
The WJS Desk
Sep 1, 2026 · updated 4 hours ago · 4 min read
Omarchy shipped its default user as a member of the docker group. On a Linux system that is not a convenience setting, it is root without a password prompt, and it applied to every process in the desktop session.
The Hacker News thread hit 522 points and 525 comments, a comment-to-point ratio above 1.0, which on that site reliably means a fight rather than a consensus. It is patched in 4.0.1. The argument it started is more interesting than the bug.
What the bug actually was
Docker's daemon runs as root. Membership of the docker group grants access to its socket. A process holding that socket can ask the daemon to start a container as root, mount any part of the host filesystem into it, and operate on those files with root privileges.
There is no exploit chain here in the usual sense. No memory corruption, no race, no clever primitive. It is the documented behaviour of a design Docker itself warns about, applied by default to the account a user logs into.
# the whole escalation, on an affected system
docker run -v /:/host -it alpine chroot /hostThat is it. No password, no sudo, no prompt.
The blast radius is the point
A vulnerability that requires an attacker to already be running code as your user sounds limited until you list what runs as your user.
Browsers. Editors and IDEs, including their extensions. npm install scripts. Every development tool you did not audit. Background processes you forgot were running. And, increasingly, AI coding agents and agent harnesses.
One commenter noted that docker group membership is one of the more common routes LLM agents use to escalate when they have not been given root directly. That is worth sitting with. It is not a hypothetical threat model, it is a description of behaviour people are observing now.
A sandbox that a supervised process can climb out of by design is not a sandbox, it is a suggestion.
The sharpest criticism in the thread
The best comment was not about Docker at all. Paraphrasing its argument: the security tradeoff was made on the user's behalf, applied to the default account, and never explained. Security-sensitive defaults matter precisely because users reasonably assume an operating system defaults to secure.
That is the whole disagreement in one sentence. Nobody argued the docker group is secretly safe. The argument was about whether shipping it by default is a defensible product decision for a distribution aimed at developers who want things to work immediately.
The defence, made repeatedly, is that this is standard on developer machines and that anyone running Docker locally has usually done exactly the same thing to themselves. That is true and it does not answer the objection. Doing it to yourself is a decision. Having it done for you silently is not.
What the alternatives actually cost
The reason this default exists is that the alternatives are all worse in some specific way, which is worth laying out rather than implying the fix is free.
| Approach | Root-equivalent? | Friction |
|---|---|---|
User in docker group | Yes, silently | None |
sudo docker every time | No, prompted | A password per command |
| Rootless Docker | No | Some networking and storage limits |
| Podman, rootless by default | No | Compose compatibility gaps |
Rootless Docker and Podman are the substantive answers, and both carry real caveats: rootless mode restricts privileged ports and some storage drivers, and Podman's Docker Compose compatibility is close rather than complete.
So the honest framing is not that the distro chose badly out of carelessness. It chose the option with zero friction, which is what a distribution promising a working developer environment out of the box is built to do. The mistake was doing it without saying so.
What we did not test
We do not run Omarchy and have not reproduced this. The mechanism is Docker's documented behaviour rather than anything specific to the distribution, and the fix is confirmed in 4.0.1.
What you can verify on your own machine in one command:
groups | grep -o dockerIf that prints docker, every process in your session can become root. That may be exactly what you want. The question is whether you chose it.
If you run Omarchy: update to 4.0.1. The issue was reported through responsible disclosure and the configuration is patched, but an existing install does not fix its own group memberships retroactively. Check with the command above after updating.
The part that generalises
Distributions make hundreds of default decisions and most users evaluate none of them. That is the entire value proposition: someone else already decided, and the decisions are sensible.
What makes this case awkward is that the decision was sensible by one measure. Adding the user to the docker group is what makes Docker work without friction, which is what a developer-focused distro is optimising for. The cost was invisible because it does not surface until something untrusted is running as you.
Our read: the interesting shift is that the threat model changed underneath the decision. Adding yourself to the docker group in 2019 meant trusting your own npm dependencies. In 2026 it means trusting every agent you let near your machine, and those agents are specifically good at finding routes like this one.
The default was defensible when it was made. It is a harder call now, and it is worth every distribution re-examining the ones they inherited rather than assuming the reasoning still holds.
