Sandboxes used to be just for kids. Now they're where coding agents run bash commands and have an entire computer to themselves.
Before agents, platforms like CodePen and LeetCode spun up sandboxes to run untrusted code - code from users where they could potentially run destructive actions if run in non-isolated environments. After agents, sandboxes had a new use. They were perfect environments for coding agents to run code and execute bash commands. Where agents could run free.
Before agents After agents
(CodePen, LeetCode) (coding agents)
untrusted user code coding agent
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────────┐
│ sandbox │ │ sandbox │
│ │ │ │
│ run snippet │ │ bash, files, git │
│ return output │ │ installs, tests │
└──────────────────┘ └──────────────────────┘
│ │
▼ ▼
output / result PR / finished task
───────────── isolated from the host machine ─────────────Current state of sandboxes: the short-lived sandboxes
Most agents running remotely in the cloud, they run on short-lived sandboxes. These sandboxes are:
- Spun up, either from scratch or from a snapshot from a previous sandbox
- Used by an agent to perform some task
- Destroyed when the task is completed
Cursor's cloud agents, a product I love, use sandboxes to work in isolated sessions and create PRs. They work by spinning up a sandbox from a snapshot where your codebase is already setup. They work. And then after the PR is merged and the session is archived, the sandbox is torn down.
This short-lived, ephemeral sandbox are cheap to spin up and destroy, and they don't require cleanup. The tradeoff here is that work and files don't perist across sessions.
Long-lived sandboxes
So speaking honestly, long-lived sandboxes are synonymous with VPS (virtual private servers). But I like the term because sandboxes are isolated environments for agents to work, whether they're short or long-lived.
Fl0w.work was designed with long-lived sandboxes as a first-class citizen. I want you to think of your fl0w.work sandbox as your personal remote computer.
Your files are yours. They persist across sessions. You can organize them however you like, as if you were working on your own computer.
Fl0w runs in your personal computer, just as it would on your local computer when you use the fl0w CLI. All of your auth, your MCP connections, agent browser sessions, your skills they all sync beetween your local computer and your remote comuter.
Your long-lived sandbox is a personal space for your agents to:
- Work across different codebases you've cloned
- Save md files to reference across different sessions
- Organize your agent's work in a file directory you define
- Run jobs on an always-on machine
Your personal sandbox
If you're interested in getting a personal remote computer without the devops, ssh, and management know-how, try fl0w in the CLI and in fl0w.work. Run your agents and make it yours.
