I've been experimenting with multi-agent coding workflows for a
while now — running Claude Code, Codex, and Cursor in parallel,
each agent working on its own isolated branch. It's a genuinely
different way to develop once you get it working.
The best tool I found for orchestrating this is
Superset by superset-sh. It lets you spin
up multiple CLI-based coding agents across isolated git worktrees,
direct their work from a single interface, and merge results when
done. Clean, fast, well-built.
One problem: macOS only.
I'm on Windows. So I did what any mildly stubborn developer would
do — I ported it.
What Superset actually does
Before getting into the port, it's worth explaining why I thought
it was worth the effort.
The core idea is parallel agent execution across git worktrees.
Instead of:
You → one agent → one branch → wait → review → repeat
You get:
You → agent A (feature-1 worktree)
→ agent B (feature-2 worktree)
→ agent C (bugfix worktree)
→ all running simultaneously
Each agent has its own working directory, its own branch, no
shared state. You review and merge when ready. For the right
kind of tasks, it's a significant productivity shift.
Why the Windows port was non-trivial
This wasn't a simple config change. A few things needed real work:
1. Terminal: macOS pty → Windows ConPTY
The original uses node-pty, which works great on macOS/Linux but
has historically been painful on Windows. I switched to
Windows ConPTY — the modern Windows pseudo-terminal API
that's been available since Windows 10 1809.
// macOS: node-pty
const pty = spawn('bash', [], {
name: 'xterm-color',
env: process.env
})
// Windows: ConPTY via node-pty with Windows-specific flags
const pty = spawn('powershell.exe', [], {
name: 'xterm-color',
useConpty: true,
env: process.env
})
ConPTY is solid now. The main gotcha is that some ANSI escape
sequences behave slightly differently — took some time to
normalize the output rendering.
2. File paths: backslashes everywhere
Windows uses backslashes. The codebase assumed forward slashes
throughout — in worktree paths, git commands, config files,
log output, everything.
The fix wasn't hard but it was tedious: normalize all internal
paths to forward slashes, then convert at the system boundary
only when actually calling Windows APIs.
// Normalize on input
const normalize = (p: string) => p.replace(/\\/g, '/')
// Convert back only when calling Windows shell
const toWin32 = (p: string) => p.replace(/\//g, '\\')
3. Shell integration: PowerShell / cmd / WSL
On macOS, you assume bash or zsh. On Windows, you need to handle:
- PowerShell 7+ (recommended)
- cmd.exe (legacy fallback)
- WSL (Linux environment on Windows)
Each has different ways to set environment variables, run
scripts, and handle exit codes. I ended up with a shell adapter
layer that normalizes the interface across all three.
4. Build pipeline: dmg → nsis/msi
The upstream build targets macOS .dmg. For Windows I switched
the Electron-builder config to target:
-
NSIS installer (
.exe) — standard Windows installer with install/uninstall support - MSI — for enterprise environments
// electron-builder.ts (Windows targets)
win: {
target: [
{ target: 'nsis', arch: ['x64'] },
{ target: 'msi', arch: ['x64'] }
]
}
5. Keyboard shortcuts: ⌘ → Ctrl
Every keyboard shortcut in the UI used macOS modifiers. Went
through the entire shortcut map and remapped:
-
⌘→Ctrl -
⌥→Alt -
⌘⇧→Ctrl+Shift
Small thing, but important for it to feel native on Windows.
What I notified upstream
I opened an issue with the superset-sh team
(superset-sh/superset#5011)
to let them know about the port. SuperWin maintains the same
Elastic License 2.0 as upstream and aims to stay rebased
on upstream main.
This is an unofficial community port — not affiliated with or
endorsed by the superset-sh team. If they ever ship an official
Windows build, great. Until then, SuperWin exists.
Current state
- ✅ Runs on Windows 10 (1809+) and Windows 11
- ✅ PowerShell / cmd / WSL support
- ✅ Claude Code, Codex, Cursor orchestration working
- ✅ Isolated git worktree management
- ⏳ No prebuilt installer yet — build from source for now
- ⏳ Installer coming in a future release
Requirements:
- Bun v1.0+ for Windows
- Git for Windows 2.40+
- PowerShell 7+ (recommended)
Try it
git clone https://github.com/the7thfreedom/superwin.git
cd superwin
Copy-Item .env.example .env
bun install
bun run dev
GitHub: the7thfreedom/superwin
What I'd do differently
If I were starting over:
- Start with ConPTY from day one — I spent too long trying to make node-pty work before switching
- Path normalization layer first — add it as a utility module before touching anything else
- Test on WSL earlier — WSL path handling is its own category of edge cases
If you're a Windows developer doing AI-assisted coding and
have been watching the agent orchestration space from the
sidelines — this is your on-ramp.
Questions, feedback, bug reports all welcome. What's your
current AI coding workflow on Windows?
Top comments (1)
Happy to answer questions about the ConPTY integration or any Windows-specific edge cases — that part alone took longer than expected. Also open to contributions if anyone wants to help push toward a proper installer.