DEV Community

wong2 kim
wong2 kim

Posted on

I tried to vibe code on Windows. It broke me. So I built my own terminal.

Every AI coding setup I saw online looked the same: Mac, tmux, agents running in split panes, everything humming along perfectly.

I was on Windows. It did not hum.

The tmux wall

tmux is the backbone of serious AI agent workflows. Persistent sessions, split panes, detach and reattach while your agents keep running.

On Windows, native tmux doesn't exist.

Fine — I'll use WSL.

WSL: close enough to break everything

WSL feels like Linux. For about 20 minutes, you think you've solved the problem.

Then the path issues start.

Windows sees: C:\Users\wooyoung\projects\wmux
WSL sees: /mnt/c/Users/wooyoung/projects/wmux

Same folder. Completely different contexts. AI agents write files into WSL. Your Windows-side editor can't find them. Your git is on the Windows side. Your dev server is on the Windows side. Your agent is happily working in a parallel universe.

The worst part: it works — until it doesn't. You're 40 minutes into a session before realizing your agent has been operating in the wrong dimension the entire time.

Port forwarding breaks hot reload. The agent hits localhost:3000, gets nothing, concludes the code is broken, and starts "fixing" code that was never broken.

You end up debugging a WSL networking quirk disguised as a React error.

Multi-agent made it dramatically worse

One agent is manageable. But real vibe coding in 2025 means an orchestrator, subagents, parallel tasks.

My setup: 6 terminal windows, 3 WSL instances, no way to tell which agent was doing what. One agent had gone completely silent — was it done? Crashed? Thinking?

I kept a Notepad file open just to track which terminal was which.

Then one Tuesday evening, I had three agents running in parallel. I wanted to check on one of them. Found it after clicking through four windows. It had been waiting for my input for 45 minutes. The other two had moved on — and built conflicting code against each other.

I closed everything. Went to bed. The next morning I started writing a PRD for Wmux.

What I built

Wmux is a Windows-native AI agent terminal. The problems I kept hitting are treated as first-class design constraints, not edge cases.

No WSL dependency. One filesystem context. No boundary crossings, no silent failures from agents writing to the wrong place.

All agents in one view. Every session visible in a single window. Status, last output, whether it's waiting — at a glance. Ctrl+D to split, Ctrl+N for a new workspace.

Browser automation built in. Claude Code can open a browser, click, fill forms, take screenshots — all via CDP. Not a workaround. A first-class feature.

Notifications that actually work. Output throughput-based detection: when your agent finishes, you get a desktop notification. No more staring at a terminal wondering if it's done.

Session persistence. Close Wmux, reopen it — your sessions are still there, scrollback intact. Like tmux. On Windows.

Why this matters

The corporate world runs Windows. The non-CS engineers I'm trying to get into AI coding run Windows. The developers who are just now discovering multi-agent workflows — a lot of them are on Windows.

The tooling just hasn't caught up. Mac users have cmux. Windows users have... friction.

If you want real multi-agent AI coding on Windows today, you either accept constant pain, or you build the environment yourself.

I chose to build.

v2.2.0 is out. Install in 30 seconds:

irm https://raw.githubusercontent.com/openwong2kim/wmux/main/install.ps1 | iex
Enter fullscreen mode Exit fullscreen mode

Follow the build: github.com/openwong2kim/wmux


Previously: From engineering floor to App Store
Next: I deployed AI to 200 factory engineers. Here's what actually happened.

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.