I sell Claude Code orchestration templates — agents, skills, and hooks that turn Claude Code into a multi-agent dev team. A few weeks ago, I started building CC Desktop: a GUI wrapper so people who aren't comfortable with the terminal could use Claude Code too.
A few days in, I killed the project. Not because it didn't work — it did. I killed it because I found a problem that couldn't be solved with more code.
Why I tried
Claude Code runs in the terminal. That's fine for developers, but there's a whole audience — designers, PMs, small business owners — who'd benefit from it but won't touch a CLI.
The plan: a desktop app (Tauri + React) that wraps claude -p in a chat interface. Pick a folder, type a message, get work done. No terminal.
What I actually shipped
In about 3 days, CC Desktop reached a working state:
- Tauri v2 + React 19 + TypeScript — cross-platform desktop app
- Chat UI with markdown rendering, syntax highlighting, code copy
- Project management — open folders, create new projects, recent projects list
- Auto-discovery — scans
.claude/agents/and.claude/skills/in any project and shows them in a sidebar - Slash command palette — type
/and see available skills from the project - Permission dialog — approve or deny tool calls from Claude
- Auto-approve toggle — let Claude work freely without asking
- Onboarding wizard — 4-step setup for first-time users
- i18n — Korean and English
- Light/dark theme
It worked. You could open a folder, chat with Claude, and it would edit your files. Skills showed up automatically in the sidebar.
The wall: subprocess architecture
Here's the thing about wrapping a CLI — you're spawning a child process. That's the only option. There's no library, no SDK, no engine you can embed. claude -p is it.
This creates a fundamental resource problem:
- Each
claudeprocess uses ~300MB RAM (GitHub #11122) - Running CC Desktop alongside terminal Claude Code = two processes fighting for CPU
- MCP server port conflicts when multiple instances run
- Each subprocess re-injects ~50K tokens per turn for global config
- OOM kills reported by multiple users running parallel instances
This isn't a bug to fix. It's a platform constraint. The Claude Code engine is private. Third-party tools can only use the CLI, which means subprocess overhead is unavoidable. Anthropic's own Claude Code Desktop embeds the engine natively — no subprocess, no overhead. That's an advantage third parties literally cannot replicate.
No amount of optimization on my side would change this. The performance ceiling is set by the platform, not by the wrapper.
What confirmed the decision
Two things landed while I was building:
Claude Code Desktop — Anthropic's official GUI. Visual diffs, parallel sessions, live app preview, PR monitoring, GitHub integration. Free with Pro/Max. And because it embeds the engine, none of the subprocess problems.
Claude Cowork — "Claude Code without the code." Chat-based file operations for non-technical users. This was the exact audience I was targeting, now served for free by the platform owner.
Separately, I already knew about Opcode — 20K+ GitHub stars, same Tauri + React stack, free and open source. But there were also Codexia, CodePilot, Claude Code WebUI, Yume, CC Switch, and more. All free, all open source.
The competitive picture was clear: I was building a wrapper in a market where the platform owner ships a native solution and a dozen open-source alternatives already exist.
The actual takeaway
This isn't a "should've researched more" story. I did check the landscape — I knew about Opcode, I knew about Claude Code Desktop. What I underestimated was how hard the subprocess constraint would hit, and I didn't fully appreciate that it's unsolvable from the outside.
The real lesson: if your product wraps a CLI, you're building on a platform where the owner has a permanent architectural advantage. They can embed the engine; you can't. That's not a gap you close with better UI or more features. It's structural.
I don't regret building it. I learned Tauri, I shipped a working cross-platform app, and I found the boundary between "hard problem" and "impossible problem" pretty fast. Three days is a cheap price for that answer.
What's still there
The code is on GitHub. Working Tauri + React app with chat, project management, agent/skill discovery, i18n, and onboarding. Use it as a reference if you want.
One thing CC Desktop does that the official tools still don't: **auto-discover agents and skills from .claude/ and show them in a UI**. The official Claude Code Desktop doesn't surface agent teams or multi-agent orchestration — that's CLI-only for now.
If you're thinking about wrapping an AI CLI in a GUI: check whether the CLI owner exposes an embeddable engine or just a subprocess interface. If it's subprocess-only, your performance ceiling is set by them, not by you.