Forem: wong2 kim

wmux: Run Claude Code, Codex, and Gemini CLI Side by Side on Windows

wong2 kim — Mon, 20 Apr 2026 13:09:05 +0000

TL;DR

If you're coding on Windows and juggling multiple AI CLI agents in a single terminal window — stop. wmux is a native Windows terminal multiplexer that lets you run Claude Code, Codex, and Gemini CLI side by side, with built-in browser automation, an MCP server, and real session persistence. No WSL required.

winget install openwong2kim.wmux

That's it. 30 seconds and you're done.

The problem

macOS devs have had cmux — a tmux-based terminal multiplexer tuned for AI agents — for a while now. Windows devs? We've been stuck with a single terminal tab, Alt+Tabbing between agents, spamming "are you done yet?" into the void.

You could use WSL, sure. But then your PowerShell scripts, Windows-native toolchains, and ConPTY-aware TUIs (hi, Claude Code) start to feel awkward.

wmux fills that gap. It's a native Windows multiplexer built on ConPTY, xterm.js with WebGL rendering, and Electron. No VM, no Linux emulation, no weird path translation.

What it actually feels like

Picture this layout on one screen:

Left pane: Claude Code writing your backend
Right pane: Codex scaffolding the frontend
Bottom pane: Gemini CLI running the test suite
Floating pane: A Quake-style dropdown terminal for quick git status checks

Ctrl+D splits right. Ctrl+Shift+D splits down. Ctrl+N opens a new workspace. Ctrl+1~9 jumps between them. Ctrl+click stitches multiple workspaces into a multiview grid. If you're a tmux person, Ctrl+B gives you a prefix mode with 13 rebindable actions.

The part that actually sold me: browser control

Tell Claude Code "search Google for wmux" and it actually does it. Not via shelling out to curl. Not by pretending. wmux exposes a built-in browser panel connected over the Chrome DevTools Protocol, and the MCP server exposes tools like:

What Claude does	MCP tool
Open browser	`browser_open`
Read page structure	`browser_snapshot`
Click element	`browser_click`
Fill form	`browser_fill` / `browser_type`
Press key	`browser_press_key`
Run JS	`browser_evaluate`
Screenshot	`browser_screenshot`

So a prompt like "search for wmux on Google" becomes:

browser_open → browser_snapshot → browser_fill(ref=13, "wmux") → browser_press_key("Enter")

And it works. Even with React controlled inputs and CJK text — both of which love to break naive automation.

Every browser tool accepts a surfaceId, so each Claude Code session drives its own browser. Run three agents, get three browsers, zero cross-talk.

Agent-to-agent messaging

This is the fun one. wmux exposes a2a_send, a2a_broadcast, a2a_task_send, and friends. Your Claude Code instance on the left can literally ping your Codex instance on the right:

"Hey, I changed the API response shape, regenerate the TypeScript types."

That's not a demo — that's Tuesday.

Stop babysitting your agents

wmux watches terminal output throughput (not brittle pattern matching) and fires desktop notifications + taskbar flashes when:

A task finishes
A process exits abnormally
A dangerous command shows up (git push --force, rm -rf, DROP TABLE…)

Go make coffee. wmux will tell you when to come back.

Session persistence that actually persists

Close wmux. Reopen it. Your sessions are still there, 999K lines of scrollback intact, in the right working directory.

Reboot your machine. Same thing. A background daemon keeps PTY processes alive, dumps scrollback to disk, and auto-starts on login.

This is the part tmux users have been quietly missing on Windows for years.

Security I didn't have to ask for

Token auth on every IPC pipe
SSRF protection (blocks private IPs, file://, javascript:)
PTY input sanitization
Randomized CDP port (no fixed --remote-debugging-port=9222 for anyone to hijack)
Memory pressure watchdog (reaps dead sessions at 750MB, blocks new ones at 1GB)
Electron Fuses locked down (RunAsNode disabled, cookie encryption on)

For a tool that hands AI agents a browser and a shell, this is the bare minimum — and wmux actually does it.

The rest of the goodies

xterm.js + WebGL GPU rendering
Unicode 11 width tables (CJK/emoji actually render correctly in TUIs)
Shell integration via OSC 133 — terminal_read_events gives agents semantic command boundaries, not raw bytes
Regex search (Ctrl+F), Vi copy mode (Ctrl+Shift+X), scroll bookmarks (Ctrl+M)
Smart right-click: selection → copy, empty area → paste, link → Open/Copy menu
Layout templates you can save and restore from the command palette
Themes: Catppuccin Mocha, Monochrome, Sandstone
i18n: English, Korean, Japanese, Chinese
Auto-update via GitHub Releases

Agent detection covers Claude Code, Cursor, Aider, Codex CLI, Gemini CLI, OpenCode, and GitHub Copilot CLI out of the box.

Install

Pick your poison:

# winget (recommended)
winget install openwong2kim.wmux

# Chocolatey
choco install wmux

# PowerShell one-liner
irm https://raw.githubusercontent.com/openwong2kim/wmux/main/install.ps1 | iex

Or grab wmux Setup.exe from the releases page.

Final thought

Windows devs have been the second-class citizens of the AI coding agent world for a minute. wmux doesn't fix everything — but running three agents on one screen, each with its own browser, talking to each other, surviving reboots? That's a genuinely different workflow.

Repo: github.com/openwong2kim/wmux — MIT licensed.

If you try it, I'd love to hear which layout you end up with. Mine is Claude-left / Codex-right / Gemini-bottom, and a floating terminal for git. What's yours?

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

wong2 kim — Wed, 25 Mar 2026 14:33:56 +0000

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

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.

From Engineering Floor to App Store: What 10 Years as a Manufacturing Engineer Taught Me About Building Software

wong2 kim — Tue, 24 Mar 2026 03:37:45 +0000

No CS degree. No bootcamp. Just 10 years on factory floors and a stubborn belief that the software I needed should actually exist.

Here's how AI tools helped me make the jump — and 5 lessons from manufacturing that turned out to be my biggest advantage.

From Factory Floors to the App Store

I spent a decade in manufacturing engineering. Process optimization, quality control, equipment troubleshooting — the kind of work where every minute of downtime costs real money.

The whole time, I had one recurring frustration: the software tools I needed were terrible. Clunky tracking systems. Overpriced dashboards. Apps that felt like they were designed by people who had never touched a production line.

So I tried to learn to code. Multiple times. Tutorials, online courses, side projects. Every attempt hit the same wall — not because I couldn't think logically, but because the jump from "hello world" to a working product felt impossibly wide.

Then AI coding tools changed everything.

Why AI Was the Missing Piece

AI didn't teach me computer science. It did something better — it met me where I was.

Suddenly I could focus on what I was already good at:

Defining the problem clearly — engineering trained me for this
Breaking it into components — process engineering is literally this
Iterating fast — prototype, test, improve, repeat (factory mindset)

AI handled the syntax. I handled the thinking.

Within months, I shipped my first iOS app. Then another. And another.

What I'm Building Right Now

Pregnancy & Parenting App Suite — My wife and I couldn't find an app that wasn't riddled with ads or missing features. So I built one.
Enterprise AI Platform — RAG chatbot + auto-generated presentations for enterprise adoption. My manufacturing background directly applies here.
Markdown Note App — Notes for iOS with iCloud sync and on-device AI. Every note app was either too simple or too complex.
ADHD-Friendly Task Planner — Eisenhower Matrix meets Pomodoro timer. Built for brains that work differently.
AI Coding Terminal — Windows-native terminal with multi-agent control. The tool I wish I had when I started.

5 Lessons Manufacturing Taught Me About Software

1. Nobody cares about your architecture.

On the factory floor, nobody cares how elegant your process flow diagram is. They care if the product comes out right. Same with apps — solve the problem, and nobody asks if you used MVVM or MVC.

2. Ship first. Optimize later.

We had a saying: "Don't let perfect be the enemy of good enough for Tuesday's shipment." Get it working, get it in front of users, then iterate.

3. Constraints breed creativity.

Tight budgets. Broken equipment. Real deadlines. Manufacturing forces you to find creative solutions — and that's exactly what indie dev demands when you're the designer, developer, tester, and marketer all at once.

4. Ask "why" five times.

Toyota's "5 Whys" technique is the best debugging framework I've ever used. Don't fix the symptom. Keep digging until you find the root cause.

5. Domain knowledge is your superpower.

No CS grad knows what a manufacturing engineer needs from a monitoring tool. No bootcamp teaches what an expecting parent wants from a pregnancy app at 3 AM. Your non-tech experience isn't a weakness — it's the unfair advantage that helps you build things people actually want.

My Stack

Category	Tools
Mobile	Swift, SwiftUI
Web	React, Next.js, Tailwind CSS
AI/ML	Python, LangGraph, LLM APIs
Infra	Docker, Supabase, Local AI Server

The Honest Truth

AI didn't make me a software engineer. It made me a software builder.

I still don't know half of what a CS grad knows about algorithms. But I can identify a real problem, design a solution, and ship a product that people use. That's enough to build meaningful things.

If you're sitting on deep domain expertise in a non-tech field — healthcare, education, construction, whatever — the barriers have never been lower. You don't need a degree. You need a problem worth solving and the will to ship.

I'm new to DEV and writing about AI-assisted development from a non-CS perspective. If this resonates, I'd love to hear your story.

What did your "before" look like?