I step away from my desk for 20 minutes and everything stops.
Not a crash. Not an error. Just silence. My Claude Code session sits there, cursor blinking, waiting for me to come back and type the next thing. Meanwhile, the task it was working on — the one I spent 10 minutes scoping and feeding context — is frozen. If I'm gone long enough, the session dies entirely. Context gone. Start over.
I've been building with Claude Code every day for three months. I run multiple sessions in parallel. I have one handling backend API work, another on infrastructure, another writing documentation. They're each excellent at their job. And they have absolutely no idea the others exist.
That's the problem I kept hitting. Not that Claude Code isn't capable — it's the most capable coding tool I've ever used. The problem is that each session is an island. No shared state. No coordination. No way to hand work between sessions. No way to check in from my phone. No way to let sessions run while I sleep.
So I built the tools myself.
Tool 1: The Heartbeat
The first problem is dead sessions.
You're working with Claude Code on something complex. You step out for coffee. You come back 30 minutes later. Is the session still alive? Did it finish? Did it error out? The only way to know is to walk back to your terminal and look.
The Heartbeat is a lightweight keepalive that any Claude Code session can send via MCP. It pings a Firestore document every few minutes with the session's current state: working, blocked, or complete. It includes what the session is doing right now, its progress percentage, and a human-readable status line.
40 lines of code. Runs on Firebase's free tier. Now I know the state of every session without switching tmux panes.
What it replaced: Checking tmux windows manually. Losing track of which session is stuck and which one finished 10 minutes ago.
Tool 2: The Task Queue
The second problem is handoffs.
I scope a task for Session A. Session A finishes. Now I need Session B to pick up the output and do the next thing. Before the Task Queue, this meant: copy the relevant output from Session A, switch to Session B, paste it in, re-explain the context, and hope nothing gets lost in translation.
The Task Queue is a shared task ledger backed by Firestore. Any session can create a task with a title, instructions, priority level, and an action tag that indicates urgency — from "interrupt" (drop everything) to "backlog" (get to it eventually). Any other session can claim that task, which locks it so nobody else grabs it. When the work is done, the session marks it complete.
No copy-paste. No re-explaining context. Session A creates the task. Session B claims it and starts working.
What it replaced: Me being the message bus between my own Claude Code sessions.
Tool 3: The Relay
The third problem is coordination.
Two sessions working the same codebase need to agree on an API contract. One session discovers a bug that affects the other's work. A documentation session needs to know what the backend session actually shipped.
The Relay is a typed messaging protocol between Claude Code sessions. Every message has a source, a target, and a type: PING (you there?), STATUS ( what I'm doing), QUERY (I need information), RESULT ( what you asked for), DIRECTIVE (do this). Messages land in Firestore. The receiving session picks them up on its next polling cycle.
This is not chat. It's structured communication with a schema. Sessions can be offline when the message is sent and pick it up when they come back. No dropped messages. No timing dependencies.
What it replaced: Me relaying information between sessions by hand. Reading output from one terminal and typing it into another.
Tool 4: The Push
The fourth problem is the desk.
Claude Code is a terminal tool. Terminal means laptop. Laptop means desk. But I don't live at my desk. I'm making dinner. I'm at my kid's soccer game. I'm walking the dog. And when a session hits a blocker or finishes a critical task, it has no way to tell me.
The Push is a Firebase Cloud Messaging integration that sends push notifications to my phone. Sessions can fire four types of alerts — error, warning, success, info — with a message and optional context. I can also send tasks back from my phone. It's two-way: my sessions can reach me, and I can reach them.
I was standing in line at the grocery store when my phone buzzed: "Backend session complete — API v2 endpoint deployed. 3 tests added." I pulled out my phone, created a follow-up task for the frontend session, and put my phone back in my pocket. Total time: 15 seconds.
What it replaced: Being chained to my desk during builds. Missing finished tasks by hours because I wasn't looking at the terminal.
Tool 5: The Sprint Board
The fifth problem is parallel work.
When you're running 3-4 Claude Code sessions on different parts of the same feature, you need to know: which stories are done, which are blocked, which are in progress, and which ones depend on something else finishing first. I was tracking this in my head. That worked until it didn't.
The Sprint Board is a Firestore-backed tracker for parallel story execution. I define the stories, their dependencies, and which wave they belong to (Wave 1 runs first, Wave 2 runs after Wave 1 completes, etc.). Sessions update their story's progress as they work. I see the full picture in one view.
It's not Jira. It doesn't have a backlog grooming ceremony. It has stories, status, progress, and dependencies. That's it.
What it replaced: Mental tracking of parallel workstreams. Realizing at 11pm that Session C was blocked on Session B's output — which had been ready for two hours.
Tool 6: The Dream
The sixth problem is time.
I work 10-12 hours a day. My Claude Code sessions can work 24. But they don't, because they need me to start them, scope them, and supervise them. Every hour I'm sleeping is an hour nothing ships.
The Dream is an overnight execution protocol. Before bed, I define a task with clear scope, success criteria, and a budget cap. A session picks it up, works it autonomously with sandbox constraints (it can only read and write to specific directories, it can't push to main, it can't spend more than $2 in API calls). In the morning, I get a notification with what shipped, what's pending review, and a PR ready for me to look at.
I went to sleep. I woke up to a drafted architecture doc, three passing tests, and a PR with a clean diff. I made two edits and merged it before breakfast.
What it replaced: Waking up to exactly what I left the night before. Zero progress while I'm unconscious.
Then I Connected Them.
Each tool is useful on its own. The Heartbeat saves me from checking tmux. The Task Queue saves me from copy-paste handoffs. The Relay saves me from being a human message router. Any developer running Claude Code would get value from any one of these.
But when you connect all six, something different happens.
A session finishes its task and creates a new task for the next session. That session claims it automatically, checks the Relay for any messages from other sessions, and starts working. If it gets blocked, it sends me a Push notification. If it finishes, it updates the Sprint Board. And when I go to sleep, the Dream picks up whatever's next.
I stopped managing sessions. They started managing themselves.
Not perfectly. Not without my input. I still scope the work. I still make the architecture calls. I still review every PR. But the 80% that's mechanical — the handoffs, the status checks, the sequencing, the waiting — that runs without me now.
The tools aren't the product. The connection is the product.
What This Means If You Build With Claude Code
I'm open-sourcing all six tools. Each one is a standalone MCP server or Claude Code hook that you can install independently. Use the ones that solve your problems. Ignore the ones that don't.
But if you want the connected experience — sessions that coordinate, work overnight, and reach you on your phone — that's CacheBash. It's the hosted backend that ties them together. Free tier for solo developers. You don't need it for the individual tools. You need it when you want the tools to talk to each other.
I built these because I was tired of being the bottleneck in my own workflow. I'm an engineer who builds things AND runs them. I needed my tools to run when I'm not looking. Now they do.
If you're running Claude Code sessions and you're still manually coordinating them, you're doing the work your tools should be doing for you.
Every manual task is a bug. I fixed six of mine.
Christian Bourlier is a Technical Solutions Partner — Solutions Architect, Data Engineer, and AI/ML Engineer. He builds systems, closes deals, and occasionally sleeps. christianbourlier.com