Why I Built a macOS Toolkit for Claude Code

I discovered Claude Code in late 2025. Yes, I was late to the party. But the moment I started using it, I was blown away. I was building solo what would have taken five-plus developers months at my last startup. Features shipping in days instead of quarters.

Then I started running parallel workstreams — multiple projects, multiple sessions, real usage. That's when I noticed it. The tool itself was incredible. The workflow around it had friction. Not big, obvious problems. Small ones. The kind you barely notice at first. But over an eight-hour day, across multiple projects, that friction compounds.

Death by a thousand paper cuts

Here's what my day looked like before:

• Open Terminal. Type claude. Wait for it to load. Realize I forgot to cd to the right project. Close it. Open a new tab. cd. Type claude again.
• Get 4 sessions running across 2-3 terminal windows. Lose track of which tab is which. Cycle through them trying to find the one that was waiting on me.
• Want to show Claude a UI bug. Take a screenshot. It saves to Desktop. Open Finder. Drag the file into the terminal. Paste the path. Tell Claude to look at it.
• Know what I need to work on today, but spend 5 minutes typing the task description into Claude instead of just... sending it.

None of these are deal-breakers. But multiply them by dozens of times a day, every day, and you're burning real time on workflow overhead instead of actual work.

What I wanted

I wanted a thin layer on top of Claude Code that handled the logistics so I could focus on the work. Specifically:

• A terminal that knows about Claude. Auto-launch on open. Status in every tab. No more guessing which session needs me.
• A place to plan work that talks to Claude. Not a full project management tool — just a lightweight board where I can organize tasks and send them into sessions.
• A way to show Claude what I see. Hotkey, screenshot, it's in the terminal. Done.
• One view of all sessions. What's running, what's waiting, what's running low on context.

Building it

I built it as a native macOS menu bar app using Electron. It sits in your menu bar — one icon, four tools. The whole thing is local. No cloud, no telemetry, no accounts beyond license activation.

The task board integration was the most interesting part to design. I initially considered building an MCP server so Claude could read the board through the Model Context Protocol. But then I realized: Claude can already read files. If the board is a file, Claude can read it natively. No server needed.

So the board just writes to a JSON file. You tell Claude where the file is in your CLAUDE.md. That's the entire integration. It's been running this way for weeks and it's been more reliable than any API-based approach I tried.

What surprised me

The screenshot tool came from the same thinking that drives all of this: micro efficiencies. Every extra click, every second waiting, every unnecessary movement — it all adds up. So it was a no-brainer. One hotkey, the screenshot drops straight into whichever terminal session I'm on. No pasting a file path. No digging through Finder because I hit the wrong key combo. Just capture and it's there.

The session monitor was the opposite — I knew I needed it before I started building. But it surprised me with the context health indicator. Being able to see when a session is running out of context window before it starts making mistakes has saved me from losing work more than once.

Who it's for

If you use Claude Code occasionally, you probably don't need this. The standard terminal works fine for one or two sessions.

If you use Claude Code as your primary development tool — multiple sessions, multiple projects, hours per day — this removes the friction that standard terminals don't know about. It's $24, one-time purchase, and it's built by someone who uses Claude Code the same way you do.

Check it out at claudecodetoolkit.com.