Last week I wrote about saying no to a feature request: a user designed a laneId
mode for my project over four days, and the right answer turned out to be zero lines of code, because they ended up shipping the fix themselves — in their own layer.
That post was accurate. The decision was right. The code that shipped was right.
The explanation I gave them for why a particular setup would work — the one I wrote with full confidence, in public, on the issue thread — was wrong. Not completely wrong. Wrong in the more embarrassing way: one layer off.
They caught it within a day of my closing reply.
Quick context: I maintain safari-mcp, an MCP server that gives AI agents a real Safari session on macOS. The whole thread (#76) was about running multiple agents against one Safari without them stealing each other's tabs.
My server already had the hard part: in HTTP daemon mode, every client gets its own Mcp-Session-Id
, and the server keys all tab state — active tab, ownership markers, the works — off that session. Two clients on one daemon cannot see each other's tab pointer. I had shipped a real fix for a real bug in that mechanism days earlier. Tests, verification, release notes. That layer was solid, and I knew it was solid.
The user runs their agents through mcporter, a runner that manages MCP servers for multiple agent sessions. They'd found mcporter's own isolation knobs — a separate daemon directory per agent — and asked whether that would cover them.
Here's what I told them, nearly verbatim:
Separate daemon dir per agent + stdio transport = isolation by process boundary, but you're back to N Safari-controller processes.
Separate daemon dir per agent +HTTP transport = the winning combo— each mcporter daemon holds its own MCP client, so each gets its ownMcp-Session-Id
, so my per-session isolation engages. One process, full isolation.
Clean analysis. Two topologies, one recommendation, a confident bolded phrase. I framed their lane concern as something you only need on the stdio path.
They built and published their fix (mcporter-lanes), I credited it, updated my README, wrote the blog post, closed the loop. Then, about an hour after my closing reply, they posted again — politely, precisely:
With mcporter in the middle, lanes are needed regardless of transport. Because mcporter does one of two things:
Mcp-Session-Id
. My beautiful per-session isolation never engages — not because it's broken, but because from where my server stands, there There is no middle ground between those two without lanes. The collapse doesn't live in the transport choice. It lives in mcporter's client cache — one layer upstream of everything I had analyzed.
My "winning combo" framing wasn't a winning combo. Transport was never the variable that mattered.
I want to be precise about the failure, because it's a failure mode I suspect most maintainers share.
I verified my own layer exhaustively. I read my session map code before answering. I had literally shipped and tested the per-session mechanism that same week. Every claim I made about my server was true.
But "each client gets its own session" carries a silent assumption: that each agent is a distinct client. Whether that's true is decided by the middleware between the agent and my server — a layer I don't own, don't ship, and hadn't read. I reasoned about mcporter's topology by analogy ("a daemon per agent surely means a client per agent") instead of by its actual caching behavior.
The guarantee I was advertising was a chain: agent → runner → client cache → transport → my server → browser extension. I had audited exactly one link and pronounced the chain sound.
Here's the part that keeps this in the same family as the last post: the correction required zero lines of code, again.
My server's behavior was correct in both topologies. What was wrong was a paragraph in my README that framed lanes as a stdio-only concern. The fix (commit f12e5e3
) rewords it: if you're behind mcporter, you need lanes on any transport, because the client cache sits upstream of the transport choice.
One sentence. But a load-bearing sentence — it's the difference between the next user with this setup debugging a "broken" isolation feature for an afternoon, and them installing the right package in two minutes.
Your isolation guarantee is only as strong as the weakest layer between the user and you. And most of those layers aren't yours. Documenting a guarantee without naming its assumptions ("this engages if each agent presents its own session") is how correct code produces incorrect promises.
Public reasoning gets corrected while it's still cheap. I posted my topology analysis on the issue instead of just DMing a recommendation. That's the only reason the wrong mechanism lived for about a day instead of shipping into folklore. The user could quote my exact sentence back at me and point at the exact layer where it broke.
"I verified my layer" feels identical to "I verified the system." From the inside, the two are indistinguishable — both come with the same warm confidence. The only reliable tiebreaker I know is someone who actually runs the other layers. They had read mcporter's internals. I had read mine. Together we had read the system; separately, neither of us had.
I closed my last post saying the user solved their problem in the layer where it actually lived. Turns out my explanation had the same bug as the feature request: right idea, wrong layer.
Have you ever documented a guarantee your own layer couldn't actually promise — one that depended on middleware you don't control? How did you find out?