I ported a macOS-only AI agent tool to Windows — here's what I learned

The7thFreedom — Thu, 04 Jun 2026 14:50:08 +0000

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?

Hello DEV! Windows dev here, just ported a macOS-only AI tool to Windows 👋

The7thFreedom — Thu, 04 Jun 2026 14:46:13 +0000

Hey everyone!

Just joined DEV and wanted to say hi.

I'm a Windows developer who spends most of his time building
with AI coding agents — Claude Code, Codex, that kind of thing.

Recently got frustrated that Superset (a great tool for
orchestrating AI agents across git worktrees) was macOS-only,
so I did what any slightly-too-stubborn Windows dev would do:
I ported it myself.

The project is called SuperWin — still early, build-from-source
only for now, but it runs well on Win10/11.

Looking forward to being part of this community. If you're into
AI-assisted development, agent workflows, or just fellow Windows
devs tired of being second-class citizens — let's connect 👇

What are you all building these days?

DEV Community: The7thFreedom