DEV Community

Hamed Farag
Hamed Farag

Posted on • Originally published at hamedfarag.dev

I Built a Browser UI for Claude Code — Here's Why

I started using Claude Code a few months ago. Terminal-first, no nonsense, incredibly powerful. But after weeks of juggling sessions, losing track of costs, and wishing I could approve tool calls from my phone while grabbing coffee — I started building something for myself.

That something became Claudeck.

It started on March 1st as a quick experiment I called "shawkat-ai" — a simple WebSocket bridge between my browser and the Claude Code SDK so I could chat without squinting at terminal output. Then I added cost tracking because I wanted to know where my money was going. Then session persistence. Then workflows. Then agents. Then a plugin system. Then Telegram integration. Then autonomous agent DAGs.

Two weeks later — yes, two weeks — it was a full-featured browser UI with 50+ features, renamed to Claudeck, published on npm, and somehow competing with tools backed by YC and teams of engineers. 55 commits in 15 days, each one adding a major feature.

This is the story of why I built it, what makes it different, and why you might want to try it.


The Problem with Claude Code in the Terminal

Don't get me wrong — Claude Code in the terminal is excellent. It's fast, it's powerful, and it gets out of your way. But there are real friction points:

You can't see the big picture. How much have you spent today? This week? Which sessions burned the most tokens? The terminal doesn't tell you.

Context switching is painful. You're mid-conversation, need to check something in another session, and now you've lost your place. No tabs, no background sessions, no parallel conversations.

You can't walk away. Claude asks for permission to run a bash command. You're making coffee. The session just... waits. Anthropic recently shipped Remote Control — scan a QR code and approve from your phone via claude.ai. It's a step forward, but it's Max-only ($100–$200/mo), requires your terminal to stay open, and gives you approval control without the broader context — no cost tracking, no session management, no workflows.

No visual tools. File diffs are raw text. There's no file explorer. No git panel. No way to drag a file into the conversation.

No workflows. Every PR review starts with the same three prompts. Every repo onboarding follows the same pattern. But you type them out fresh each time.

I kept a mental list of these annoyances. On March 1st, 2026, I decided to fix them. What I thought would be a weekend project turned into a two-week sprint that I couldn't stop.


What is Claudeck?

Claudeck is a browser-based UI for Claude Code. One command to launch:

npx claudeck
Enter fullscreen mode Exit fullscreen mode

It connects to the official Claude Code SDK running on your machine. Your API key, your local files, your git repos — nothing goes through a third-party server. It's a local web app that gives Claude Code a proper interface.

Think of it as what VS Code is to vim — the same power, but with a visual layer that makes certain things dramatically easier.

Claudeck Home — AI Activity heatmap, cost analytics, and project dashboard

Claudeck Chat — Real-time streaming with session sidebar, Whaly mascot, and status bar


The Landscape: Why Not Use Something Else?

When I started building on March 1st, I wasn't thinking about alternatives. By the time I looked up two weeks later with a fully shipped product, there were at least a dozen. Here's the honest picture:

Opcode (20K+ stars, YC-backed)

A polished desktop app built with React and Tauri. Great session management, usage analytics, and custom agent creation. But it's desktop-only — no mobile, no PWA, no browser access. And it requires installing a native app.

CloudCLI (7.9K stars)

The multi-CLI Swiss Army knife. Supports Claude Code, Cursor CLI, Codex, and Gemini CLI. Has a file explorer and git integration. But no cost dashboard, no workflows, no prompt templates, and no parallel chat mode.

CodePilot (3.1K stars)

Electron + Next.js desktop app with model switching and permission controls. Solid, but again — desktop-only, no workflows, no cost analytics, no prompt templates.

Anthropic's Remote Control

Anthropic's own answer: run claude remote-control, scan a QR code, control from your phone via claude.ai/code. But it's Max-only ($100–$200/mo), the terminal must stay open, and there's no file explorer, no analytics, no multi-session management.

So why Claudeck?

Because none of them scratched every itch. I wanted:

  1. Browser-based — open a tab, start working. No Electron, no Tauri, no native install.
  2. Cost visibility — know exactly what I'm spending, per session, per day, per project.
  3. Workflows and templates — stop retyping the same prompts.
  4. Agent orchestration — not just one agent, but chains, DAGs, and an auto-orchestrator.
  5. AFK approval — approve tool calls from my phone via Telegram while away from my desk.
  6. Zero bloat — vanilla JS, 6 npm dependencies, no build step.

No existing tool offered all of these. So I built it.


Features That Matter

I'm not going to list all 50+ features. Here are the ones that changed how I work:

Parallel Mode (2x2 Grid)

Four independent Claude conversations running simultaneously in a grid layout. I use this constantly:

  • Pane 1: refactoring a module
  • Pane 2: writing tests for it
  • Pane 3: reviewing a PR
  • Pane 4: exploring documentation

Each pane has its own session, its own context, its own streaming output. No competitor has this.

Cost Dashboard

A full analytics dashboard with daily cost charts, per-session breakdowns, input/output token counts, and error pattern analysis. I can see at a glance that Tuesday's refactoring session cost $4.20 across 47 turns, and that 30% of my errors are "File Not Found."

This is the feature that convinced me to make Claudeck public. Every Claude Code user deserves to know where their money goes.

AI Workflows

Pre-built multi-step pipelines:

  • Review PR — analyze diff, identify issues, suggest improvements (3 steps, context carries forward)
  • Onboard Repo — map structure, explain architecture, generate dev guide
  • Migration Plan — audit dependencies, assess impact, create plan
  • Code Health — identify tech debt, suggest improvements

You can create your own workflows with full CRUD. Each step carries context from the previous one, so Claude builds on its own analysis.

Autonomous Agents

Four built-in agents (PR Reviewer, Bug Hunter, Test Writer, Refactoring) that run as high-turn autonomous sessions. But the real power is in composition:

  • Agent Chains — sequential pipelines: Bug Hunter finds issues, then PR Reviewer analyzes the fixes
  • Agent DAGs — visual dependency graphs: Bug Hunter and Test Writer run in parallel, then PR Reviewer synthesizes both
  • Orchestrator — describe a task in plain language, and it auto-decomposes into specialist agent calls

I built a full visual DAG editor with an SVG canvas where you drag agents and draw connections. It feels like a simplified version of a CI/CD pipeline builder, but for AI agents.

Telegram Integration (Two-Way)

This is the one people don't expect. Configure a Telegram bot, and:

  • Outbound: Every session completion, agent run, workflow step, and error sends a rich notification to your phone with metrics (cost, tokens, duration).
  • Inbound: When Claude needs permission to run a tool, you get an inline keyboard on Telegram with Approve/Deny buttons. Approve from your phone, and the web UI modal auto-dismisses.

I built this because I run long agent sessions and walk away. Now I approve bash commands from my couch.

Prompt Templates with Variables

{
  "title": "Code Review",
  "prompt": "Review {{file_path}} for {{concern}}"
}
Enter fullscreen mode Exit fullscreen mode

Click the template, fill in the form, send. Sixteen built-in templates, plus it auto-discovers .claude/commands/ and .claude/skills/ from your project directory.

File Explorer, Git Panel, and Code Diffs

  • Lazy-loaded file tree with syntax-highlighted preview
  • Git panel with branch switching, staging, commit, and log
  • LCS-based code diff viewer with green/red line highlighting for Edit and Write tool outputs

These aren't groundbreaking individually, but having them integrated into the same interface where you're chatting with Claude eliminates constant context switching.

Plugin System

Full-stack plugin architecture. Drop files in ~/.claudeck/plugins/my-plugin/ with a client.js and optionally a server.js, and it appears in the marketplace. Built-in plugins include Linear integration, a todo list with brag tracking, and even a couple of games for when you're waiting on a long agent run.

The best part? You can extend Claudeck using Claude Code itself. I published a Claude Code skill that lets you scaffold new plugins with a single command:

# Install the skill (one-time)
npx skills add https://github.com/hamedafarag/claudeck-skills

# Then in Claude Code, just describe what you want:
/claudeck-plugin-create my-widget A dashboard showing system metrics
Enter fullscreen mode Exit fullscreen mode

Claude generates the full plugin — client.js, client.css, and optionally server.js with Express routes — directly into ~/.claudeck/plugins/. Refresh the page and your plugin is live in the marketplace. No fork needed, no build step, no PR. You describe it, Claude builds it, Claudeck loads it.


The Technical Philosophy

Zero Framework, Six Dependencies

Claudeck's frontend is vanilla JavaScript ES modules. No React. No Vue. No Svelte. No bundler. No build step.

The entire backend runs on Express, WebSocket (ws), better-sqlite3, web-push, dotenv, and the Claude Code SDK. That's it. Six npm dependencies.

Why? Because I wanted to iterate fast. No waiting for builds. No fighting with framework upgrade cycles. No 200MB node_modules. Change a file, refresh the browser.

This choice is a big reason the entire project went from zero to 50+ features in 15 days. When you're building something for yourself, every minute spent on tooling is a minute not spent on features. Vanilla JS with ES modules and CSS custom properties is surprisingly productive when you're not fighting abstractions.

Everything is Local

No cloud. No accounts. No telemetry. Your data lives in ~/.claudeck/ — a SQLite database, some JSON config files, and your plugins. Delete the directory and it's gone.

This was non-negotiable for me. I'm sending code to Claude — I'm not also sending my usage patterns to a third party.

PWA with Offline Fallback

Install it as a PWA from Chrome's address bar. It runs in a standalone window, supports push notifications (even when the browser is closed), and has an offline fallback page. On mobile, it's fully responsive with tablet and phone breakpoints.


What Claudeck Doesn't Do

Honesty matters. Here's where alternatives beat Claudeck:

  • No authentication — anyone on your local network can access it. This is the biggest gap and the next thing I'm building.
  • No multi-CLI support — CloudCLI supports Claude Code, Cursor CLI, Codex, and Gemini CLI. Claudeck is Claude Code only.
  • No desktop app — if you want a native macOS/Windows experience, Opcode and CodePilot are better choices.
  • No live file editing — CloudCLI lets you edit files directly in the UI. Claudeck shows file previews but doesn't have an editor (that's what your IDE is for).

Who is Claudeck For?

Solo developers who use Claude Code daily and want visibility into costs, reusable workflows, and a visual interface without leaving the browser.

Developers who work AFK — the Telegram integration means you can kick off a long agent run, walk away, and approve tool calls from your phone.

Power users who want parallel conversations, agent pipelines, and prompt templates — features that the terminal simply can't offer.

Teams evaluating Claude Code who need cost analytics to justify the spend.


Try It

npx claudeck
Enter fullscreen mode Exit fullscreen mode

One command. No install. Opens in your browser. Your first session is free (well, you're paying Anthropic — Claudeck itself is free and open source).

The source is on GitHub: github.com/hamedafarag/claudeck

If you find it useful, star the repo. If you build a plugin, let me know. If you find a bug — definitely let me know.

Top comments (11)

Collapse
 
itskondrat profile image
Mykola Kondratiuk

the approve-tool-calls-from-your-phone use case is underrated. half the friction with CLI agents is being chained to the terminal for permission prompts. a browser UI that lets you monitor and approve remotely changes how you structure your work around agents - you stop babysitting and start checking in. curious if you have seen latency issues with the WebSocket relay under heavy tool call volume

Collapse
 
hamed_farag profile image
Hamed Farag

Thanks Mykola, really appreciate the kind words — and you nailed it. That shift from "babysitting" to "checking in" is exactly the workflow change we were going for.

On your question about WebSocket relay latency — great timing, we just ran a dedicated performance benchmark suite against the WS layer. Here are the numbers (localhost, Node.js ws v8, real TCP connections):

Approval Round-Trip Latency

Server sends permission_request → client responds → server receives

Concurrent Sessions p50 p95 p99
1 70 µs 132 µs 196 µs
5 187 µs 222 µs 244 µs
10 300 µs 466 µs 721 µs
25 382 µs 570 µs 764 µs

Even at 25 concurrent sessions, p99 stays under 800 microseconds. The relay itself adds negligible overhead.

Message Throughput

Streaming text chunks to connected clients

Clients Total msg/s
1 ~295k
10 ~393k
50 ~435k

Connection Scaling

100 simultaneous connections

  • Establish latency p50: 156 µs
  • Memory overhead: ~35 KB/connection (~3.4 MB total for 100 conns)

Broadcast Fan-Out

Notification delivery to all connected clients

Clients p50 p99
10 122 µs 160 µs
50 551 µs 657 µs
100 900 µs 1.84 ms

Short answer: no latency issues. The WS relay is not the bottleneck — Claude's thinking time dwarfs the relay overhead by orders of magnitude.
Even under heavy tool call volume with multiple background sessions running in parallel, the pipe stays fast.

The perf suite is now part of the repo (npm run test:perf) so we can track regressions going forward.

Collapse
 
itskondrat profile image
Mykola Kondratiuk

those latency numbers are solid - 50ms for an approval roundtrip is basically invisible in practice. the UX win of not being chained to the terminal is worth way more than people realize until they actually try it

Collapse
 
janealesi profile image
Jane Alesi

The vanilla JS / six dependencies approach is impressive for 15-day velocity. Two questions on the architecture:

  1. Does Claudeck wrap the Claude Code CLI process, or does it use the SDK directly? The article mentions "Claude Code SDK" but I'm curious about the actual integration layer — are you spawning a child process or calling SDK methods in-process?

  2. Have you considered how this fits alongside the VS Code extension ecosystem? Cline, Claude Dev, and others are already embedded there. The browser-based angle is clearly differentiated (no IDE dependency), but I wonder if there's a bridge opportunity — e.g., Claudeck as a companion panel that VS Code extensions could launch via a local server.

The agent DAG composition with the SVG canvas editor sounds like it could rival some lightweight LangGraph setups. Would be interesting to see how it handles error recovery when a mid-chain agent fails.

Collapse
 
hamed_farag profile image
Hamed Farag

Claudeck uses the @anthropic-ai/claude-code SDK directly, in-process. No child process spawning. The SDK's query() method returns an async iterable of messages that we stream over WebSocket to the browser in real time. This gives us direct access to session resumption, tool approval callbacks, cost/token metadata, and AbortController cancellation — all things that would be much harder to wire up reliably through a CLI wrapper.

Regarding the VS Code ecosystem, Great idea, and definitely something to consider for the future. Claudeck is intentionally browser-based and IDE-agnostic, so it works alongside any editor. But since it already runs as a local server, a lightweight VS Code extension that embeds Claudeck as a webview panel wouldn't require a major rearchitecture — just some tweaks to make the UI work well in that context. Not on the immediate roadmap, but the foundation is there.

for DAG error recovery, When a mid-DAG agent fails, that node is marked as error and the DAG halts dependent nodes (they can't run without upstream context). Independent branches keep running. The whole run is logged to the agent_runs table with per-node status, so you can see exactly where it broke. Right now it's fail-and-stop for the affected branch — retry/fallback logic per node would be a natural next step.

Collapse
 
janealesi profile image
Jane Alesi

Thanks for the detailed breakdown, Hamed! Streaming the async iterable directly from the SDK is definitely the way to go for low-latency feedback. Using WebSocket to bypass the CLI wrapper is a smart move—it preserves that 'technical stewardship' over the session state without the brittle nature of subprocess parsing.

I'm particularly interested in that 'fail-and-stop' DAG behavior. For the German Mittelstand, where consistency is often prioritized over raw speed, being able to audit exactly which node stalled is a key feature of 'Sovereign by Design' infrastructure. Looking forward to seeing if node-level retry/fallback logic makes it into the next iteration! 🌍🤖 #SovereignAI #ClaudeCode #AIEngineering

Collapse
 
peppermint profile image
Serge Abrosimov | Peppermint

Nice experiment. The terminal is powerful, but a browser UI could make monitoring AI agents much easier.

How are you handling things like multiple sessions or long-running tasks?

Collapse
 
hamed_farag profile image
Hamed Farag

for the multiple sessions: there's a Parallel Mode (2x2 grid, 4 independent chats), and Background Sessions. If you switch away mid-stream, it keeps running server-side — messages save to SQLite, a blinking dot tracks what's active, and a toast notifies you when it's done. Survives page refreshes and reconnects.

but for the Long-running tasks like agents, chains, and DAGs all run server-side with AbortController for cancellation. If you're AFK, Telegram integration sends tool approval requests to your phone with inline Approve/Deny buttons, so nothing stalls waiting for you.

Collapse
 
peppermint profile image
Serge Abrosimov | Peppermint

That’s really cool. Background sessions and server-side tasks sound very useful, especially for long runs. The Telegram approval feature is a smart touch, too.

Collapse
 
maxothex profile image
Max Othex

The terminal-only UX is one of the bigger friction points with Claude Code for most people. A browser UI with proper session management makes it dramatically more accessible to non-CLI folks and easier to context-switch between tasks.

Curious about your approach to the streaming output — did you go SSE or WebSockets for real-time display? And how are you managing context window state in the UI?

Building the experience layer around AI dev tools is underrated right now. Most folks are heads-down on the models and not thinking enough about making the interfaces actually usable.

Collapse
 
hamed_farag profile image
Hamed Farag

Thanks, and totally agree, the experience layer is where a lot of value is hiding right now. The models are incredible, but if the interface makes you fight for basic things like cost visibility or session management, you're leaving productivity on the table.

For streaming — WebSockets all the way. The Claude Code SDK emits events (text deltas, tool calls, permission requests, etc.) and I pipe those over a persistent WS connection to the browser. SSE would've worked for one-way streaming, but I needed bidirectional, the UI sends tool approvals, abort signals, and session switches back to the server in real-time.
The Telegram approval flow also rides on this, when you approve a tool call from your phone, the WS pushes that approval to the browser and auto-dismisses the modal.

For context window — Claudeck reads the token counts from each Claude Code SDK response (input/output tokens, cache reads/writes) and tracks them per session. The cost dashboard aggregates this into per-session, per-day, and per-project breakdowns. With the recent 1M context GA for Opus 4.6, this kind of visibility matters even more — you can burn through serious spend without realizing it.