The Tool Had 22 Open Issues. I Fixed That by Not Using It.

A new tool launched 9 days ago that does exactly what I needed.

22 open issues. Requires experimental flags. Installation docs that send you to three different places. One of the open issues is titled “crashes on startup with fresh install.”

I evaluated it for about 20 minutes. Then I built the same thing myself in a different 20 minutes.

The Problem It Was Solving

I run multiple Claude Code sessions at the same time. Head of CS for roughly 3,000 accounts means I’ve got one session on customer health analysis, one drafting outreach emails, one running a content calendar update, and one doing whatever I asked it to do 40 minutes ago that I’ve since forgotten about.

Each session starts completely blind to what the others are doing.

Session A drafts an outreach email to a customer. Session B runs account health and flags the same customer as churn risk and drafts a different email. Both fire. The customer gets two emails in 20 minutes that contradict each other. She’s very gracious about it. I am not.

The tool in question — claude-peers-mcp — is an MCP server that gives Claude Code sessions awareness of each other. Shared context, message passing between sessions, inter-agent communication. Legitimately useful architecture. Exactly the problem.

Nine days old. 22 open issues. Experimental flags required to even run it.

What I Did Instead

I read the code.

Not all of it. Enough to understand the mechanism. The core of what it’s doing: sessions need a shared communication layer that persists outside any individual session’s context window. The MCP server is one implementation of that idea. It’s not the only one.

The underlying concept is simple. You need:

A place sessions can write messages
A way for sessions to know what they’ve already read
Delivery into the session context without requiring the AI to go look for it

An MCP server does this. So does a text file.

Here’s what I built in 20 minutes:

Append-only daily log. Every session can write to it. Messages are timestamped, tagged with a session ID, and appended. No locks, no server, no ports. Just a file.

Per-session read markers. Each session tracks the last position it read in the log. On startup, it reads from its marker to end-of-file and picks up anything it missed. The marker updates after each read.

Delivery via existing hook. I already had a hook that fires on every user message. It now checks the log, reads new entries since last read, and injects them into the session context. The AI sees inter-session messages in its system context on the very next interaction after they’re written.

Total infrastructure added: one text file, one marker file, 30 lines added to an existing hook script.

I tested it. Sent a message from Session A. Switched to Session B. Sent any message. Session B’s system context included the message from Session A.

First keystroke. Done.

The Framework

I use a three-question filter every time something new ships:

1. What problem is it actually solving?

Not the headline. Not the README intro. The actual mechanism. What state does it maintain? What does it read? What does it write? What would break if you removed it?

For claude-peers-mcp: sessions need a shared communication channel that persists outside individual context windows.

That’s the problem. Not “inter-agent coordination.” Not “multi-session awareness.” A shared channel that persists. Once you strip it to that, the solution space opens up considerably.

2. Do I understand the mechanism?

If I can’t explain how it works at a component level, I’m not ready to depend on it. Not because I’m paranoid — because when it breaks at 11 PM (and it will break at 11 PM), I need to know where to look.

If I can explain the mechanism, I can also ask: is this the only way to implement it? Is the complexity load-bearing, or is it solving problems I don’t have?

3. Can I replicate the 20% that does 80% of the work in less time than it’ll take to debug their v0.0.9?

This is the actual decision. The answer is not always yes. Plenty of tools are doing hard things that would take weeks to replicate. Authentication flows. Video processing pipelines. Database optimization engines. Don’t build those.

But session message passing between text files? Yeah. Twenty minutes.

The threshold is roughly: if I can understand the mechanism, and the mechanism is doing something I could implement with the tools I already have, and the existing implementation is early-stage enough that debugging it costs more than building it — build it.

When Not to Build

This framework gets misread as “always build instead of adopting tools.” That’s not it.

I use Salesforce. I’m not building a CRM. I use Typefully. I’m not building a social scheduling tool. I use n8n. I’m not building a workflow engine.

The calculation flips when:

The tool is doing something genuinely hard (database query optimization, ML inference, video transcoding — not my problem to reinvent)
The tool is mature and battle-tested (production-grade tools have solved edge cases you haven’t hit yet)
The team dependency is real (if the rest of your team is using it, the integration value outweighs the build cost)
The build time exceeds the debug time (if replicating it honestly takes longer than adopting it, adopt it)

The claude-peers-mcp case hit none of those. Nine days old. Simple mechanism. Solo user. 20-minute build. Easy call.

The Actual Takeaway

New tools are a signal, not a solution.

When something ships that solves a problem you have, the useful question isn’t “should I use this?” It’s: “what problem is this actually solving, and what’s the minimal version of that solution that works for my context?”

Sometimes the answer is: use the tool. It’s doing something real and the complexity is justified.

Sometimes the answer is: you’ve just been shown the right problem to solve, and you can solve it in 20 minutes with a text file.

The new shiny thing is usually showing you where the gap is. It’s not always the thing to fill it with.

Update (Apr 3): The file-based system has held up through a week of multi-session use. No issues. Will revisit claude-peers-mcp when it matures — the MCP approach is architecturally cleaner for complex scenarios.