Your key, your box
Cline already avoids locking you to one model vendor. Self-hosting the environment closes the other half — no hosted sandbox in the middle holding your source.
Cline runs commands in a terminal, and asks before each one until you tell it not to. Give it a box, and the answer to "should I let it run this?" stops being about your laptop.
# 1. create a box for the agent
$ containarium create cline-box
# 2a. open it in VS Code over Remote-SSH — Cline runs *inside* the box
$ containarium ssh-config cline-box >> ~/.ssh/config
# 2b. …or keep the editor local and point Cline's MCP settings at the box
$ containarium mcp-url cline-box
→ shell + file tools, scoped to the boxAuto-approve
Cline asks permission for every file edit and terminal command, and lets you switch that off when you want it to just work. Everyone eventually switches it off — approving forty commands in a row isn't review, it's a reflex. The question is what the agent is auto-approved on.
Unreviewed shell commands on the machine holding your SSH keys, cloud credentials, browser profile, and every other repo you have checked out. One bad rm or a package that runs a postinstall script and the blast radius is your working life.
Unreviewed shell commands on a disposable Linux container that holds one repo and nothing else. Worst case, you delete the box and make another. That is what makes leaving autonomy on a reasonable default rather than a gamble.
The box holds an SSH key scoped to itself — not a cluster token, not your credentials. A compromised agent gets a shell in one container, not a path to anything else.
Open at both ends
Cline is Apache 2.0 and runs on whichever provider's key you hand it. Containarium's core is Apache 2.0 and installs on a VM you own. Put them together and there is no vendor between the model you chose and the machine your code runs on.
Cline already avoids locking you to one model vendor. Self-hosting the environment closes the other half — no hosted sandbox in the middle holding your source.
Toolchains and caches survive, so Cline resumes instead of reinstalling its dependencies every time you come back to a task.
Run several Cline sessions at once without them fighting over one package manager or one set of ports. We run five.
Connecting
Cline is a VS Code extension, so open the box over Remote-SSH and run it there. The extension, the terminal it drives, and the checkout all live in the container — nothing it does touches your host. Append containarium ssh-config to your SSH config and the box shows up like any other remote.
Keep the editor local and register the box's MCP server in Cline's MCP settings. Cline is already strong at MCP — it connects to servers and even builds tools on the fly — so it gets typed shell and file operations scoped to the box, with no client library to write.
Not on Cline? The same box drives Claude Code, Cursor, OpenCode, or your own agent. Need a GPU in it? That works too.
FAQ
Create a box, then open it in VS Code over Remote-SSH and run Cline there — extension, terminal, and checkout all inside the box. Or keep the editor local and register the box's MCP server in Cline's MCP settings so its tools are scoped to the box.
Auto-approve is what makes the agent autonomous and also what makes it risky — it runs commands without you reading them. The risk is in where they land. In a disposable box the worst case is a box you delete; on your laptop the worst case is your laptop, keys and all.
Yes — Cline connects to MCP servers and can build tools on the fly. Every box runs an MCP server exposing shell and file operations, so there's no client library to write.
Yes — a box is a long-lived LXC container or Kubernetes pod, so toolchains, caches, and state survive until you delete it.
Yes, and it matches how Cline already works. Cline is Apache 2.0 with your own API key; Containarium's core is Apache 2.0 on your own VM. No vendor between the model you chose and the machine your code runs on.
Start free on the hosted cloud, or self-host the open source on your own VM.