shuside
Open app

shu's IDE

Every agent gets its own machine.

shuside runs each coding thread in a full KVM virtual machine on your own cluster. Claude Code or Codex works inside it with a real kernel, real services, and real devices. You watch from a browser IDE built for many machines at once.

Open shusideRead the spec
  • One VM per thread
  • GPU passthrough
  • Self-hostable
  • Works on a phone

Why a whole machine

A worktree shares everything that matters.

Branches isolate files. They do not isolate port 5432, the Docker daemon, the GPU, or the phone plugged into your desk. Put four agents on one host and they fight over all of it.

Four agents, one host

git worktree
  • One Postgres on 5432. Whoever migrates first wins.
  • One Docker daemon, one set of container names.
  • One GPU, one CUDA context, out-of-memory for everyone.
  • One ADB device list. Two agents install onto the same phone.
  • One machine to wedge when an agent runs the wrong rm.

Four agents, four VMs

shuside thread
  • Own kernel, own disk, booted from an image the repo defines.
  • Own services on its own tailnet address. Same ports every time.
  • GPU passed through with VFIO. One thread holds it, the scheduler waits.
  • Own devices, own caches, own daemons.
  • Release the VM and the mess goes with it.

How a thread runs

The machine is versioned with the repo.

A .shuside/ directory in your project says what a VM looks like and how to build it. Every thread boots from that, on your cluster.

  1. Describe the VM

    project.yaml sets cpu, memory, disk, and whether the thread needs a GPU. A build script installs what the project needs, once, into a qcow2.

  2. Images are content-hashed

    The hash covers project.yaml and the build inputs. Same hash, same image, pulled from storage. Nothing rebuilds unless the definition changed.

  3. Start a thread

    The controller picks a node with room, and a free GPU if you asked for one. The worker boots a KVM guest, checks out your branch, and starts Claude Code or Codex in it.

  4. Attach from anywhere

    The terminal streams through the relay to your browser or your phone. Pause it, resume it, or release it when the PR is up.

.shuside/project.yaml
instance:
  cpu: 8
  mem_mb: 32768
  disk_gb: 120
  gpu: true
base_image: shuside-base
build_inputs:
  - vm/

# vm/build.sh installs toolchains, services,
# and emulators into the image. Run once per hash.

The IDE

Built for a fleet, not a file.

Opinionated in the direction of VS Code and Cursor. The left rail is every thread you own across every project, each one a machine.

Terminal first

The agent session is the center of the screen, streamed over the relay. Everything else is a panel you can close.

The VM desktop

noVNC to the guest display, for when the agent opens a browser, an emulator, or something with a window.

Changes and history

Working tree against the base commit, a git graph, and per-file discard behind a confirmation. Served by the guest.

PRs the model writes

One button stages, commits, pushes, and opens the pull request through a GitHub App. Nobody types commit messages.

Fits on a phone

Same app, no separate build. The rail becomes a drawer, the panels become tabs, and the terminal stays usable.

Claude Code and Codex

Sign in with the subscriptions you already pay for. Credentials sit in Vault and each thread picks one.

Coworkers

Agents that keep working after you close the lid.

A thread is a prompt, a branch, and a machine. Start it from your phone on the train, check the terminal from another laptop, come back to a pull request. The VM does not care which device you attached from, or whether you attached at all.

Self-hostable

Your hosts, your tailnet, your database.

Supabase for the backbone, KVM and libvirt on Linux machines you own, a tailnet between them. Every non-FOSS piece sits behind a named slot with a documented swap.

  • TailscaleorHeadscale, NetBird
  • Tailscale FunnelorCaddy, nginx
  • Supabase cloudorself-hosted Supabase

Opinionated on purpose

If a worktree is enough, use a worktree.

shuside is heavier than a sandbox because the problems it is for are heavier than a sandbox. It assumes Linux hosts with KVM, a tailnet, and a project where an agent needs a machine, not a folder.

Built for

  • Services that hold ports, daemons, and state while an agent works.
  • GPUs that have to be scheduled, one thread at a time.
  • Devices and emulators attached to a specific machine.
  • Many agents in flight, each one allowed to break its own box.

Not built for

  • A single repo where tests run in a second and nothing listens on a port.
  • Teams without a Linux host to run KVM on.
  • Anyone who wants a general-purpose editor. The IDE is for threads.

Give the agents a machine each.

Bring a Linux host with KVM and a project that has outgrown a worktree. shuside does the rest.

Open shuside

Under development. Expect rough edges.