DEV Community: Chad

I just wanted Claude Code on my phone. 10 days and 2,000 downloads later, here's the story.

Chad — Wed, 18 Feb 2026 22:45:14 +0000

I didn't set out to build a developer tool. I just wanted to use Claude Code away from my desk.

This is how a personal workflow hack turned into an open-source project with 2,000+ npm downloads — and what I learned along the way.

Claude Code is already an app

Most people think of Claude Code as a coding tool. I saw something different: a runtime for a personal AI assistant.

Think about it. Claude Code already has everything you need — a conversational interface, file system access, persistent context through CLAUDE.md, custom slash commands, and the ability to read, write, and search across your entire project. It's not just a coding agent. It's a programmable chat application that happens to run in a terminal.

So instead of building an app with Claude Code, I decided to use Claude Code as the app.

I configured a CLAUDE.md that described my projects, my goals, my preferences, and my schedule. I added slash commands for recurring workflows — session management, project tracking, weekly reviews. I organized file-based knowledge across folders that it could search and reference.

The result was a personal assistant that remembered everything, understood my context deeply, and improved every time I refined the instructions. I canceled my ChatGPT Plus subscription and genuinely didn't miss it — not even the memory feature. This was better.

But it ran in a terminal. And I wanted it everywhere.

The problem: it lived on my desk

Claude Code runs in a terminal. Close the lid, and it's gone.

So I set up a dedicated MacBook in my garage as an always-on server. Amphetamine to prevent sleep, Tailscale for secure remote access, tmux to keep sessions alive. Then I'd SSH in from my phone using iSH.

It worked. I could reach Claude Code from anywhere over Tailscale.

But the experience had friction. iSH was surprisingly capable for a mobile terminal, but there were real limitations — copying images in tmux was painful, and the phone keyboard UX had a hard ceiling. It was functional, not comfortable.

I checked Claude's official app. The UI was nicer, but it required pushing code to GitHub and spinning up a virtual environment each time. Slash commands weren't fully supported. It wasn't the same setup I'd built.

The idea: cut the steps

What I really wanted was fewer steps.

Before:  phone → iSH → SSH → tmux attach → claude
After:   phone → tap bookmark → claude-relay

A lightweight web server could do that. Relay the Claude Code session to a browser page, add it to my home screen, done.

Since I was already on Tailscale, I didn't need complex authentication — no cloud, no third-party auth. Just a simple PIN to keep it locked down. The whole thing could run locally.

spawn("claude") → stdout JSON stream → WebSocket → browser

That's the first version. I spawned the claude CLI as a child process, parsed its stdout JSON stream line by line, and relayed everything to a browser page over WebSocket.

That's why it's called "relay."

8 days after the first commit, it was on npm.

What I didn't see coming

Here's the thing: I'm comfortable in the terminal. I use Claude Code for coding all day, but I'd also turned it into a personal assistant — project management, scheduling, note-taking, all through the same interface. For me, the terminal was fine. The relay server was just a way to access it when I was away from my desk — nothing more.

So when I shared it on Reddit, I wasn't expecting the feature requests I got:

"Can I get notifications when Claude needs approval?"
"Can I run multiple projects at once?"
"I want to use this for hands-off coding"

I hadn't considered any of these because they weren't my problems. But every single one was valid. These were developers using Claude Code differently than I was — as a coding assistant that needed babysitting. They wanted to walk away and come back when it was done.

That changed my perspective on what this tool could be.

20 stars and 1,876 downloads in the first week.

v2: From personal hack to developer tool

The stdout parsing approach had gotten me far, but it couldn't support everything Claude Code could do. I switched to the official Claude Agent SDK, which gave me full programmatic control — model switching, usage tracking, session compaction, the works.

But I was careful about one thing: don't break Claude Code.

I'm a terminal person. What feels like a convenience to me might break someone else's workflow. So the principle was: preserve the Claude Code experience exactly, and only add what the browser uniquely enables.

Push notifications

This was the feature that changed everything — and it wasn't even on my original list.

Claude needs approval → phone buzzes → tap approve → done

No more walking back to check if Claude is waiting. No more losing 20 minutes of dead time because you forgot which terminal window it was in. The session keeps moving whether you're at your desk or not.

I added PWA support so you could install it on your phone's home screen. The favicon blinks in the browser tab when a session needs attention. It fundamentally changed how people used Claude Code — from something you babysit to something that works alongside you.

The hardest part: onboarding

Building the notification itself was straightforward. The hard part was making sure people could actually set it up.

Push notifications require HTTPS. If you use Tailscale Pro, the certificate problem solves itself — but I didn't want to require a paid service for a free tool. So I went with mkcert for local certificate generation. Install the cert, trust it on your phone, done.

But "done" is doing a lot of heavy lifting there. How do you guide a user through certificate installation, PWA setup, and push permission — all from a CLI tool?

I built a multi-step onboarding flow directly in the terminal. It surveys your use case first (local only? remote access? mobile?), then gives you one task at a time based on your setup. Once the terminal steps are done, it shows a QR code that hands off to your phone for the remaining setup.

This was probably the feature I spent the most time on. Not the notification itself, but making sure anyone could actually get there.

File browser and terminal

I was still keeping VS Code open on the side — just for quick file checks and the occasional terminal command. Four-finger swipe to VS Code, glance at a file, swipe back. Dozens of times a day.

So I added a read-only file browser and a built-in terminal. Not a full IDE — just enough to check files and run commands without leaving the window.

I stopped opening VS Code. If I needed to edit a file directly, vim in the built-in terminal was enough.

The worktree revolution

Around this time, I switched my git workflow from git checkout to git worktree. Combined with claude-relay, the effect was dramatic.

My setup with Arc Browser: split each tab — claude-relay on the left, the dev server on the right. One saved tab per worktree. Switch between issues by switching browser tabs.

Now I had 4-5 branches running simultaneously. Claude working on a feature in one tab, fixing a bug in another, refactoring in a third. Browser notifications told me which one needed attention. Context switching dropped to near zero.

The port problem

But managing all those sessions was getting messy. Each claude-relay instance needed its own port — 2633, 2635, 2637, hopping by twos. I'd forget which port mapped to which branch. Every new worktree meant opening a terminal, configuring the server, starting a dev server manually.

So I built a daemon. One port (2633), one process, managing everything. Projects register over Unix IPC, and the web UI routes via WebSocket paths. Add a project from the CLI, and it appears in the browser instantly.

Persistent terminals

The last piece. The built-in terminal was ephemeral — close the tab, lose the session. But I needed dev servers running per worktree, and I didn't want to remember which port was which.

I made the terminals persistent. Start a dev server in a terminal tab, close the browser, come back later — it's still running. Each project can have multiple named terminal tabs. The port management problem just... disappeared.

That's where we are now: v2.2.

What I learned

Build for yourself first. The best tools come from genuine daily friction, not market research.
Ship before it's ready. v1 was a single server.js. It was enough to validate the idea.
Users see what you don't. I'm a terminal person — I never would have prioritized push notifications or hands-off mode. The community shaped this tool more than I did.
Preserve the original experience. Adding features is easy. Not breaking existing workflows is hard.

Try it

npx claude-relay

One command. No account, no cloud, no install. Everything runs on your machine.

GitHub: github.com/chadbyte/claude-relay
npm: npmjs.com/package/claude-relay

What's your Claude Code setup like? I'm curious how others are working with it — especially if you've found ways to reduce the context-switching problem.

I stopped building apps with Claude Code. Now, Claude Code IS the app.

Chad — Sat, 07 Feb 2026 10:37:50 +0000

I was building apps with Claude Code. Development was fast. I was excited. Then it hit me: we just got the internal combustion engine, and I'm using it to build a faster horse carriage.

As someone with a backlog of things to manage, I wanted to build apps to improve my quality of life. Track my expenses, log my Jiu-Jitsu mat time, monitor my sleep. Claude Code made development fast, so I started building.

But while writing the code, I had a reality check. All I really want is to record data and have AI analyze it. I don't need pretty buttons or flashy dashboards. I'm the only user. Why am I polishing a frontend? Why am I worrying about deployment?

The speed didn't eliminate this fundamental question. What I wanted was to record data consistently, have AI interpret it, and get feedback. The frontend was never a requirement.

So I thought: Why not just do it all inside Claude Code?

What I did instead of building an app

Instead of initializing a new app, I ran mkdir my-life and launched Claude Code right there.

The first thing I did was install skill-creator from skills.sh. It lets you create new skills on the fly.

Using that, I created /deep-interview. I asked it to query my true motivations. At first, it asked one-dimensional questions. I told it that this would only reaffirm the version of myself I wanted to be, and asked it to dig into specific past examples instead.

Then, Claude started interviewing me properly. My values, decision-making patterns, personality type. The results went into me.md — my personality type, motivation structure, recurring behavioral patterns. It took about 30 minutes.

Next, I told it about all the side projects I was managing. Why I wanted them, the context in which they started. The deep interview resumed. In the process, some projects were naturally dropped, and for others, I was advised to focus solely on completion.

The best part was discovering that I was staying in my comfort zone — building things but never announcing them. I would develop but never release. Putting something out means being evaluated, and that's outside my control. My developer ego was avoiding that. The project revealed this tendency. The advice was simple — the outcome is uncontrollable anyway, so just release.

Later, I wanted to expand this to my financial life. I downloaded my recent transaction history as a CSV from my bank app and uploaded it. I prompted it to organize the categories. At first, it tried to do it in Markdown, which was inefficient. I had it install SQLite. I told it not to set categories from the start, but to review the transactions one by one and create adaptive categories. It executed this perfectly.

After analyzing over 600 transactions, I asked it to write a report in the tone of a kind financial advisor, pinpointing our household spending patterns and offering constructive prospects for future financial goals. I shared it with my wife, and she was delighted.

From then on, I started adding tools to record everything in my life. Sleep patterns, weight management. Replacements for apps I had tried to use but abandoned — sometimes due to clunky interfaces, sometimes due to my own laziness — started being added one by one.

Structured data went into SQLite. An expense DB, a workout DB, a health tracking DB — three databases replaced three apps. Unstructured data went into Markdown. Eventually, everything converged into a single directory.

~/my-life/
├── me.md              # Who I am (Mission, Values, Personality)
├── now.md             # What I'm doing right now
├── projects/          # Things with an end
├── goals/             # Things I want to achieve
├── practices/         # Things without an end (Workout, Writing...)
├── data/*.db          # Structured data (Finance, Workout, Sleep, Weight)
├── context/           # Budget, Transaction logs
├── sessions/          # Conversation logs per session
└── CLAUDE.md          # Operations manual for Claude

No React. No API server. No deployment pipeline. Just files, SQLite, and an AI that can read, write, and reason about it all. That's everything.

The moment I felt the difference

The more context I gave this project about myself, the deeper Claude Code's responses became. Sometimes I asked Claude what else it wanted to know about me, and conversely, I asked what patterns I had that I wasn't recognizing.

I have a pattern. When a project is about 95% complete, I suddenly get a new idea and want to drift toward that. Typical completion avoidance. This pattern was revealed in the deep interview, and since I was aware of it, I created a skill called /escape95. It checks conditions like: "Are you trying to add a new feature when it's already deployable?" and "What was the original goal?" If the pattern is detected, Claude intervenes.

One day, I brought up a shiny new project idea. Claude looked at me.md (completion avoidance tendency), checked projects/ (two unfinished projects), and said:

"No. Finish the existing projects first. This is your pattern. Let's talk after you finish what you have."

The AI told me "No." Not because of a content policy, but because it understood me — cross-analyzing my personality, my behavioral patterns, and my current state — and made a judgment for me.

What app does this? Does Notion say, "Don't make another page"? Does Todoist cross-reference your personality type with your project status? Each app only sees its own data. But when everything is in one directory, the AI can see the whole picture and reason across it.

And this isn't a task manager. When a session ends, a log remains, recording even the emotional flow of the day. I started this project a few days ago, and the early session logs were full of anxiety. Is this the right direction? Will this work? The current session logs are filled with clarity. The change over just a few days is recorded. This isn't a tool. It's a thinking partner.

A car that changes its own tires based on the terrain

The essence of this tool is that it is not a finished product. Whenever I need something, I add a skill, and the tool itself changes. If I need a ledger, I create a skill. If I need calendar integration, I attach an MCP. If I want to track a new habit, I add a table to the DB and create a skill. If I need intervention in my behavioral patterns, I make that a skill too.

It feels like riding in a car that changes its own tires and engine as the terrain shifts. No app can do this. Apps are confined to the use cases imagined by their creators. Last week it was a finance tool. This week I added behavioral intervention. Next week it could be something I haven't thought of yet. Projects like Clawdbot started from a similar philosophy, but you're still customizing within someone else's framework. Here, there is no such ceiling.

I dropped all other projects

After creating my-life, I stopped developing all side projects related to personal tracking. I no longer needed them. No matter how great a SaaS comes out, I don't want to give up the joy of using this tool that holds all my context and considers the whole picture.

And I realized — what if this were a SaaS? It would be terrible. 90% of the utility I feel would vanish. What I find useful isn't a sleek GUI. In fact, the GUI distracts from the essence. What's useful is talking directly in natural language with an AI that holds all the context, and being able to change the tool itself when needed.

Instead of building a SaaS, I wanted to use Claude itself as the app. I wanted to access it from anywhere. At first, I ran Claude Code in tmux and SSHed in from my phone. It worked, but it was clunky. Eventually, I built a WebSocket relay server so I could access it directly from a web browser. Now, I can talk to the tool that knows my finances, projects, goals, and patterns from anywhere.

Looking back

I was using Claude Code to build apps. Then I realized Claude Code itself was the app all along — not a tool for making the product, but the product itself.

And that raises a harder question: did I ever need the app in the first place? The frontend, the deployment, the authentication — all of that was scaffolding for something that a directory of files and an AI could already do.

What I needed wasn't Software as a Service. It was Claude Code as a Service. An AI that has all my context, accessible from anywhere. That's it.

I'm not saying all GUIs should disappear tomorrow. But I do think that the tech layer — which is ultimately just an interface between data and humans — is going to get much thinner than we expect.

It's a strange feeling as an app developer, but I don't want to go back.