The Local Editor Problem

Here's the tension: AI agents work best with full access to a filesystem. But your local machine is the wrong filesystem to give them.

And here's the other tension: browser IDEs exist, but you've spent years configuring your editor. Your keybindings are muscle memory. Switching to VS Code in a browser tab feels like wearing someone else's shoes.

These two problems seem unrelated, but they have the same solution.

The tradeoff nobody talks about

Most remote dev environments assume you'll use their browser IDE. Open a tab, start coding. It works. But it also means abandoning your local setup. Your Neovim config, your tmux layout, your shell aliases, all of it.

Some developers don't care. They're happy in a browser. That's fine.

But some developers have a setup they've refined over years. Switching editors isn't a minor inconvenience. It's giving up a tool that's become an extension of how you think.

The usual answer is "just run everything locally." But then your AI agents are modifying files on your actual machine. Installing packages into your system. Running Docker containers alongside your personal stuff. Close your laptop and the session dies.

Sandbox SDKs like Vercel Sandbox and Cloudflare Sandbox solve code execution, but they're APIs for running untrusted code programmatically. E2B and Daytona give agents disposable containers that don't persist between sessions. Codespaces and Gitpod are persistent but assume you'll use their browser IDE.

How Haven CLI works

Haven CLI uses Mutagen for bidirectional file sync between your local directory and a remote container. Edit a file locally, it appears in the container in ~200ms. An agent modifies a file remotely, it appears in your editor.

# Connect local directory to a remote workspace
haven connect . myproject-alice          # managed
haven connect . [email protected]:2222 # self-hosted

# Run AI tools in the remote container
haven opencode

# Run any command remotely
haven npm run dev

Your editor is local. Execution is remote. The sync layer sits in between.

This is a simple idea, and that's the point. There's no magic. It's file sync over SSH. Mutagen handles conflict resolution, watches for changes, and keeps things in sync. The ~200ms latency is real. You won't notice it when saving files, but you'll occasionally see a brief delay if you're watching for file changes in real time.

Where it works well

Daily development. You're building a web app. You open your editor, write code, save. The remote container runs the dev server. On managed hosting, you get a public URL automatically. On self-hosted, you handle networking yourself. Either way, AI agents run in the container with full access. Your laptop stays clean.

The "close your laptop" problem goes away. Agent sessions run in tmux inside the container. They keep running whether you're connected or not. Open another machine, run haven connect . again, same session. Your work is there.

Local editor (Neovim, VS Code, Emacs, whatever)
         ↕ Mutagen sync (~200ms)
Remote container (Docker + AI tools)
         ↕ Public URL (managed hosting)

Where it doesn't

Large monorepos with tens of thousands of files. Mutagen handles them, but initial sync takes time and you'll notice delays. For a typical project under 10k files, it feels instant. For a massive repo, it's fine. Not instant.

Anything latency-sensitive in the sub-100ms range. If you're doing real-time collaboration where every millisecond matters, local is better. For normal development, ~200ms is imperceptible.

And honestly, if you're happy with a browser IDE, you don't need this. Codespaces and Gitpod have good browser experiences. Haven CLI exists for people who refuse to give up their local editor. If that's not you, the browser workflow is simpler.

The commands

haven connect .          # Sync local dir to remote workspace
haven opencode           # Run OpenCode in remote container
haven claude             # Run Claude Code in remote container
haven npm run dev        # Run any command remotely
haven status             # Check connection and sync status
haven disconnect         # Stop syncing (container keeps running)

It's a thin wrapper around SSH and Mutagen. Just composing tools that already work well.

Haven CLI is MIT-licensed. Works with self-hosted EnvHaven instances or managed hosting. Source and docs on GitHub.