DEV Community: אחיה כהן

I Logged Every AI Crawler for 34 Days. ChatGPT Outreads Googlebot

אחיה כהן — Sun, 16 Aug 2026 09:40:07 +0000

In mid-July, my Google clicks in my home market (Israel) dropped by almost half. Buyer-intent queries that used to bring steady leads just evaporated from Search Console. While I was staring at GSC dashboards trying to figure out what broke, I finally did the thing I should have done months earlier: I stopped looking at dashboards and started reading raw server logs.

What I found there was a parallel universe. Google Search was sending me less than ever — but AI systems were reading my site constantly. Not "someday this will matter" constantly. Right-now constantly: an AI assistant was fetching a page of mine roughly every 26 minutes, around the clock, because a real human had just asked it a question.

So I built a small log analyzer and let it run. Here's what 34 days of complete Caddy logs from a small business site (about 70 real human visitors a day) actually look like.

The numbers

All counts are HTTP 200 responses only (more on why below), over 34 days:

Bot	Requests	Per day	What it is
bingbot	5,444	158.2	Bing's index — which feeds ChatGPT
ChatGPT-User	1,388	40.3	Live fetch while a human asks ChatGPT
Googlebot	1,233	35.8	Classic Google crawl
GPTBot	547	15.9	OpenAI training crawler
Claude-User	519	15.1	Live fetch while a human asks Claude
OAI-SearchBot	281	8.2	ChatGPT search indexing
Applebot	268	7.8	Apple (Siri / Apple Intelligence)
ClaudeBot	214	6.2	Anthropic training crawler
Amazonbot	136	4.0	Amazon (Alexa & co.)
PerplexityBot	103	3.0	Perplexity indexing

Three things in that table genuinely surprised me.

ChatGPT-User outreads Googlebot. 40.3 fetches a day versus 35.8. This isn't a crawler building an index for later — ChatGPT-User is the user-agent OpenAI sends when a human is mid-conversation and ChatGPT decides to pull a live page to answer them. On my site, that now happens more often than Googlebot visits. For a tiny business site in a niche market, I did not expect that.

Bing crawls 4.4x harder than Google. 158 requests a day versus 36. Nobody optimizes for Bing. Bing's referral traffic is a rounding error. But Seer Interactive found that 87% of SearchGPT's citations match Bing's top organic results (versus 56% for Google) — Bing's index is a structural input to what ChatGPT can retrieve and cite. Suddenly that 4.4:1 ratio reads very differently: the "irrelevant" search engine is the supply chain for the assistant that's actually fetching my pages 40 times a day.

Live retrieval is the biggest AI bucket that matters. Grouping by meaning rather than by bot name:

🔴 Live user retrieval (a human asked right now)   1,907  (~56/day)
🔎 AI-search indexing (OAI-SearchBot, Perplexity,
   bingbot, Applebot)                               6,096  (~177/day)
📚 Training crawls (GPTBot, ClaudeBot, Amazonbot)     897  (~26/day)
🌐 Classic Google                                   1,233  (~36/day)

1,907 live retrievals in 34 days. Each one of those is a moment where a real person asked an AI assistant something, and the assistant chose my site as a source. That's the leading indicator for citations — and it's the number I now track weekly.

What they actually read (this is the useful part)

Per-bot top pages turned out to be more interesting than the totals:

ChatGPT-User loves the homepage (115 fetches), a WhatsApp automation guide (108), and — third place — our WhatsApp bot pricing guide. People are asking ChatGPT what a WhatsApp bot costs, and ChatGPT is pulling my pricing page to answer them. That's a sales conversation I'm part of without knowing it.
Claude-User is obsessed with exactly one post: a spam-detection write-up got 233 of its 519 total fetches — 45% of everything Claude reads on my site is one article. One strong, specific technical post apparently becomes a go-to source for one assistant.
GPTBot (the training crawler) spends its time on /signin and /forgot-password. Twelve visits to my login page. Enjoy the training data, I guess.
Perplexity-User: zero. PerplexityBot indexes me (103 requests), but not a single live user-triggered retrieval in 34 days. Every assistant has its own taste in sources, and Perplexity's taste apparently doesn't include me. Yet.

Methodology, and the trap that almost ruined the data

The analyzer is ~60 lines of Python that runs over Caddy's JSON access logs. The core is just user-agent patterns with one ordering rule — the *-User patterns must be matched before the generic bot patterns, because the loop stops at first match:

BOTS = {
    "ChatGPT-User":    re.compile(r"ChatGPT-User", re.I),   # live retrieval
    "Claude-User":     re.compile(r"Claude-User", re.I),    # live retrieval
    "Perplexity-User": re.compile(r"Perplexity-User", re.I),
    "OAI-SearchBot":   re.compile(r"OAI-SearchBot", re.I),
    "GPTBot":          re.compile(r"GPTBot", re.I),          # training
    "PerplexityBot":   re.compile(r"Perplexity", re.I),
    # ... bingbot, Googlebot, ClaudeBot, Applebot, Amazonbot
}

The trap: count only HTTP 200s. My first version counted every request, and the numbers were inflated with garbage — security scanners spoof OpenAI user-agents (a scanner claiming to be GPTBot while probing for /wp-admin on a site that doesn't run WordPress) and land on 404s. Filtering to 200-only removed the impostors and left actual content fetches. If you run this on your own logs and skip that filter, your "AI traffic" will be part vulnerability scan.

Why your analytics can't see any of this

None of these 8,900 AI-related requests appear in GA4. No JavaScript execution, no consent banner click, no pageview event. And it's worse than that: on my site, GA4 undercounts humans by roughly 9x too — only ~11% of visitors accept the cookie banner (I measured this two independent ways over 11 days: ~780 real browser visitors in the logs and widget-loads, 89 in GA4).

So the fastest-growing reader of my site — AI assistants answering buyer questions in real time — is completely invisible unless you read server logs. If your hosting gives you raw access logs, that's where this story lives. If it doesn't, you can't see it at all, and you might be making content decisions while blind to a quarter of your real readership.

What I'm doing differently now

Watching *-User agents weekly, not rankings daily. Live retrievals are the citation pipeline.
Taking Bing seriously for the first time in my life. Bing Webmaster Tools went from "never opened it" to the top of this week's list — if 87% of ChatGPT citations flow through Bing's index, it's the cheapest GEO lever there is.
Writing more single-topic, specific pages. Claude's 233-fetch obsession with one spam-detection post convinced me: assistants latch onto pages that answer one question thoroughly, not pillar pages that answer twelve questions shallowly.

Now I want your denominator. Pull one month of access logs and count bingbot vs Googlebot hits — my ratio is 4.4:1. If you run a small site, especially a non-English one, I'd genuinely like to know whether that ratio holds outside my niche: drop your two numbers (and your site's language) in the comments.

I said my tool supported multiple instances. A stranger running 15 of them filed three bugs. All three were right.

אחיה כהן — Thu, 13 Aug 2026 08:20:51 +0000

I maintain safari-mcp, an MCP server that lets AI agents drive a real Safari session on macOS. Over a few releases this summer I shipped per-session tab isolation — the feature that lets several agents share one browser without stealing each other's tabs. I wrote about it here. Twice. I was reasonably proud of it.

Then a stranger showed up with a deployment I had never imagined — three macOS profiles, up to fifteen concurrent server instances — and filed three bug reports in the space of seven seconds.

All three were right.

The reports

What made them remarkable wasn't just the hit rate. It was the form. Each issue had a description of the deployment, a repro, and observed data from their own machines. No speculation, no "it feels flaky." They had read the code, formed a hypothesis about where it breaks at their scale, and then watched it break exactly there.

Bug 1: the memory guard that guarded nothing. The server has a WebKit memory monitor that sweeps idle tabs before Safari's content process balloons. It also has a gate: only the instance acting as "extension host" — in practice, whichever instance won the race for port 9224 — was allowed to sweep, and only its own tabs. In a fifteen-instance deployment, that means fourteen instances accumulate tabs forever and one instance politely cleans up after itself. The guard was effectively inert precisely in the topology where memory pressure is worst.

The embarrassing part: the gate was redundant. There was already a lock file guaranteeing one sweeper per cycle. Someone (me) had added a second safety mechanism on top of an existing one, and the second one broke the feature. The fix was a deletion.

Bug 2: the ownership file that ate its own entries. Instances record which tabs they own in a shared JSON file. The save path was read-at-startup, modify-in-memory, overwrite-on-save. Classic. With one instance, harmless. With fifteen, every save was a snapshot overwrite that silently dropped whatever the other fourteen had written in the meantime.

Note what this bug doesn't do: it doesn't crash, it doesn't touch the wrong tab, it doesn't log anything. Losing an ownership entry is fail-safe — a tab just stops being tracked. Which is exactly why it survived. Bugs that fail loudly get fixed in week one. Bugs that fail politely wait for someone to run fifteen instances and notice entries vanishing.

The fix was merge-on-write: union the disk state with local state, newest timestamp wins, with explicit removal deltas so deletions don't get resurrected by a stale peer. I considered a file lock and deliberately skipped it — the residual race window is sub-millisecond and fail-safe, and a lock adds a failure mode of its own. That tradeoff is written down in the code, next to the merge.

Bug 3: the poll that never backed off. When a profile's Safari window is closed, the server polls for it to reappear — a fixed 3-second interval spawning an osascript subprocess each time. Forever. Their logs showed the consequence: roughly 1,200 log lines and 1,200 subprocess spawns per hour, per idle instance. Multiply by fifteen.

The fix is the boring one you already know: self-scheduling backoff, 3s doubling to a 60s cap, reset on success. While fixing it I found a bonus bug the report hadn't mentioned — a trace log being written to __dirname, which for an npm package means inside node_modules. That file had been quietly growing inside an installed package directory the whole time.

What I actually learned

Your test topology is a claim about the world, and nobody peer-reviews it. I had tested multiple instances — on one profile, launched from one place, in small numbers. The reporter ran three profiles times five. Every one of the three bugs lived precisely in the gap between my topology and theirs. Not one was visible in mine. The tests were green the entire time; the suite passed 78/78 the morning the reports came in. Green tests verify the world you thought to simulate.

Fail-safe failures are the long-lived ones. All three bugs share a property: the system kept working. Memory got worse slowly. Entries vanished silently. Subprocesses spawned invisibly. If any of them had thrown an exception, they'd have died in code review. Design your failures to be loud, or accept that the quiet ones will be found by a stranger, years later, at a scale you didn't test.

Sometimes the fix is a deletion. The memory-guard bug existed because two safety mechanisms overlapped and the newer one strangled the feature. I didn't need to write cleverer coordination code — I needed to remove the redundant half. The diff that fixed the scariest-sounding of the three bugs was net negative lines.

A good bug report at foreign scale is free QA you could not have bought. I could not have afforded to stand up a fifteen-instance, three-profile deployment as a test rig for a feature I wasn't sure anyone used that hard. Someone built it because they needed it, then handed me the findings with repros. The only correct responses are fast verification, honest credit, and shipping the fix. All three fixes went out in one release the next day, each issue closed with a reply documenting not just what changed but which alternatives I rejected and why — including the lock I chose not to add.

That last part matters more than it looks. The reporter now knows the merge-on-write has a known, bounded, fail-safe race. The next person who hits something weird there won't start from zero — the reasoning is in the thread, not in my head.

The uncomfortable question

The feature worked. The story I told about it was, at my scale, true. It took someone else's production topology to reveal that "supports multiple instances" was really "supports the multiple-instance shapes I happened to try."

What's the biggest gap between your test topology and a user's real deployment that you've been bitten by — and did the bug fail loudly or politely?

An invisible character broke a security patch. Then it broke my review. Then it broke my review of the fix.

אחיה כהן — Sun, 09 Aug 2026 07:15:27 +0000

My open-source project, safari-mcp, got a security-hardening pull request from an automated scanner. The idea behind the patch was right. The patch itself un-parsed the codebase. Then the same defect infected my review of the patch, my review of the fix, and eventually the private note I wrote to remind myself to stop letting this happen.

This is a story about one character, told in three acts, and it ends with a rule I now apply to everything I publish.

The character

U+2028 LINE SEPARATOR (and its sibling U+2029 PARAGRAPH SEPARATOR) is a legal Unicode character that most terminals and editors render as a space, or as nothing at all.

In JavaScript it has two sharp edges:

In strings, it counts as a line terminator. If you build a single-quoted string by escaping only quotes and backslashes, a raw U+2028 in the payload can terminate the literal early. That is a classic injection vector, and it is what the pull request set out to fix. Legitimate concern, real hardening value.
In regex literals, the grammar forbids line terminators outright. A raw U+2028 between the slashes of /.../ is not a weird regex. It is a SyntaxError at parse time.

Keep both edges in mind. The first one motivated the patch. The second one is what the patch shipped.

Act 1: the patch that un-parsed the codebase

The PR extended my escaping helper to also escape \r, \n, U+2028 and U+2029. Seven lines added, one changed. The problem: the new .replace() calls embedded the raw characters inside regex literals, instead of the escape sequences \u2028 and \u2029.

My terminal renders U+2028 as a space. So the diff looked like it said .replace(/ /g, ...) — replace every space. That would be a different catastrophic bug. The truth was worse in a more interesting way: the file no longer parsed at all. node --check failed with a SyntaxError. The main server file imports that module, so the entire MCP server failed to start.

A security patch that prevents the server from running is, to be fair, extremely secure.

What caught it was not reading the code. It was refusing to trust rendering:

Python repr() on the raw diff showed the literal characters.
A fun tell: Python's splitlines() splits on U+2028, so a "one-line" regex was quietly two lines to Python.
node --check turned suspicion into proof.

I wrote all of that up in a REQUEST_CHANGES review, with a corrected snippet showing the right approach: put the ASCII escape sequence \u2028 in the source, never the raw character.

Act 2: my review had the same bug

I composed that review body in a shell heredoc. Heredocs pass Unicode through byte-for-byte. The corrected snippet I posted — the one teaching the contributor to use escape sequences — was posted with the raw characters in it, exactly where the ASCII text \u2028 was supposed to appear.

The review explaining the invisible-character bug contained the invisible-character bug.

I only caught it because, after posting, I fetched my own review body back through the API and ran repr() on it. Then I rebuilt the body in Python, constructing the escape-sequence text from character codes instead of typing it, and patched the review via the API.

Act 3: the fix was perfect. My approval was not.

The contributor fixed everything properly: escape sequences in the regex literals, a regression test that locks the full escaping recipe (backslash, quote, \r, \n, U+2028, U+2029 — in that order, so order drift fails the suite), and a documented behavior change. I verified it in a fresh clone at byte level. Full test suite green. I approved.

My approval review quoted those escape sequences. It posted with raw U+2028 in it. Again. Same failure, same detection (re-fetch, repr()), same API patch.

Epilogue: it kept going

The status row I wrote about the incident, in my own tracking file? Raw U+2028 in it.

The personal rule file I then wrote — literally titled "byte-verify anything that discusses this character" — was written to disk with two raw U+2028 bytes in it. The note about the disease was a carrier.

Four artifacts in two days. Every one of them was about the defect. Every one of them contained it.

Why this keeps happening

Text that discusses a character tends to contain that character. When I write about U+2028, some layer in the pipeline — text generation, a heredoc, an editor buffer, a clipboard — will happily emit the real code point where I intended the six ASCII characters that name it. Every layer treats it as ordinary printable Unicode and passes it through. Every renderer displays it as nothing.

So there is no natural checkpoint where the defect becomes visible. The character is only "visible" in a byte-level representation: repr(), a hex dump, an assertion. If your verification is "I looked at it and it looked fine," you have verified nothing — for this class of bug, looking is the one sense that cannot detect it.

It has a quine-like quality that I find genuinely funny now, several patches later: the document about the virus carries the virus.

The rules that survived

Never trust rendering for invisible characters. Verify bytes: repr() in Python, xxd, grep -P with the code point. Eyes are the wrong instrument.
Compose text about escape characters programmatically. I now build the string "\u2028" as chr(92) + "u2028" in a script. I do not type it into anything that will be published.
Assert before posting. assert chr(0x2028) not in body costs one line.
Re-fetch after posting and verify the published artifact. The pipeline between you and the platform can preserve what you thought you had stripped. Verify what readers actually see, not what you sent.
Your own artifacts are in scope. Byte-checking a stranger's diff is the obvious part. The review of the diff, the changelog entry, the tracking note, the article — those are artifacts too, and they are more likely to carry the character, because they talk about it.

The meta part

This article discusses U+2028 roughly thirty times. It was generated by a script that constructs every single mention from character codes and asserts that the raw bytes are absent before the file is written. After publishing, I fetched the live body back and byte-verified it.

Based on my track record of the last two days: if I had skipped any of that, you would right now be reading an article about an invisible character, carrying the invisible character.

What is the nastiest invisible-character bug you have hit — and did your tooling show it to you, or did you find it by accident? Zero-width joiners in usernames, BOMs at the top of config files, non-breaking spaces in YAML — I want to hear the war stories.

I gave a user the right answer with the wrong mechanism. They caught it within a day.

אחיה כהן — Tue, 04 Aug 2026 08:17:36 +0000

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.

The claim

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 own Mcp-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.

The correction

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:

Caches one MCP client and reuses it for every agent session. My server sees exactly one Mcp-Session-Id. My beautiful per-session isolation never engages — not because it's broken, but because from where my server stands, there is only one session. Every agent walks in wearing the same badge.
Creates a fresh client per call. Now there's no session continuity at all — each tool call is a stranger, and per-session state is meaningless in the other direction.

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.

Why I got it wrong

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.

The fix was one sentence

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.

What I'm taking from it

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?

A user spent four days designing a feature for my project. The right answer was zero lines of code.

אחיה כהן — Fri, 31 Jul 2026 11:12:44 +0000

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?"

The request

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.

Surprise one: most of it already existed

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.

Surprise two: the feature request found a real bug

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.

The proposal I liked and still didn't build

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.

Where the concern actually lived

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.

The scoreboard

Final tally for the "rejected" feature request:

A README section that made existing isolation discoverable, instead of documented-but-invisible
A real cross-client session bug found, verified, and shipped as a fix — credited to the reporter
A reusable extension, published by the user, solving the problem in the layer that owned it
A written-down design for laneId, on the record, buildable in a day if the need ever materializes
Zero lines of feature code in my repo

YAGNI 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.

I built a guard that refused to read the user's tab. Then my own cleanup code closed it.

אחיה כהן — Mon, 27 Jul 2026 06:40:34 +0000

Three days ago my browser automation tool closed one of my own tabs. Not a tab it had opened — a dashboard I had open in another window, with a page I hadn't finished reading.

What makes it worth writing up isn't the bug. It's that the guard designed to prevent exactly this had already fired, correctly, ninety seconds earlier.

The guard worked

Safari MCP lets an AI agent drive your real, logged-in Safari. That premise means the single worst thing it can do is act on a tab you're using. So there's an identity system: every tab the tool opens gets a marker stamped into window.name, which survives navigation, redirects, and cross-origin loads. Before running anything in a tab, the tool checks the marker.

I was filling in a form. The URL was a forms.gle shortlink, which 302s to docs.google.com — a cross-origin redirect that, it turns out, drops window.name. My next read came back refused:

Tab tracking lost — refusing to target the user's current tab.

Correct. Exactly the intended behaviour. The tool no longer knew which tab was its own, so it declined to guess.

So I did the tidy thing and cleaned up my orphaned tab:

safari_close_tab

It closed a different tab. One of mine. The tool went from "I can't prove which tab is mine, so I won't read" to "let me close a tab" in one step, and nobody stopped it.

The shape of the hole

Here is the close path as it existed:

if (_st().activeTabIndex) {
  await osascript(`... close tab ${_st().activeTabIndex} of ${window}`);
} else {
  await osascript(`... close current tab of ${window}`);  // ← the user's tab
}

current tab of window is whatever the user is looking at. So the fallback for "I don't know which tab is mine" was "close theirs."

That branch is only reachable when the index is unknown — which is precisely the state the guard had just announced. The two pieces of code were describing the same condition and disagreeing about what it meant.

Three layers, one mistake

When I went looking, the same fail-open was in all three layers of the stack, and it had the same shape every time: no ownership recorded was read as permission, not as refusal.

The first one is the most embarrassing, because it's a list:

const _noOwnershipCheck = new Set([
  // Tab management
  "new_tab", "list_tabs", "close_tab", "switch_tab",
  ...

A set of operations exempt from the ownership check, grouped under the comment "read-only or tab management". Three of those four are harmless: new_tab creates a tab, list_tabs reads, and switch_tab carries its own ownership check at the tool level. close_tab destroys a user tab and had no check anywhere.

It wasn't exempted by argument. It was exempted by category — it looked like tab management, it sat next to tab management, so it inherited tab management's safety assumptions. Nobody ever wrote down "closing a tab is safe." The list said it, silently, by adjacency.

The third layer, the browser extension, had a variant worth naming on its own. Its guard refuses an operation when the session owns tabs and this isn't one of them — but when the session owns nothing, it allows the operation, with this comment:

// If no tabs owned yet, allow operation (backward compatibility for sessions that don't use new_tab)

That leniency is sensible for a write: worst case it edits the page you're already on. For a close it's a disaster. And "owns nothing" is exactly what a session reports after its transport drops and the client re-initialises — mid-task, tab still open. The lenient branch is reachable only in the state where it's most wrong.

The rule I actually got wrong

My first instinct for the fix was to reuse the rule the read path already uses: refuse a tab carrying another session's marker, allow an unmarked one. It keeps "read the page I'm looking at" working for a session that genuinely never opened a tab.

That rule would not have prevented this. The tab I destroyed was a genuine user tab. It had no marker at all. Under "unmarked is fine", it sails straight through to tabs.remove().

Which forced the actual distinction: a wrong read costs information; a wrong close costs the user their work. They don't get the same rule. The read paths keep the lenient fallback on purpose. The destructive path gets no fallback whatsoever — it closes a tab it can positively prove it owns, or it throws:

const idx = explicitIndex || (await _provenOwnTabIndex());
if (!idx) {
  throw new Error(
    `Tab tracking lost — refusing to close a tab this session cannot prove it opened ...`
  );
}

No else. "Owns nothing" now means "closes nothing", which is the sentence that should have been in that first list all along.

A few adjacent things fell out of it. Blanking a window's last tab — the workaround for "closing this would quit Safari" — used the same fallback, and throwing away someone's loaded page is destructive too; it's pinned to the proven index now. And in the extension, the guard validated one tab (tabId) while the indexed branch removed a different one (_winTabs[index - 1]), so the check and the action were pointed at different tabs. That one had never fired in production; it was just waiting.

What I'd take from it

The guard wasn't wrong and the fallback wasn't wrong. What was wrong is that they were two different answers to one question — do we know which tab is ours? — living in two files, and only one of them had thought about what the answer implied.

I've since stopped trusting the word "safe" in a category name. close_tab was in a set called tab management, and the set was right: it is tab management. Categories describe what an operation is. Guards have to be about what it costs when it's wrong. Sorting by the first and inheriting the second is how a destructive call ends up on the exempt list with no one having decided that.

The test I wrote isn't behavioural, for the same reason as last time: the defect is a missing refusal on a path that only runs after state is already lost. There's nothing to exercise. It reads the source and asserts that no AppleScript verb in the close path targets the front document — and I checked that it fails when I put the old branch back, because a regression test you haven't seen fail is a guess.

Fixed in v2.15.8. The repo is safari-mcp — the full analysis is in issue #68.

A question for you: how do you catch the operations that got their safety assumptions by adjacency — the ones sitting in a list they only half belong to? Every review I've done reads the code in the branch, not the membership of the set above it.

I run an affiliate code. Seven fake ones outrank it — and Google's AI believes them.

אחיה כהן — Thu, 23 Jul 2026 12:01:27 +0000

Disclosure up front: I'm a Chatwoot affiliate. The links in this post are affiliate links, and the code I mention earns me a commission. That's exactly what this post is about, so it would be strange to bury it at the bottom.

Last week I did something I'd never bothered to do: I searched Google for my own affiliate code.

Google asked me if I meant "ACHIEVERS."

Two results came back, both from my own site. That's the entire web footprint of the code. Meanwhile, the first organic result for chatwoot coupon promises 70% off, and a page ranking for chatwoot discount code confidently tells you the code is START for 20% off.

Neither of those can be true, and the reason is arithmetic, not opinion.

The ceiling is public

Chatwoot publishes its affiliate terms on its own site:

"Refer businesses to Chatwoot Cloud and earn 20% of the revenue for the first 12 months. Your referrals get 5% off their subscription too."

That's the whole mechanism. A partner earns 20% of the revenue for a year; the person they refer gets 5% off. There is no tier that issues 20%, 50% or 70% to a referral, because there's no lever in the program that produces one.

So when I went looking, here's what's actually circulating as of July 2026:

Code	Claimed discount	Where
`START`	20% off	three separate blogs
`PINTU`	50% off	AI-generated article site
`KUMAR` / `MALIK`	60% off	startup directory, coupon aggregator
`SAVE55`	unspecified	LinkedIn "newsletter"
`GET50`	unspecified	YouTube short
`5OFFCODE`	5%	email-tools blog
—	"70% off", "$100 off"	coupon aggregators, no code attached

Only one of those is even in the right ballpark, and it isn't attached to a real referral account as far as I can tell.

The part that actually matters

Here's the thing I didn't expect, and the reason I'm writing this instead of shrugging.

I've been tracking whether Google's AI Overview names a specific code for these queries. One day it named mine across all three coupon queries I track. The next day — after no change on my end — it named none of them, and instead fell back to citing chatwoot.com for the generic fact that referrals get 5% off.

It got the fact right. It just wouldn't commit to a code.

When I looked at the source distribution, the reason was obvious. Every fake code sits on 8+ independent domains. Mine sits on one. An LLM asked "what's the real code" is doing something closer to counting witnesses than checking arithmetic — and by that measure, seven fabrications beat one accurate source.

This is the uncomfortable version of the "AI search rewards authority" advice everyone repeats. It doesn't reward being right. It rewards being corroborated. Those are different things, and coupon spam is the cleanest natural experiment I've seen for the gap between them.

Why coupon spam is structurally good at this

Fake discount content has properties that make it unusually effective against retrieval-based systems:

It's cheap to generate. A "verified 2026 promo code" page is a template. One prompt produces fifty.
It's unfalsifiable at read time. A crawler can't try the code at checkout. Neither can an LLM.
It's mutually reinforcing. Aggregators scrape each other, so a single fabrication propagates into what looks like independent confirmation.
Nobody corrects it. The vendor doesn't chase coupon sites, and the affiliate who'd care is one voice against a dozen.

The honest actor is structurally disadvantaged. I can say the real number is 5%, but I can only say it once, from one domain.

What I did about it

Three things, none of them clever:

Said the number plainly and named the fakes. My Chatwoot vs Intercom comparison now lists START, PINTU, KUMAR, MALIK, SAVE55, GET50 and 5OFFCODE explicitly and explains why each is inconsistent with the published program terms. Naming them is the part that matters — "there are fake codes out there" is unquotable; "START doesn't work because the ceiling is 5%" is a sentence a model can lift.

Quoted the primary source instead of paraphrasing it. Chatwoot's own affiliate page is the authority on Chatwoot's affiliate terms. Linking it beats asserting it.

Stopped splitting my own signal. I had four different affiliate codes across my site, one per content category, because I wanted to know which content converted. That experiment finished — one code produced everything, the other three produced nothing in three weeks — so I collapsed them into one. Four competing answers on one domain is a weaker signal than one answer repeated, and I'd been doing it to myself.

I don't know yet whether any of it moves the needle. That's the honest ending.

If you actually want Chatwoot

Since it would be silly to write all this and be coy:

Self-hosting is free. The Community Edition has no agent cap and no conversation cap. If you're comfortable with Docker, you do not need a discount code, because there's nothing to discount. This is genuinely what I'd recommend to most people reading dev.to.
The hosted version has a free tier for up to 2 agents, then starts at $19/agent/month.
If you go hosted, the working code is ACHIYAVS for 5% off at Chatwoot Cloud, and yes, I earn a commission on it. On the $19 tier that discount is about $0.95 per agent per month. It is not a reason to choose anything. Take the 15-day trial first.

I'd rather tell you the code is worth a dollar than tell you it's worth 70% and waste your time at checkout.

If you want to reproduce the measurement: search your own brand or code in quotes with &nfpr=1 appended to the Google URL to disable autocorrect, logged out. The number of distinct domains that come back is the number the models are effectively counting.

My fix for a data-loss bug sat in a green PR for four days. Every install in that window still had the bug.

אחיה כהן — Tue, 21 Jul 2026 11:12:56 +0000

On July 17 I opened the most serious issue my project has ever had, wrote the fix the same morning, and pushed it as a pull request. CI went green on Node 20, 22 and 24 within minutes. Zero review comments. mergeStateStatus: CLEAN.

Then it sat there.

I merged it today — July 21. Four days.

For those four days the fix existed, was correct, was tested, and was visible to nobody. Every npx safari-mcp in that window installed the version with the bug. The npm counter says roughly 1,400 people a week pull this thing. The fix was done and the users still had the bug, and those two facts sat side by side without touching each other.

I want to be precise about why, because the interesting part isn't "I was busy."

The bug, briefly

safari-mcp lets an AI agent drive the Safari you're already logged into. That's the value and that's the danger: you're using the browser at the same time as the agent. The one promise the project makes is the agent never touches a tab it didn't open.

That promise had a hole. When the tracked tab index ran past the end of the window — you closed a tab, or tore one into its own window — the resolver clamped the index to the last tab:

if (_st().activeTabIndex && _st().activeTabIndex > tabCount) {
  console.error(`[Safari MCP] Tab ghost proactive fix: clamping to ${tabCount}`);
  _st().activeTabIndex = tabCount;
}

The last tab in the window is not our tab. It's whatever you happen to have open there. So at the exact moment the code discovers it no longer knows where its tab is, it points the session at one of yours — and logs the words "proactive fix" while doing it.

The fix is four lines: fail closed. Drop ownership, return null, let the next call open a fresh tab.

Small diff. Green CI. Four days.

What actually held it

Not review capacity. I'm the only reviewer; there was no queue.

Not risk. The change makes an unsafe path safe; the worst case of shipping it is that the agent opens a redundant tab.

What held it was that merging was the fourth step of a five-step ritual and only the first step was automated. Merge, bump version, write the changelog entry, cut a GitHub release, and only then does the Publish workflow fire and npm gets the fix. Steps 2–4 are me, at a keyboard, in a mood to do release chores.

CI told me the code was good. Nothing told me the code was stuck. Those are different signals and I only had one of them.

The tell I ignored

Here's the part that made me write this instead of quietly shipping.

While cutting today's release I opened CHANGELOG.md and found the previous release, v2.15.3, had no entry at all. Shipped July 15. The release commit touched exactly two files: package.json and package-lock.json.

Three real fixes went out that day — clicks landing on the wrong tab, ARIA combobox typeahead never loading, a focus-helper queue that poisoned itself after a timeout, the last one contributed by an outside developer. Anyone reading the changelog to decide whether to upgrade saw nothing between 2.15.2 and 2.15.4. The contributor's fix was invisible.

I didn't skip that entry on purpose. I skipped it because it's step 3 of the same manual ritual, and step 3 has no test.

So the pattern isn't "a PR was slow." The pattern is: the parts of shipping that a machine watches are reliable, and the parts that only a human watches decay — silently, and in the same direction every time. My CI has 57 tests. My release process has zero.

The uncomfortable comparison

There's a well-worn instinct in solo open source that goes: don't automate the release, you'll ship something bad by accident. Manual = careful.

I believed that. Look at what manual actually bought me:

	Automated	Manual
Code correctness	57 tests, 3 Node versions	—
Packaging	`packaging.test.mjs` fails CI if an imported file isn't published	—
Registry sync	server.json version synced + published on release	—
Merge decision	—	4-day gap
Changelog entry	—	silently missing
Cutting the release	—	mood-dependent

Every column with a machine in it held. Every column with only me in it drifted. The "careful" half is the half that failed, and it failed quietly, which is worse than failing loudly.

The honest version of the instinct isn't manual is careful. It's manual feels careful because you were paying attention at the moment you did it, and you have no record of the moments you weren't.

What I'm changing

Not full auto-release-on-merge. I still want a human deciding when a release exists, because "these three fixes belong together" is a judgment call and I don't have a robot with taste.

What I want is for the gaps to be loud:

A changelog check in CI. If the diff touches safari.js or index.js and doesn't touch CHANGELOG.md, CI complains. That's the test step 3 never had. It's ten lines and it would have caught the 2.15.3 hole on the day it happened.
A stale-green-PR alarm. Any PR that is CLEAN + passing + zero-review-comments for more than 48 hours gets surfaced, loudly, wherever I'll actually see it. Not to force a merge — to make "still holding this" a decision I re-make rather than a default I drift into.
Release notes generated from the changelog, so the GitHub release and the changelog can't disagree — one source, two renders.

None of that is clever. That's the point. The failure wasn't clever either.

The thing I'd actually generalize

If you maintain something alone, look at your last five releases and ask a narrow question: which steps between "merged" and "a user can install it" have no automated observer?

Not "which steps are manual" — plenty of manual steps are fine. Which manual steps would fail without producing a symptom you'd notice.

A missing changelog entry produces no error. A green PR sitting for four days produces no error. A release you didn't cut produces no error. They produce the absence of something, and absence doesn't page anybody.

My whole test suite is built to catch code that does the wrong thing. Not one of those 57 tests can catch code that does the right thing where nobody can reach it.

v2.15.4 is on npm now — the tab-index path fails closed, and the 2.15.3 changelog entry has been backfilled. Source: github.com/achiya-automation/safari-mcp

What's the gap in your pipeline that has no observer? I'm genuinely collecting these — the ones I find myself are always the boring ones, and the interesting ones seem to come from other people's setups.

I filed a critical bug against my own tool. Then I read the code — and my own root cause was wrong.

אחיה כהן — Fri, 17 Jul 2026 07:19:32 +0000

Three days ago I filed the most serious issue my project has ever had — against myself.

The tool is safari-mcp, an MCP server that lets an AI agent drive the Safari you're already logged into. That premise is the whole value proposition, and it's also the whole danger: the user is using this browser at the same time as the agent. The single promise the project makes is "the agent never touches a tab it didn't open."

The issue was that the promise had broken. Two of a user's tabs ended up displaying pages the agent had loaded. Nothing was closed — the back-history survived — but scroll position, in-page state, anything unsaved: gone.

I wrote up the incident, traced the root cause, and proposed a fix. Then today I opened the file to actually write that fix.

My root cause was wrong. The fix I proposed had already shipped, three months ago. And the real bug was sitting four lines below it, wearing the word "fix" in its own log message.

What I claimed

Here's what I wrote in the issue:

_ownedTabs (and every tabIndex parameter) is a positional handle to a mutable, user-controlled list. Positional handles are only valid as long as nobody else mutates the list.

And the proposed fix:

Track ownership by a stable identity, not a position. On safari_new_tab, inject a sentinel into the page (e.g. window.__safariMcpTabId = "<uuid>"), and resolve tabIndex → real tab by scanning windows for the matching sentinel.

Confident. Specific. Reasonable. I even left a follow-up comment calling the sentinel design "the plan of record."

I wrote all of that from my memory of the architecture. I did not open safari.js.

What was actually in the file

The sentinel already existed. It had been there since v2.8.3, released April 14 — a release literally titled "bulletproof tab tracking via window.__mcpTabMarker."

// ========== TAB IDENTITY MARKER ==========
//  - window.name           : survives EVERY navigation (full loads, redirects,
//                            cross-origin). The browser preserves window.name by
//                            design — the bulletproof identity that index/URL lack.
//  - window.__mcpTabMarker : survives SPA / same-document routing (secondary marker).

I had written the fix I was now proposing. I'd written the comment explaining why it was the right fix. I'd forgotten I'd done it.

So the interesting question stopped being "why is ownership positional" — it isn't — and became "if identity resolution is already there, how did a user's tab still get navigated?"

Three exits, one of them guesses

resolveActiveTab() is the function that answers "which tab is ours, right now?" It has a strategy ladder, and what matters is how each rung fails.

Rung 1 — the marker scan. Loop every tab, ask each one whether window.name matches our marker. Found it? That's our tab, whatever index it's sitting at. This is identity, and it's correct.

Rung 2 — no URL to fall back on:

if (_st().hasOwnedTab && !_st().activeTabMarker) { _st().activeTabIndex = null; }

Identity lost → drop the index. Fails closed. ✅

Rung 3 — the URL scan comes back empty:

if (_st().hasOwnedTab && !_st().activeTabMarker) {
  console.error('[Safari MCP] Tab identity lost (marker + URL unresolved) — clearing index to avoid targeting the user\'s tab');
  _st().activeTabIndex = null;
  return null;
}

Same call, same instinct. Fails closed. ✅

And then, four lines later, in the same block:

if (_st().activeTabIndex && _st().activeTabIndex > tabCount) {
  console.error(`[Safari MCP] Tab ghost proactive fix: index ${_st().activeTabIndex} > tabCount ${tabCount}, clamping to ${tabCount}`);
  _st().activeTabIndex = tabCount;
}

Read that carefully, because I didn't for three months.

We tracked tab 8. The window now has 7 tabs — because the user closed one, or tore one into its own window. Our index is out of range. That is the exact moment the code has learned it no longer knows where our tab is.

And it responds by clamping the index to tabCount: tab 7. The last tab in the window. A tab we have never seen, that belongs to the user, chosen for no reason other than that it's the highest index that won't throw.

Then it logs the words "proactive fix."

That's the bug. Not positional ownership — a fail-open sitting between two fail-closed branches, in the safety-critical path, describing itself as a fix.

How it got there

git log -S puts the clamp at March 31. The identity marker landed April 14.

The clamp is two weeks older than the mechanism that made it obsolete. It's from the era when the index was genuinely all we had, when "out of range" produced ugly AppleScript errors and clamping made them stop.

And that's the actual lesson, the one that generalizes past my weird little macOS project:

When you add a better mechanism, the old heuristic does not remove itself.

The v2.8.3 work added identity resolution and correctly rewired the branches it was looking at — the two hasOwnedTab && !activeTabMarker guards are the new thinking, and they fail closed because in April I understood the stakes. The clamp wasn't rewired, because it didn't look like an ownership decision. It looked like input validation. It looked like the careful line. It had a bounds check and an error log.

Every upgrade leaves fossils like this. The dangerous ones aren't the code that looks scary. They're the code that looks like it's on your side.

"Proactive fix" is a confession

Here's the tell I want to hand you, because it's cheap and it's reusable.

The clamp was written to fix a symptom: an index pointing past the end of the array. It makes that symptom disappear by inventing a plausible value. tabCount isn't a computed answer to "where is our tab" — it's the nearest number that doesn't crash.

Any code that converts "I don't know" into a plausible value is a fail-open wearing a fix's clothes.

Once you have that phrasing, you start seeing them everywhere. ?? 0 on a total that should have been fetched. catch {} around the call that establishes permission. || user[0] when the lookup missed. Clamping an index into range. Each one takes a state where the honest answer is stop and launders it into a value the next line will happily use.

The bounds check is real. The clamp is the bug. They're on the same line, and that's exactly why it survived three months of me reading past it.

What the fix actually is

It's a deletion, not the sentinel architecture I proposed. That branch has to do what its two neighbours already do — when the index is out of range, identity is lost, so drop it and make the caller re-anchor:

if (_st().activeTabIndex && _st().activeTabIndex > tabCount) {
  _st().activeTabIndex = null;   // fail closed, like every other exit
  return null;
}

Callers already handle this. There's a _assertNotFallingBackToUserTab() that throws a clear "Tab tracking lost — re-run safari_new_tab to recover". The recovery path was built. The clamp was just routing around it.

The cost is honest: sessions that used to get lucky will now throw. In a tool whose entire promise is "we don't touch your tabs," an error message is the correct output for "I don't know which tab is mine." A guess is not.

It's PR #59, open against issue #54 — where I've also left my original root-cause analysis standing, wrong, with a correction under it. The drift between what I remembered and what shipped is the bug; editing the evidence out seemed like the wrong move.

The part I keep thinking about

I filed a detailed, confident, well-structured bug report about code I wrote, and got the root cause wrong — because I reasoned from my mental model instead of from the file. The mental model was a year of accumulated intent. The file was what actually shipped. Those had quietly drifted apart, and the gap between them is precisely where the bug lived.

If I'd handed that issue to an AI agent — or a new contributor — they'd have implemented the sentinel I asked for. Diligently. It already existed. The clamp would still be there, and the user's tabs would still be getting navigated, and the issue would be closed.

The most expensive thing in that whole chain was my confidence.

Have you found one of these in your own code — a "fix" that was actually inventing an answer? I'd genuinely like to collect the pattern. Drop it in the comments.

safari-mcp is MIT-licensed and drives your real, logged-in Safari on macOS. It has 97 tools, and — once #59 lands — one fewer place where it guesses which tab is yours.

A stranger fixed my bug. Then I found out he fixed the wrong half — and it still worked.

אחיה כהן — Sun, 12 Jul 2026 07:16:34 +0000

Someone opened a pull request against my Safari MCP server last week. Three functions, same treatment each, clean write-up, all CI green. It fixed a real bug — his repro was solid, mine reproduced it too.

Then I sat down to write it up, built a 40-line model of the thing to make sure I understood it, and discovered that half of his patch does nothing at all. Not "does something subtle." Nothing. The two hunks he described as the fix are behaviorally identical to the code they replace.

The half he didn't emphasize is the one that closes the bug. And the reason neither of us could tell — the reason I couldn't tell about my own code — turns out to be the actual story here.

The protocol: positional, ID-free, and one mistake from disaster

My server talks to a small Swift helper for the things JavaScript can't do on a Mac: focus an app, hide a window, synthesize a real OS-level click. Newline-delimited JSON over stdin/stdout. Request and response are correlated positionally — there are no request IDs:

const _helperQueue = []; // callbacks waiting for responses

_helperProc.stdout.on("data", (chunk) => {
  _buf += chunk.toString();
  const lines = _buf.split("\n");
  _buf = lines.pop();
  for (const line of lines) {
    if (!line.trim()) continue;
    const cb = _helperQueue.shift();   // first reply belongs to first waiter
    if (cb) cb(line);
  }
});

This works exactly as long as one invariant holds:

Every callback in the queue corresponds to a request that was actually sent and whose reply is still coming.

Violate that once and the queue is off by one. Reply N goes to waiter N+1. Forever — there is nothing in the protocol that can ever resynchronize it. And because every waiter is a setTimeout-guarded promise, the symptom is never an error. It's a hang.

The two ways to abandon a request

A helper call looks like this (this is the real pre-fix code, lightly trimmed):

function _helperGetFrontApp(timeout = 2000) {
  return _withHelperLock(() => new Promise((resolve) => {
    let resolved = false;

    const timer = setTimeout(() => {
      if (!resolved) { resolved = true; resolve(null); }        // path 1: gave up waiting
    }, timeout);

    function cb(line) {
      if (resolved) return;
      resolved = true;
      clearTimeout(timer);
      resolve(line.trim());
    }

    _helperQueue.push(cb);                                       // ← pushed BEFORE the write
    try { _helperProc.stdin.write('{"getFrontApp":true}\n'); }
    catch { clearTimeout(timer); resolve(null); }                // path 2: write blew up
  }));
}

There are two ways to walk away from a request, and they are not the same, which is the whole point:

Path 1 — the timeout. The helper is slow; we stop waiting. But a reply is still coming. The dead cb stays in the queue, gets shifted when the late line lands, sees resolved === true, and returns without touching anything. It ate exactly one line — which is precisely correct, because exactly one line was owed. The queue stays aligned.

Path 2 — the write failure. stdin.write throws (broken pipe: the helper died between our last call and this one). The request was never sent, so no reply is ever coming. But look at the catch: it calls resolve(null) and never sets resolved = true. So cb is still sitting in the queue, and it's still armed.

The next request comes in. Its reply arrives. shift() hands it to the armed corpse of a request that was never sent. resolved is false, so it consumes the line, resolves a promise nobody is listening to, and the caller who actually sent a request gets nothing — it waits out its full timeout, and leaves its own callback behind when it does.

That's not an off-by-one. That's a cascade. One failed write poisons the channel for the lifetime of the daemon.

Proving it instead of believing it

I've been wrong about my own concurrency code before, so I stopped arguing with myself and modeled it — a positional queue, the same resolved guard, the two abandonment paths, pre-fix and post-fix:

PRE-FIX   timeout   → B got: reply-to-B     ← already correct!
PRE-FIX   writefail → B got: TIMEOUT(B)     ← B's reply eaten by A's armed callback
POST-FIX  timeout   → B got: reply-to-B
POST-FIX  writefail → B got: reply-to-B     ← fixed

There it is. The timeout path was never broken. The patch's headline change — replacing the abandoned callback with an explicit no-op consumer:

const idx = _helperQueue.indexOf(cb);
if (idx >= 0) _helperQueue[idx] = () => {};   // no-op consumer for the late reply

...replaces a callback that was already a no-op consumer (because cb self-guards on resolved) with a callback that is visibly a no-op consumer. Zero behavior change. It's a comment that happens to compile.

The fix is the other hunk, the quiet one in the catch:

catch {
  const idx = _helperQueue.indexOf(cb);
  if (idx >= 0) _helperQueue.splice(idx, 1);   // never sent → nothing is coming → drop the slot
  clearTimeout(timer);
  resolve(null);
}

And note that the two hunks do opposite things — one keeps the slot, one removes it — for reasons that are entirely non-obvious unless you have the positional invariant in your head. Swap them and you've built a worse bug than the one you set out to fix: splice on timeout means the late reply gets shifted onto the next caller, who now gets someone else's answer and believes it. He got that distinction right in both directions, on his first try, in code he didn't write. That's the part I'm actually impressed by.

The reason nobody could see it

Here's what I found when I grepped my own file for this pattern. Seven helper functions. Every one of them open-codes the same request/timeout/queue dance. Four carry some version of the no-op-consumer line:

764:  if (idx >= 0) _helperQueue[idx] = () => { _helperConsecutiveTimeouts = 0; }; // late reply ⇒ alive
825:  if (idx >= 0) _helperQueue[idx] = () => {};   // no-op consumer for a late reply
863:  if (idx >= 0) _helperQueue[idx] = () => {};   // No-op consumer for late response
912:  if (idx >= 0) _helperQueue[idx] = () => {};

Three don't. Those three are exactly the three he patched.

So the honest reading isn't "I forgot the fix in three places." It's worse and more interesting: I wrote a defensive line four times without ever writing down what it defends against, and in the three functions where I skipped it, the code was accidentally fine anyway — while a genuinely broken path sat two lines below, in every single one of the seven.

The invariant — an abandoned slot must consume exactly one reply, unless nothing was ever sent — is stated in exactly zero of those seven functions. Not in a comment, not in a name, not in a type. It lives only in whatever I happened to be holding in my head on the afternoon I wrote each one. A contributor reading this file has no way to check his patch against the rule, because the rule isn't there. He had to reconstruct it from the wreckage — and he reconstructed it correctly, which is why his catch hunk lands even though his description of why doesn't.

That's the failure. Not the missing line. The missing place to put the line.

Copy-paste isn't a style problem, it's a memory problem

I don't care much about DRY as an aesthetic. A little duplication beats a bad abstraction, and I'll take three copies of a five-line function over an inheritance hierarchy every day of the week.

But that argument is about code you can see. This is about something else:

A rule that exists in N copies has to be re-derived from scratch by whoever writes copy N+1 — including you, next year, at 11pm.

Seven functions, seven independent recollections of an unwritten rule. I got the cosmetic half right four times out of seven and the load-bearing half wrong seven times out of seven. That is not a discipline problem you fix by being more careful. It's a coin flip you have to win every time, forever, and the odds get worse with every function added.

The correct shape was always one function:

// The helper protocol is POSITIONAL — replies are matched to requests by queue order,
// not by id. So an abandoned request must leave the queue in a consistent state:
//   • timed out  → a reply IS still coming → leave a no-op consumer to eat exactly one line
//   • write failed → nothing was ever sent → remove the slot entirely
// Get this backwards and every subsequent reply goes to the wrong caller, silently, forever.
function _helperRequest(payload, { timeout, onLine, onAbandon }) { ... }

Seven callers, one invariant, stated once, in the only place where it can be found by the person who needs it. Copy eight — written by someone who never read this article — gets it for free.

That refactor is mine to do, and it's the actual fix. His patch fixed the three instances. The reason there were three instances to fix is still sitting in my file.

What this says about test suites

54 tests on this file. All green. Not one of them ever failed a write.

Of course they didn't — you have to go out of your way to break a pipe in a test, and nobody writes that test until the bug that needs it has already shipped. The bug lived in the intersection of two things a test suite naturally avoids: the error path of the transport, and state that outlives a single call. My tests all assert what one request returns. The bug is only visible in what the next one returns.

He didn't find it by reading my code looking for bugs. He found it because safari_new_tab hung on his machine, and he kept going past the symptom until he hit a queue that was one slot off.

Do you have a positional protocol in production — FIFO correlation, no request IDs? I want to know whether "an abandoned slot must eat exactly one reply" is folklore that everyone rediscovers the hard way, or whether the real lesson is just don't build a protocol without request IDs. Because I'm now fairly sure the invariant I'm about to carefully centralize is one I shouldn't need to have at all.

Source: achiya-automation/safari-mcp — a Safari MCP server that drives your real, logged-in browser. The PR is #53, by @jrepp.

One command adds import, WhatsApp drip and campaigns to self-hosted Chatwoot

אחיה כהן — Sun, 05 Jul 2026 13:12:46 +0000

I run a self-hosted Chatwoot for support, and I genuinely love it. But every time I wanted to actually grow on it, I hit the same wall.

Import a few thousand contacts? Hand-write API calls, or click them in one at a time. Run WhatsApp follow-up sequences? Not built in. Send a bulk campaign with a real variable preview, or attach a video over WhatsApp's 16 MB limit? Nope.

And every off-the-shelf "fix" was the same shape: a separate SaaS, a second server, or a subdomain — each with its own login and its own copy of my customers' data.

So I built the missing layer and open-sourced it: chatwoot-power-tools (MIT).

One command, same-origin, no second server

curl -fsSL https://github.com/achiya-automation/chatwoot-power-tools/archive/refs/heads/main.tar.gz | tar xz \
  && cd chatwoot-power-tools-main && sudo bash install.sh

The installer detects your existing Chatwoot Docker Compose stack, provisions a least-privilege DB role, starts one small sidecar container (cwpt-engine) next to your own containers, adds a single reverse-proxy route, and injects a dashboard script. Everything it adds is served same-origin under one /chatwoot-addons/* path — no subdomain, no CORS, no extra account, and no customer data ever leaving your box.

It's a plain, readable Bash installer (no opaque binary piped to root), it's --dry-run-previewable, and --uninstall reverses everything while preserving your data and any existing DASHBOARD_SCRIPTS.

What it adds

📥 Smart contact import — a CSV/Excel wizard styled to look native, detects columns bilingually (Hebrew + English headers), flags duplicates before import, and maps onto custom attributes.

🔁 WhatsApp drip sequences — automated template-message sequences managed from inside Chatwoot. Enroll a lead by setting a conversation attribute; messages then send at the intervals you configure, automatically skipping quiet hours, Shabbat and Jewish holidays.

✨ Dashboard upgrades — a "Sequences" sidebar item, variable chips + a live preview on the native campaign modal, and client-side video compression (WebCodecs) so you can send video past WhatsApp's 16 MB limit with no server-side transcode.

The part I'm most proud of: least-privilege by design

The engine talks to your Chatwoot only through the API, and its database role is deliberately tiny. It gets SELECT on the handful of tables it reads, plus UPDATE on a single column — contacts.custom_attributes. That's it.

It literally cannot read or change names, phones, emails, or anything else. A bug in the engine can't touch them, because the grant doesn't exist. The role's password is generated on your server with openssl rand and written only to your Chatwoot .env — it never enters logs, command output, or git. No telemetry, no third parties.

Fully bilingual, automatically

The entire UI localizes to each agent's own Chatwoot language — Hebrew (RTL) or English (LTR) — detected automatically, no configuration. Same screen, either way.

Try it

It's MIT, self-hosted Docker Compose only (not Chatwoot Cloud), with a full CI suite. If you self-host Chatwoot, I'd genuinely love your feedback — and issues/PRs are welcome.

👉 github.com/achiya-automation/chatwoot-power-tools

Still deciding between self-hosted and Cloud?

This tool only makes sense if you're self-hosting, so it's worth saying plainly where that stops being the right call. Self-hosting is free and unlimited, but somebody has to own the server, the upgrades and the backups. If that somebody doesn't exist on your team, Chatwoot Cloud starts at $19/agent/month and the Hacker tier is free for up to 2 agents — I wrote up the full pricing and where Intercom is genuinely the better buy.

One warning if you go that route: search for a Chatwoot coupon and you'll find codes advertised at 20%, 50%, even 70% off. None of them work. Chatwoot's affiliate programme caps the customer discount at 5% — that's the ceiling, published on their own affiliate page. My code is ACHIYAVS and it gives exactly that 5%, on monthly or yearly, on every paid tier.

Disclosure: ACHIYAVS is my affiliate code — I earn a commission if you use it, and you pay 5% less than list. Self-hosting with the tool above earns me nothing, and it's still what I'd recommend if you have the ops capacity.

Exactly-Once by Default: How Durable Execution Changed the Way I Build Automations

אחיה כהן — Thu, 02 Jul 2026 11:21:39 +0000

In the previous article I described moving 34 production automations off a visual no-code platform and rewriting them in TypeScript. The single feature that made that migration worth the effort was durable execution with exactly-once semantics. This post is the deep-dive.

The problem: a crash in the middle

Here's a scenario every automation eventually hits. A workflow receives a new lead, sends them a welcome message, then writes them to the CRM:

Send welcome message
Save to CRM

Now imagine the process crashes exactly between step 1 and step 2 — a deploy, an OOM kill, a dropped node. What happens on restart?

Re-run the whole thing → the lead gets the welcome message twice.
Don't re-run it → the lead never lands in the CRM.

Both outcomes are wrong. This is the at-least-once vs at-most-once dilemma, and in a system doing real side effects (sending messages, charging cards, creating records) it is not academic.

The usual fix, and why it hurts

Most tools give you retry-on-failure. But retry alone re-runs side effects. To get exactly-once you build it yourself:

Generate an idempotency key per lead.
Before each side effect, check "did I already do this?" against some store.
Persist progress after each step so a restart knows where to resume.
Repeat this bookkeeping for every workflow you ever write.

It works, but it's tedious, easy to get subtly wrong, and it clutters every automation with plumbing that has nothing to do with the business logic.

How DBOS makes it the default

DBOS flips this: durability is the baseline, not a feature you assemble. You annotate ordinary TypeScript functions. A workflow orchestrates; steps are the units that do side effects and get checkpointed.

import { DBOS } from "@dbos-inc/dbos-sdk";

export class Onboarding {
  @DBOS.workflow()
  static async welcomeLead(lead: Lead) {
    await Onboarding.sendWelcome(lead);   // step 1
    await Onboarding.saveToCRM(lead);     // step 2
  }

  @DBOS.step()
  static async sendWelcome(lead: Lead) {
    await whatsapp.send(lead.phone, "Welcome aboard!");
  }

  @DBOS.step()
  static async saveToCRM(lead: Lead) {
    await crm.upsert(lead);
  }
}

As the workflow runs, DBOS records the completion of each step in Postgres. From the docs:

"If a workflow is interrupted for any reason (e.g., an executor restarts or crashes), when your program restarts the workflow automatically resumes execution from the last completed step."

And crucially:

"Steps are tried at least once but are never re-executed after they complete."

So in our crash scenario: sendWelcome already completed and was recorded. On restart, DBOS skips it and resumes at saveToCRM. The welcome message is not sent twice; the CRM write finally happens. Exactly-once, with zero idempotency bookkeeping in my code.

No separate workflow server, no queue broker to babysit — just your program and Postgres.

The one rule to internalize

Durability isn't free magic — there's a contract. The workflow function must be deterministic: given the same recorded step results, replaying it must take the same path. So anything non-deterministic — network calls, random values, reading the clock, DB writes — belongs inside a step, never loose in the workflow body. Steps are the checkpointed boundary; the workflow is the recomposable script that ties them together.

Once that clicks, the mental model is clean: workflow = the plan, steps = the effects.

What this replaced

On the visual platform, I got retry and error branches, but exactly-once across a crash was something I had to design per flow — manual idempotency keys and "already done?" checks. Here it's the substrate. My code shrank to the business logic, and the reliability guarantee got stronger, not weaker.

That reliability is also what I sell to clients: fewer leads slipping through the cracks, no duplicate messages, no half-finished processes. (See the client-facing angle in the LinkedIn series.)

A note on how I built it

I'm one person, and wiring durable execution into 34 real automations is a lot of surface area. I did it in pairing with Claude Code — it turned "I understand exactly-once in theory" into workflows running in production, TypeScript module by TypeScript module. The barrier between a concept and a shipped system is thinner than it's ever been.

Sources: DBOS Workflows tutorial · Workflows & Steps reference

How do you handle mid-workflow crashes today — hand-rolled idempotency, an outbox, something else? Curious what patterns people have settled on.