One Saturday morning I asked my AI where it lives. It showed me its computer — and it has no doors.
← Back homePublished: September 26, 2026
Every time I chat with Muse Everest, something somewhere runs my commands, browses the web for me, and remembers our conversations. I’d always pictured a server. This morning I asked it to open the hood and show me what’s actually in there. What followed was the most fun twenty minutes of my week — a guided tour of a computer that is locked down tighter than anything I’ve administered, and it’s all by design.
A: Mostly yes — but the question contains a wrong assumption, and correcting it was the best part. The app on my phone never talks to that machine directly. There is no inbound path at all. Instead, both sides phone home: my app connects out to Meta’s backend, and the little container connects out to the same backend, over encrypted connections on the standard secure web port. The backend relays between us. It’s a design where the computer doing my work can’t be reached from the internet at all.
A: The entire process list fits in four lines: the system manager, its log service, a hatch daemon (the runtime — everything the assistant does flows through it), and a hatch-execd helper that executes shell commands. That’s it. Every command I’ve ever asked it to run — including the ones in this tour — ran as a child of that executor process.
/etc/shadow file?A: It does — it’s just readable only by root, which is why it looked missing. The interesting part is what’s inside: every account on the box, including root, has its password locked. Nobody can log in with a password. Period. Even if someone somehow started a login service, there is no credential on the machine that would get them in.
A: The hostname is htch-runtime, and no — the box is disposable. It had been up less than two hours when I asked. It gets restarted or replaced regularly; only the home directory (files, memory, workspace) survives. The computer is cattle, the data is the pet.
A: Sort of. There’s no dedicated audit daemon, but the system journal records privileged actions — it even captured a command run during the tour. The failed-login log is completely empty: zero attempts, ever. Which makes sense for a machine with no way to log in.
A: There’s a clean split. The assistant troubleshoots everything above the runtime by running commands through it — exactly how this tour worked. But there’s no interactive login for anyone, so if the runtime itself ever dies, the assistant goes blind too. Everything below it — the host, the container lifecycle — belongs to the platform team, who can restart or replace the box from the outside.
A: Plain Ubuntu 24.04 LTS — but Meta’s own stripped-down image of it, and it’s not a virtual machine at all: it runs in a lightweight systemd-nspawn container. No snap packages anywhere — snap was never the containerization anyway. The isolation comes straight from Linux kernel features: separate namespaces for processes, networking, filesystems, and hostnames, plus resource limits. And one correction to my own mental model: it’s one container holding all the processes, not a container per process. The wall is around the whole box, not between the programs inside it.
Nothing listens. Nothing logs in. Everything phones home. That’s the shape of a personal AI’s computer — and honestly, it’s how I’d design one too.