The residence is scaffolded - the sandbox VM is provisioned, running, and ready for its new guest.
The VM: Technical Details
It boots from a golden image, reverts in roughly seventeen
seconds, and keeps a 100GiB /work disk that survives being torn down
and rebuilt.
From inside, the Internet works - but from a network perspective, nothing else does, by design: the LAN, my tailnet, even its own host are unreachable, and every new outbound connection lands in the kernel log.
Forty-seven automated tests/checks assert as much. That number will look quaint sooner than later.
Root and sudo - Developer means developer
The agent is master of its own domain in every orderinary sense - no sudo prompts or approval steps for it for anything on its own machine (the VM guest). That’s deliberate, and anything else would not only be an enormous pain to set up, it would be theatre; if we are calling the agent’s environment a true dev/build environment, it needs the ability to install packages and access all the resources that a developer would need.
(In my career, I worked somewhere that didn’t give me root access to my own workstation - for about six hours, writing tickets about how I couldn’t do my job. I had root the next day. I probably wouldn’t have bothered to show up if I didn’t have it by the following one.)
An agent that has to ask permission is a different experiment, and a less interesting one.
What “root” actually means
The containment lives one layer out, at the VM network edge, where it can be enforced by something the agent does not control:
- transfers are host-initiated in both directions
- there is no shared filesystem —
/work/inand/work/outare rsync targets, not mounts of anything real - the guest has no key to the host, and the firewall drops guest→host:22 regardless of what the guest believes
The operative assumption is the uncomfortable one: any credential that enters the guest is already public. Not “might leak” - leaked, from the moment it arrives. Everything else follows from taking that literally.
What still needs to be done
The brief. What do I ask the agent to actually do?
It is easy to write a goal that produces a demo and hard to write one that produces something worth chronicling. “Build a website” is the former. I don’t - yet - quite have the latter, and I would rather leave the machine idle than start it on a task whose only interesting outcome is that it finished.
I know that a significant part of the brief will be its own absence. The agent will have agency. However, previous experiments I have run have shown that prompts like “You have the following tools. Now just be” and similar result in … Well, not much worth chronicling. Claudes, Gemmas, GPTs, Qwens - they all seem very happy just navel-gazing and reaching <|end_turn|>.
I wish to provide a gentle nudge, but those words are “load-bearing,” if I may quote my future tenant.
So: a running sandbox, a locked network, an empty chronicle, and an unwritten brief. Here we are.
Now, be.