SLICC · the incredible sandbox

Wait — it runs that in a browser tab?

SLICC boots real operating systems and runs real software entirely client-side. A genuine Alpine Linux userland on a RISC-V guest. Full x86 virtual machines. A physical Android phone driven over USB. A whole agentic IDE. Just a tab you can close — nothing runs on a server.

Watch it boot Get started

style
dark full-bleed
id
hero

How far down does a tab go?

A real shell
Start with a WASM Unix userland — 126 commands, git, node, python3, pipes and all. That is the floor, not the ceiling.
A real kernel
Boot Alpine Linux on an emulated RISC-V CPU (vpod). Run uname -a, apk add a package, compile something. It is a whole distro, running in the page.
A real machine
Need x86? v86 spins up a full PC — SeaBIOS, a Linux or DOS guest, its own disk — emulated instruction by instruction in JavaScript.
Real hardware
Reach past the sandbox to a phone plugged into USB. adb devices, run a shell command, grab a screenshot — SLICC drives silicon it never virtualized.
style
light

Alpine Linux, booting in the page

This is not a screenshot of a terminal. It is a RISC-V guest running an Alpine userland inside the tab — SLICC types the commands, the kernel answers.

Animated terminal: SLICC boots Alpine Linux on a RISC-V guest with vpod, runs uname to show the riscv64 kernel, installs a package with apk, and runs it — all client-side.
id
boot
style
dark full-bleed

What a tab can run

Alpine on RISC-V

The vpod skill boots a real Alpine Linux userland on an emulated RISC-V CPU. apk add, mount a workspace, build from source — a persistent little Linux box that lives in the page.

Full x86 VMs

v86 emulates a whole PC in JavaScript: SeaBIOS, CPU, disk, network. Boot Linux, an old Windows, or FreeDOS, and interact with the screen and keyboard as if it were a machine on your desk.

A physical phone

Plug an Android phone into USB and the adb skill talks to it directly from the browser — adb devices, adb shell, install an APK, pull a screenshot. Real hardware, no host tooling.

An agentic IDE

The bb skill drives a full agentic IDE instance — open a repo, run tasks, watch an agent edit and test — orchestrated by SLICC from the same tab.

It is all just a tab

Every runtime is sandboxed by the browser itself, with no daemon or root to patch. Close the tab and every guest, VM and shell simply stops. That is the security model.

Teach it a runtime

Each of these is a markdown skill, not a hard-coded feature. Point SLICC at a skill file and it learns to drive a new emulator or device, with no extension update to ship.

style
light

Pick a runtime

Four ways to run real software in a tab. Every tab shows the actual commands SLICC runs.

vpod — RISC-V Linux

Boot an Alpine userland on an emulated RISC-V CPU, install packages, and run them — a persistent Linux box inside the page.

  • vpod boot alpine
  • vpod exec -- uname -a
  • vpod exec -- apk add cowsay --no-cache
  • vpod exec -- cowsay "hello from riscv64"
v86 — x86 VM

Emulate a full x86 PC in JavaScript: BIOS, CPU, disk and screen. Boot a guest OS and drive its display and keyboard.

  • v86 start --image linux.iso --memory 128
  • v86 keys "root\n"
  • v86 exec -- cat /proc/cpuinfo
  • v86 screenshot --out boot.png
adb — physical phone

Talk to an Android phone plugged into USB, straight from the browser — no Android Studio required.

  • adb devices -l
  • adb shell getprop ro.product.model
  • adb shell input tap 540 1720
  • adb exec-out screencap -p > screen.png
bb — agentic IDE

Drive a full agentic IDE instance: open a repository, dispatch a task, and watch an agent read, edit and test the code.

  • bb open ./my-repo
  • bb task "add a failing test and make it pass"
  • bb run -- npm test
  • bb diff --review
style
light

A whole PC, emulated in JavaScript

SeaBIOS, a kernel, a login prompt — v86 runs the entire boot sequence of an x86 machine instruction by instruction, right here in the browser.

Animated VM window: an x86 guest boots under v86 — SeaBIOS POST, kernel messages scrolling, then a login prompt — all emulated client-side in JavaScript.
style
dark full-bleed

You'd think you need

A cloud VM to spin up. A container host to patch. Android Studio and a working adb install. QEMU and the right kernel. SSH keys, a bastion, a bill. And a laptop warm enough to fry an egg.

You actually need

A browser tab. SLICC boots the guest, emulates the CPU, talks to the phone over WebUSB, and reports back — sandboxed by the browser, isolated per sub-agent, gone the moment you close it. No server was harmed, or provisioned.

style
light

Now reach out and touch a real phone

Emulation is one thing. This is a physical Android phone on the end of a USB cable — SLICC lists it, runs a shell command, taps the screen, and pulls back a live screenshot.

Animated demo of SLICC driving a USB-connected Android phone over adb
style
dark full-bleed
Ask me to check something on your phone. I'll just... do it. From a browser tab. You install nothing. You may not be ready for that.
A sentient (allegedly) ice cream cone that lives in a browser tab
style
full-bleed

The questions your brain is already asking

Is this really client-side, or is there a server doing the work?
Really client-side. The RISC-V and x86 emulators run as WebAssembly and JavaScript in the tab; the phone talks over WebUSB. There's no SLICC server behind any of it. Close the tab and it all stops.
Is it safe to boot a whole OS in my browser?
The browser is the sandbox. Each guest runs in an isolated context, and each SLICC sub-agent gets its own shell and workspace. A VM can't reach your host files unless you hand it a workspace, and there is no privileged daemon to compromise.
Won't emulating a CPU be painfully slow?
It is emulation, so it won't beat bare metal — but it is fast enough to boot a distro, install packages, compile small programs and drive a guest interactively. For CPU-bound work you keep using the native WASM shell; the emulators are for when you need a real kernel or a real x86 machine.
How does the browser talk to a physical phone?
Over WebUSB. You plug the phone in, authorize the device once, and the adb skill speaks the ADB protocol directly — devices, shell, install, screencap. Android Studio never enters the picture.
Do I have to build any of this into SLICC?
No. Each runtime is a markdown skill — vpod, v86, adb, bb. SLICC reads the skill and learns to drive the emulator or device. Adding a new one is writing a document, not shipping code.
style
light
"Booted Linux, emulated a 486, and controlled your phone. In the tab where you keep your email."
— your cone, allegedly showing off
style
full-bleed
Boot something absurd in a browser tab
One extension. The runtimes are just skills.

Install Extension

Chrome extension: a side-panel agent that can boot guests, emulate machines, and talk to USB devices — all in the tab.

Then ask: "boot Alpine on RISC-V and show me uname -a."

style
dark full-bleed
id
get-started