Last week I got the best feature request my open-source project has ever received. It was detailed, technically literate, fail-closed by design, and came from someone who clearly runs the tool harder than I do.
I'm not going to build it. And the person who asked for it agrees — because the conversation ended with him shipping the fix, in his own layer, as a package other people can now use.
I want to walk through how that happened, because the whole arc is a case study in a question I think we ask too rarely: not "how do I implement this?" but "where does this concern actually live?"
My project is safari-mcp, an MCP server that lets AI coding agents drive the real Safari on macOS — your session, your logins, your tabs. Which is exactly what makes concurrency dangerous: if two agents share one browser, "the active tab" is a loaded gun.
The issue, from a user running parallel AI agent sessions against his everyday Safari, asked for isolated tab lanes: each concurrent client gets stable ownership of its own tab, explicit targeting, and — his words, and the best phrase in the whole thread — behavior that never falls back to whatever tab is in front, because the front tab is usually the human's.
Five concrete asks. A design sketch. Fail-closed semantics specified up front. Feature requests do not get better than this.
My first instinct was to answer from the roadmap. I made myself read the source instead, and the result was uncomfortable: three of his five asks had already shipped. Per-session tab state keyed by MCP session id. Tab identity by a marker stamped into the page, not by index, so it survives navigation and tab reordering. And the fail-closed refusal he asked for existed nearly verbatim — the codebase literally prints "refusing to fall back to 'current tab of window' (would target the user's active tab)."
He's a competent engineer who read the README carefully and reasonably concluded none of this existed. That's not his failure. All of it was documented only in a design doc the README never linked. A capability nobody can discover is indistinguishable from a capability you never built — so the first "feature" I shipped from this thread was a README section.
Then his follow-up made it better. He dug into why isolation wasn't engaging in his setup and found that in shared-daemon mode, every client's browser-extension traffic carried the same process-wide session id — so the extension saw all clients as one session, and one client could be served another's cached tab.
He was right. I verified it in the source, shipped the fix the same day, and his name is in the release notes. A feature request that produces a shipped bugfix has already paid for itself. But the main course was still on the table.
His remaining gap was real: his client tooling multiplexes several agent sessions through one connection pool, collapsing them into a single MCP client — so per-session isolation, which keys on the client boundary, never gets a chance to engage. His proposal: a laneId
parameter on every tool call, required, fail-closed, routed into the existing session map.
Here's the trap: internally, this was almost free. The per-session state machinery already existed; running each call in a lane-scoped context would have reused it nearly unchanged. When a feature is one afternoon away, "cheap to build" starts masquerading as "right to build."
But the cost wasn't in the implementation. The server exposes 97 tools, and a required laneId
means 97 tool schemas grow a parameter — every schema an agent reads, every byte of context it burns, in every single-client setup that will never have two clients. A multi-client concern would leak into everyone's single-client API, forever. Schemas are the one part of an MCP server you can't refactor quietly later.
So I did the annoying thing: I said I liked it, wrote down exactly how it would be built and gated if ever needed — and held the build. Publicly. In the issue. Which felt like stalling, right up until it turned out to be the move that mattered.
Look at the shape of the problem again. The isolation wasn't missing from my server — it was being erased upstream, by the layer that collapsed N agent sessions into one client. Asking my server to add lanes was asking the downstream layer to compensate for something the upstream layer destroyed.
He reached the same conclusion, went looking in his own stack — and found his multiplexer already had per-instance isolation knobs. Then he did the genuinely great thing: instead of a private workaround, he built and published an extension that gives each of his agent sessions its own daemon directory — its own connection, its own server process, its own lane — with a composite lane key for the concurrency edge cases and an idle timeout so processes don't pile up.
It's not specific to my project. It works for any stateful MCP server behind that multiplexer. The fix landed in the layer that owned the problem, and it landed as infrastructure other people can reuse.
Final tally for the "rejected" feature request:
laneId
, on the record, buildable in a day if the need ever materializesYAGNI usually gets framed as refusal — a door closed in the requester's face. Done right, it's redirection: the effort didn't disappear, it moved to where it belonged, and the ecosystem ended up with more than my feature would have delivered. The best code review I ever got was a feature request. The best feature I shipped last week was a link to someone else's package.
What's the best feature request you've ever declined — and did saying "not here" ever produce something better than building it would have? I'd genuinely like to hear the counter-examples too: the time you held the line on YAGNI and it turned out you did need it.