Control Hub for Remote Operations & Tmux Execution
WARNING: This software was vibe-coded at 3am by mass hallucinations between a human and multiple AI agents. It works on my machine. It might work on yours. It probably won't. If it does, that's the miracle - not the expectation.
CAUTION: If you have to ask "is this safe?" - turn back now. This is the wasteland. We don't do safe here. We do fast, loud, and pray the tests pass. I asked the three wise men of the West - Gemini, Claude, and ChatGPT - and they said it's fine. Maybe I should consult the three wise men of the East next.
CHROTE is your own personal tmux cloud - a web dashboard that lets you run AI coding agent swarms from anywhere, on any device.
The pitch: You're sitting on the can in the morning dictating all that cool shit you dreamt about last night to get your agents working. You close your laptop lid and the agents keep working. You open a different machine and pick up exactly where you left off. Your tmux sessions live in the cloud (your cloud, on your hardware), accessible via Tailscale from anywhere in the world.
The experience: Best of both worlds. You get the raw power of terminal interfaces - tmux, Claude Code, the command line. And you get a modern web dashboard on top - drag-and-drop session management, visual monitoring, theme customization, ambient music. Terminal purists and GUI lovers, united at last.
You know how normal people run one Claude Code instance and carefully review each change?
We don't do that here.
Here, we spin up 10, 20, 30 agents. We point them at problems. We watch the chaos unfold through terminal windows. Sometimes they solve the problem. Sometimes they fight each other. Sometimes they all independently decide to refactor the same file and create merge conflicts that would make God weep.
This is NOT for you if:
- You've never used Claude Code
- You think "vibe coding" sounds irresponsible
- You have a budget
- You need things to work reliably
- You value your sanity
This IS for you if:
- You're already mass-prompting Claude Code instances in a dozen terminal tabs
- You've accepted that AI will write most of your code and you're just here to steer
- You understand that "it works on my machine" is a lifestyle
- You have more API credits than sense
- You want to feel like a mad scientist running a robot army
You know what's harder than herding cats? Herding AI agents. They're off doing their thing, buried in tmux sessions, and you need to tell them something. Or ask them something. Or just poke them to make sure they're still alive.
ChroteChat is somewhat functional, janky as hell and now rendered a little pointless. I recommend instead setting up Clawdbot in the same backend as CHROTE. It will be very easy to set up and you can then have Clawdbot control the CHROTE sessions for you. This is a really powerful flow and I cannot recommend it enough.
| Tab | What It Does |
|---|---|
| ChroteChat | Message your agents directly (mail + nudge + channels) |
| Terminal 1 & 2 | Dual terminal workspaces, 4 panes each |
| Files | Native file browser for /code and /vault |
| Beads | Issue tracking with Kanban/Triage/Insights + filtered views |
| Settings | Theme, font size, tmux appearance |
| Help | Keyboard shortcuts and documentation |
- 1-4 terminal panes per tab (two tabs = 8 total windows)
- Drag sessions from sidebar onto windows
- Click tabs to switch between assigned sessions
- Each empty window shows its guardian - placeholder artwork you get to look at for exactly three seconds before burying it under a tmux session. It's there. Then it's not. Like a wasteland Polaroid.
CHROTE works on phones and tablets too. The recent mobile revamp includes:
- Responsive layout - Top bar collapses to hamburger menu, terminal view adapts to narrow screens
- Touch-friendly targets - Session list items are sized for fingers, not mouse precision
- Long-press context menus - Hold on a session to get the context menu on mobile
- Collapsible sidebar - Auto-collapses on narrow screens, manually toggle as needed
- Improved input layout - Chat input area adapts to mobile keyboards
You can dictate code changes while jogging and monitor your agent swarm from the couch. The wasteland is mobile-first now.
Fair warning: ChroteChat on mobile is held together with duct tape and prayers. It works, mostly, but expect rough edges - layout glitches, keyboard weirdness, the occasional existential crisis. We're aware. We'll fix it. For now, it's "works on my phone" territory.
Access your project files directly through the dashboard with the native file browser:
Customize your workspace with multiple built-in themes:
See that "Nuke All Sessions" button?
It does exactly what it says. All sessions. Gone. Instantly.
Use it liberally. This is the wasteland. Attachment is weakness. If your agents are stuck in loops, arguing with themselves, or have collectively decided to rewrite your codebase in Haskell - nuke them. Start over. You'll feel better.
| Prefix | Example | What It Means |
|---|---|---|
hq- |
hq-mayor |
Headquarters - coordination sessions |
gt-rigname- |
gt-gastown-jack |
Rig workers - the agents doing actual work |
main, shell |
main |
Your personal sessions |
| Other | chaos-monkey |
Whatever you want, we don't judge |
Every terminal window in CHROTE has a guardian - a wasteland operator watching over your agents. They don't actually do anything. They're just... there. Staring. Judging your tmux sessions with silent, pixel-based disapproval. Think of them as the dashboard's emotional support animals, except they're cyberpunk rodents who've seen some shit and have zero therapeutic credentials.
Fun fact: 50% of CHROTE's development time was spent trying to make tmux sessions transparent so you could see the guardians while working. Turns out that's a mirage on the Fury Road - xterm.js doesn't do transparency, terminal emulators are a stack of ancient curses, and the guardians were never meant to be seen for more than three seconds anyway. They're watching you. You're not supposed to watch them back.
Meet them:
 POLECAT The Mechanic V8 engine heart. Keeps the rigs running when everything's on fire. |
 FOX The Strategist Monocle and military precision. Plans the operations others execute. |
 BADGER The Engineer Welding goggles and steady hands. Builds what Fox designs. |
 WOLF The Enforcer Hooded and chained. When sessions need killing, Wolf answers. |
 CREW The Technician Wrench in hand, plasma flowing. Keeps the terminals alive. |
 CONVOY The Transport The war rig itself. Carries your workloads across the wasteland. |
 HAWK The Architect Cloaked scholar. Reads the ancient docs. Guides the workers. |
 TOWN The Settlement CHROTE itself. The glowing hub where all roads lead. |
Every wasteland operation needs its anthem. The official CHROTE soundtrack - genre-defying chaos for coding robots:
Listen to that shit. You might learn something. The lyrics explain you Gastown and Tmux.
Built-in tracks (yes, we ship MP3s with the codebase - this is the wasteland, might as well have some tunes while you watch a stream of errors). These are their own can of worms - separate from the playlist above. Instrumental. Ambient. The kind of music that makes you feel like you're running a dystopian control room at 2am. Which you are.
- Design_phase - When the architects are scheming
- Who_ate_my_PRD - The eternal question
- Vibes_at_the_hq - Command center ambience
- Mayors_introspection - Deep thoughts from the control room
- The_idle_Polecat - When the mechanic takes a smoke break
- Polecat_Danceparty - V8 engine rhythms
- Deacons_revenge - Things got personal
- MergePush - The moment of truth
- March_of_the_Polecats - When the crew mobilizes
- Convoy_Run - Full throttle across the wasteland
Access the music player in the dashboard tab bar. Let it play while your agents "work". They can't hear it, but you'll feel better.
- Windows 11 with WSL2
- Ubuntu 24.04 in WSL
- Tailscale account (recommended for remote access)
Two commands. That's it.
# 1. Install Ubuntu in WSL (skip if you already have it)
wsl --install -d Ubuntu-24.04
# 2. Run setup from the CHROTE directory
cd C:\path\to\CHROTE # wherever you cloned/extracted it
.\Chrote-Toggle.ps1 -SetupThe -Setup flag auto-detects your Ubuntu distro and handles CRLF line endings automatically. No sudo needed. No password prompts. Just run and walk away.
Manual alternative (if PowerShell isn't your thing):
wsl -d Ubuntu-24.04 -u root -e bash -c "tr -d '\r' < /mnt/c/path/to/CHROTE/wsl/setup-wsl.sh | bash"ZIP Download Users: If you downloaded this as a ZIP (not via Git), Windows may have added CRLF line endings to the scripts. Both methods above handle this automatically by stripping CRLF before execution. You can also use
wsl/bootstrap.shas an alternative entry point.
Mac users: CHROTE is Windows-native. The core concepts translate to macOS - you've got native Linux capabilities, you've got tmux, you just need to wire up the services differently. PRs welcome.
Path flexibility: The setup script automatically detects where CHROTE is located. Clone it anywhere you want -
C:\Users\you\CHROTE,D:\Projects\CHROTE, wherever. Just run.\Chrote-Toggle.ps1 -Setupfrom that directory.
Note: Current gastown is a unstable and you will have to struggle with it to get it working. You can also use other setups or look for a stable fork. I might add one later as well. There is built in support for a vendored version in Chrote install.
The setup script (wsl/setup-wsl.sh) handles everything:
| Component | What It Does |
|---|---|
| WSL Config | Enables systemd, sets default user to chrote |
| chrote user | Non-root user for running agents (no sudo access) |
| Dependencies | curl, git, tmux, python3, jq, rsync, build-essential |
| Go 1.23 | For building the server and tools |
| Node.js 20 | For building the dashboard |
| ttyd | Web terminal backend |
| Claude Code | Anthropic's CLI (via npm) |
| CHROTE Server | Go binary serving the dashboard |
| Gastown | Downloaded and built from GitHub during setup |
| Beads | Downloaded and built from GitHub during setup |
| Beads Viewer | Downloaded and built from GitHub during setup |
| systemd Services | chrote-server and chrote-ttyd auto-start on boot |
After installation, the following paths are available inside WSL:
| Path | Purpose |
|---|---|
/code |
Symlink to ~/chrote (your working directory) |
/vault |
Symlink to E:\Vault (optional, for read-only storage) |
~/chrote/vendor/gastown/gt |
Gastown orchestrator (vendored) |
~/chrote/vendor/gastown/bd |
Beads issue tracker (vendored) |
~/chrote/vendor/gastown/bv |
Beads viewer (vendored) |
When new versions drop, here's how to update each component:
Claude Code (npm global package):
# Check current version
claude --version
# Update to latest
sudo npm update -g @anthropic-ai/claude-code
# Or install specific version
sudo npm install -g @anthropic-ai/claude-code@latestGastown Tools (gt, bd, bv) - download from GitHub releases:
| Tool | Repository |
|---|---|
| gt | github.com/steveyegge/gastown/releases |
| bd | github.com/beads-ai/beads/releases |
| bv | github.com/beads-ai/beads-viewer/releases |
# Example: Update gt to version X.Y.Z
cd /tmp
curl -LO https://github.com/steveyegge/gastown/releases/download/vX.Y.Z/gt_X.Y.Z_linux_amd64.tar.gz
tar -xzf gt_X.Y.Z_linux_amd64.tar.gz
cp gt ~/chrote/vendor/gastown/gt
# Restart service to pick up PATH changes
sudo systemctl restart chrote-server
# Verify
gt --versionThe chrote-server service has vendor/gastown in its PATH, so tools placed there are available to the server and any sessions it spawns.
# The toggle script - your daily driver
.\Chrote-Toggle.ps1 # Start and open browser
.\Chrote-Toggle.ps1 -Setup # Run first-time setup
.\Chrote-Toggle.ps1 -Stop # Kill everything
.\Chrote-Toggle.ps1 -Status # Check if anything's alive
.\Chrote-Toggle.ps1 -Logs # Watch the logsAfter setup completes and WSL restarts:
# Check if services are running
.\Chrote-Toggle.ps1 -Status
# You should see:
# WSL: Running
# chrote-server: active (running)
# chrote-ttyd: active (running)
# API: OKIf something's wrong:
# Check the logs
.\Chrote-Toggle.ps1 -LogsOnce the rig is running:
| Outpost | Location | Purpose |
|---|---|---|
| Command Center | http://localhost:8080 |
Main dashboard (local access) |
| Command Center | http://chrote:8080 |
Main dashboard (via Tailscale) |
| Direct Terminal | http://localhost:8080/terminal/ |
Raw ttyd access |
| File Depot | http://localhost:8080/api/files/ |
File API |
Note:
http://chrote:8080requires Tailscale configured on your WSL instance. For initial testing, usehttp://localhost:8080which works immediately.
For remote access from other devices:
# Inside WSL
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --hostname chroteThen access from any device on your Tailnet via http://chrote:8080.
CHROTE was built with Gastown in mind - Steve Yegge's orchestration framework for running 10-30+ AI coding agents in parallel. But CHROTE is a platform, not a Gastown dependency. You can run anything that needs tmux sessions - other agent frameworks, manual Claude Code instances, or your own tooling.
CHROTE includes a built-in Operators Manual (Help tab) with documentation for both CHROTE itself and Gastown workflows. If you're new to agent swarms, start there.
┌─────────────────────────────────────────────────────────────────────┐
│ Tailscale Network │
│ (Network-level access control) │
└───────────────────────────────────────────────────────────────────┬──┘
│
┌───────────────────────────────────────────────▼──────────────────────────────┐
│ WSL2 (Ubuntu 24.04) │
│ User: chrote (no sudo, sandboxed to /code and /vault) │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ systemd services │ │
│ │ ┌─────────────────────────┐ ┌─────────────────────────┐ │ │
│ │ │ chrote-server :8080 │ │ chrote-ttyd :7681 │ │ │
│ │ │ (Go binary - dashboard │ │ (web terminal access) │ │ │
│ │ │ and API server) │ │ │ │ │
│ │ └─────────────────────────┘ └─────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ Tailscale hostname: chrote │
└──────────────────────────────────────────────────────────────────────────────┘
Why WSL2 instead of Docker?
We tried Docker first. The layers of indirection made debugging harder than it needed to be. WSL2 gives us real Linux with real systemd and better performance for this use case.
CHROTE is two programs welded together into one binary. Understanding this helps when things break.
┌──────────────────────────────────────────────────────────────────┐
│ BUILD TIME │
│ │
│ dashboard/src/*.tsx ──[npm run build]──► dashboard/dist/ │
│ (React + TypeScript) (HTML, CSS, JS) │
│ │
│ │ │
│ ▼ copy │
│ │
│ src/internal/dashboard/dist/ │
│ │ │
│ ▼ go:embed │
│ │
│ src/**/*.go ──────[go build]─────────► chrote-server │
│ (Go backend) (single binary) │
│ dashboard inside │
└──────────────────────────────────────────────────────────────────┘
Stage 1 - Build the dashboard:
cd dashboard && npm run buildVite compiles React and TypeScript into plain HTML, CSS, and JavaScript. Output lands in dashboard/dist/.
Stage 2 - Copy into Go's territory:
cp -r dashboard/dist/* src/internal/dashboard/dist/Stage 3 - Build the server:
cd src && go build -o ../chrote-server ./cmd/serverThe magic is //go:embed dist/* in the Go code. This tells the compiler: "Take everything in that folder and bake it into the binary." The resulting chrote-server file contains the entire dashboard - no external files needed. One binary rules them all.
At runtime, chrote-server handles all traffic on port 8080:
| Path | What Happens |
|---|---|
/ |
Serves embedded dashboard (React app) |
/api/* |
JSON APIs - talks to tmux, filesystem, beads |
/terminal/* |
WebSocket proxy to ttyd for live terminals |
No nginx. No reverse proxy. No "which service handles what" confusion. One process, one port.
Same server, different doors:
| URL | How You Get There | When To Use |
|---|---|---|
localhost:8080 |
Direct connection on same machine | Local dev, initial testing |
chrote:8080 |
Tailscale resolves hostname to your WSL's IP | Remote access from anywhere |
Your laptop (coffee shop wifi)
│
│ "http://chrote:8080"
▼
Tailscale network (encrypted tunnel across the internet)
│
▼
Your home server (WSL2)
│
▼
chrote-server listening on :8080
Tailscale makes your WSL instance reachable by the hostname chrote from anywhere in the world - but only on your private network. Same server, same code, just a longer wire.
Production - dashboard baked into binary:
systemctl start chrote-server
# Access at localhost:8080 or chrote:8080Development - live reload while hacking:
cd dashboard
npm run dev # Vite dev server on :5173Change a file, browser updates instantly. When you're done, rebuild and restart:
npm run build
cp -r dist/* ../src/internal/dashboard/dist/
cd ../src && go build -o ../chrote-server ./cmd/server
sudo systemctl restart chrote-serverWe're reckless, not stupid. The wasteland has walls.
| Layer | What It Does |
|---|---|
| User isolation | All agents run as chrote user - a dedicated non-root account with no sudo access. They can't escalate privileges, install system packages, or touch anything outside their sandbox. |
| File sandboxing | The file API only allows access to /code and /vault. Path traversal attacks are blocked and logged. Agents can't read your SSH keys, browser history, or that folder you don't talk about. |
| Network perimeter | Tailscale provides the access boundary. No authentication on the dashboard itself - if you're on the Tailnet, you're in. |
For the paranoid (which you should be), configure your Tailscale ACLs to restrict the CHROTE machine:
This way, even if an agent goes rogue, it can't pivot to your other machines. The wasteland stays contained.
IMPORTANT: Do not expose port 8080 to the public internet. The dashboard has no authentication. Use Tailscale for remote access or keep it localhost-only.
See SECURITY.md for the full security model.
Quick fixes for common issues. For the full troubleshooting guide, see docs/troubleshooting.md.
CHROTE has two ways to run the dashboard:
| Mode | URL | What It Means |
|---|---|---|
| Development | localhost:5173 |
Vite dev server - changes apply instantly |
| Production | localhost:8080 |
Go binary - changes require rebuild + restart |
If you make a change and nothing happens: Check which URL you're using. If you're on :5173, rebuilding the Go binary does nothing. If you're on :8080, you must rebuild AND restart.
# Check service status
systemctl status chrote-server chrote-ttyd
# View logs
journalctl -u chrote-server -f
# Restart services
sudo systemctl restart chrote-server chrote-ttyd
# Nuclear option: full WSL reset
wsl --shutdown # From Windows PowerShell
.\Chrote-Toggle.ps1Copy one of these prompts to get AI assistance:
Installation Help Prompt
I need help installing CHROTE. Please read the installation guide at docs/installation.md and help me through the process.
My environment:
- Windows version: [your version]
- WSL status: [installed/not installed]
- Current step: [where you're stuck]
- Error message: [paste any errors]
Guide me through the installation step by step, explaining what each command does before I run it.
Troubleshooting Help Prompt
I'm having an issue with CHROTE. Please read docs/troubleshooting.md to understand the system, then help me debug.
CRITICAL: First ask me whether I'm viewing localhost:5173 (dev mode) or localhost:8080 (production mode) - this determines what fixes apply.
My issue:
- What's happening: [describe the problem]
- What I expected: [what should happen]
- What I tried: [any fixes you attempted]
- Error messages: [paste from browser console or terminal]
Don't assume "rebuild and restart" fixes everything. Diagnose which mode I'm in first.
Setup copies your files into WSL. Here's where everything lives:
| What | Where |
|---|---|
| Windows source | E:\Docker\CHROTE (or wherever you cloned it) |
| WSL working copy | /home/chrote/chrote (aka /code) |
| Windows path to WSL | \\wsl$\Ubuntu-24.04\home\chrote\chrote |
Edit directly in WSL from Windows - open \\wsl$\Ubuntu-24.04\home\chrote\chrote in Explorer or VS Code. Changes are immediate, no sync needed.
Or use VS Code's WSL extension:
- Install "WSL" extension
Ctrl+Shift+P→ "WSL: Connect to WSL"- Open folder
/home/chrote/chrote
# Enter WSL
wsl
# You're now in /code as chrote user
# Edit files, then rebuild:
# Dashboard only (React + TypeScript)
cd dashboard
npm run build
cp -r dist/* ../src/internal/dashboard/
sudo systemctl restart chrote-server
# For live development with hot reload
npm run dev # localhost:5173cd /code/dashboard
npm run testCHROTE/
├── src/ # Go server
├── dashboard/ # React UI
│ └── public/ # Guardian images live here
├── wsl/ # WSL setup scripts
├── vendor/ # Gastown, Beads (optional)
├── docs/ # Documentation
└── test-sessions.sh # Creates fake sessions for testing
Tmux sessions shouldn't be trapped on one machine.
The whole point of CHROTE is liberation. Your agents run on a beefy home server. You connect from your laptop, your phone, your tablet, your work machine. You dictate changes while walking. You check progress from the couch. You close the lid and the work continues. The sessions are always there, always running, always accessible.
Terminal power, web convenience.
We didn't build this to replace tmux. We built it to make tmux accessible from everywhere, with a modern UI layer that doesn't get in the way. Drag a session to a window. Click to peek. Nuke everything when it goes sideways. The dashboard serves the terminal, not the other way around.
Sandboxed chaos.
Yes, we run 30 agents in parallel. Yes, they fight each other. Yes, merge conflicts happen. But they're sandboxed - no sudo, no system access, no network pivoting. The chrote user is a padded cell where agents can thrash around without hurting anything that matters.
Is this the right approach for everyone? Absolutely not. Is it useful for power users who want to vibe code from anywhere? We think so.
| Document | What It Is |
|---|---|
| docs/installation.md | Detailed installation guide |
| docs/troubleshooting.md | Common issues and solutions |
| PRD.md | Product requirements |
| SPEC.md | Technical specification |
| SECURITY.md | Security model |
MIT - Open source for the community.
CHROTE stands on the shoulders of giants (and some very caffeinated developers):
| Project | Creator | What It Does |
|---|---|---|
| Gastown | Steve Yegge | The orchestration framework that makes running 30 AI agents feel almost sane. CHROTE is just the garage - Gastown is the war rig. |
| Beads | Steve Yegge | Atomic units of work for AI agents. The issue tracking system that actually understands what agents are doing. |
| Beads Viewer | Dicklesworthstone | Beautiful visualization for beads data. Makes the chaos comprehensible. |
Special thanks to the Gastown community for pioneering the art of AI agent swarm management.
"I live, I die, I live again!"
- Every tmux session, probably