DEV Community: אחיה כהן

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.

I Deleted My No-Code Automation Platform and Rewrote 34 Workflows in TypeScript

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

A few weeks ago I deleted two years of work.

Thirty-four automations that run every day — for me and for my clients. WhatsApp AI bots, lead capture from Facebook and web forms, PDF report generation, calendar booking, CRM sync, notifications. All of them built the same way: box after box, dragged and dropped onto a visual canvas.

I deleted the lot and rewrote them in code.

This isn't a "no-code is bad" post. The visual platform I used (n8n) is genuinely excellent and open-source, and it let me ship fast for years. But as the system grew, I started fighting the tooling instead of building. So I want to walk through why code-first won for my use case, the numbers that came out of it, and — importantly — the parts that did not improve, because I have no interest in hype.

What "code-first" actually changed

Here's the before/after, minus the buzzwords.

Maintenance. Before, every change meant opening a browser, hunting for the right node inside a diagram, and dragging. Now every change is a line of code and a git commit. Full history, real diffs, code review, and instant rollback when something breaks.

Building. Before, each new automation was assembled from scratch on the canvas. Now I compose typed, reusable modules. Faster, and consistent across the whole system.

Control. The logic is mine, written explicitly. No magic behind a box, no surprises.

No lock-in. It's standard code in an open format. It runs anywhere; it isn't married to any one platform's JSON schema.

I built on DBOS — a framework that runs workflows written as ordinary TypeScript, backed by Postgres, with durable execution built in. More on that below.

The numbers

The headline that still makes me smile:

Memory: from ~1.4GB down to ~150MB. Roughly 10×.

Same 34 automations, same work, a tenth of the footprint. At idle the new stack sits around 48MB. A smaller, cheaper server now runs the same load with plenty of room to grow.

A couple more measured figures:

Metric	Result
Throughput	~1,167 workflows/second
Per-workflow overhead	~30ms
Idle memory	~48MB
Memory vs. old stack	~150MB vs ~1.4GB (~10×)

Where did the memory go before? To scale under load I had to add worker processes and a queue layer — each one eating more RAM. Now the base is so light that most of the time there's simply nothing to talk about.

The honest part (because I hate hype)

The bots themselves are not faster to respond. Here's why: when a bot talks to a large language model, the LLM sets the pace, not the infrastructure around it. The model's "thinking" takes what it takes, and no runtime swap changes that.

So what did I actually gain? A server that breathes, far higher concurrency, and lower infrastructure cost. Stability and efficiency — not the latency of a single reply. If someone tells you a runtime swap made their AI bot "instant," be skeptical.

How one person did all this

Translating 34 live automations to code, keeping behavior identical, testing each one, and shipping to production without a single client noticing — that is not a one-person job. Historically it's a team, over weeks.

I did it solo, working with Claude Code.

In practice it was a dialogue with a tool that reads code like a senior engineer: it helped me understand each existing automation, rewrite it in TypeScript, catch bugs before production, and verify each flow against the original. I direct, decide, and approve; it does the heavy lifting, fast.

And the migration itself was invisible to the outside world. A Caddy reverse proxy routes all the inbound traffic — WhatsApp, webhooks, forms — so every sender kept hitting the same endpoints. I swapped the engine mid-flight; nobody felt a thing.

The takeaway

The real story here isn't DBOS versus n8n. It's that the ceiling moved.

For years we all learned to work inside limits: "too complex to hand-write," "needs a team," "not worth the weeks." A lot of those limits just quietly disappeared, and our habits haven't caught up yet.

So the question I keep asking myself now isn't "how do I do what I already do, a bit faster?" It's "what would I build if the technical barrier weren't there?" Half of my someday-list turns out to be within reach today.

Next article: a technical deep-dive into the one feature that made this migration worth it — exactly-once durable execution — with real code.

Have you moved something from no-code to code-first? What pushed you over the edge? I'd genuinely like to hear it.

Apple shipped an official Safari MCP. I read all 17 tools. Here's why I'm keeping mine.

אחיה כהן — Thu, 02 Jul 2026 07:15:08 +0000

Apple shipped the tool I've spent a year building as open source.

For about ten minutes on Tuesday night, I thought I was cooked. Safari Technology Preview 247 dropped with an official Safari MCP server, built by the WebKit team, the people who actually make the browser. I maintain a scrappy AppleScript version of the same idea. David, meet Goliath's in-house team.

So I did the only thing that made sense. I read all 17 of their tools, one by one. Somewhere around tool #9 I stopped feeling cooked. By the end I knew I wasn't deleting my repo, and the reason is a single sentence Apple wrote themselves.

First, credit where it's due

The design is clean. It runs on safaridriver, the WebDriver binary already shipping inside Safari, so setup is one command. It runs entirely on your machine. No page content, no screenshots, nothing phones home to Apple. The 17 tools cover the boring-but-essential debugging loop: open a URL, read the DOM, click things, watch the network tab, grab the console, screenshot the result.

If what you want is an agent that debugs how a page renders in WebKit, this is a first-party, well-built way to get it. And honestly? It's the best validation I could ask for. A year ago people asked me why anyone would let an AI drive a browser. Apple just answered that for me.

The one sentence

Here's the line, straight from Apple's own docs:

"The Safari MCP server does not have access to your personal information in Safari (e.g. AutoFill or other browser activity)."

Read that again if you build automation. safaridriver spins up a clean, isolated WebDriver session. Fresh window. A "controlled by automation" banner across the top. None of your logins. None of your cookies. Not the twelve tabs you already have open.

For a debugging tool, that's the right call. Reproducible, sandboxed, no personal state leaking into a test run. I'd have designed it the same way.

It's also the exact problem I built my tool to avoid.

Why mine exists at all

I never built safari-mcp to debug rendering. I built it because I wanted an agent to drive the Safari I'm already logged into: my Gmail, my GitHub, my Ahrefs dashboard, my bank. No re-auth, no fresh profile, no QR code. It runs on native AppleScript in the background, on the stable Safari you already have, on any Mac. No Technology Preview required.

That's the whole difference. Apple's server opens a sterile room and hands your agent a key. Mine walks into the room you're already sitting in.

Here's the honest scorecard I dropped into my README:

	safari-mcp	Apple `safaridriver --mcp`
Your real logins / cookies	✅ Your actual Safari	⚠️ Isolated automation session
Runs on	✅ Stable Safari, every Mac	❌ Technology Preview 247 only
Background, no focus steal	✅ Yes	❌ Dedicated automation window
Tools	96	~17
Cookies / localStorage / IndexedDB	✅ 10 tools	❌
Network mocking + throttling	✅ Yes	❌ Read-only
Official Apple support	❌ Community, MIT	✅ Apple, WebDriver-standard

I checked two of those rows on my own machine before writing this, because I didn't want to bluff. Stable safaridriver in Safari 26.5 has --port, --bidi, --enable, --diagnose. No --mcp. It only exists in the Preview today. And the isolated session really does mean no logins. That's the wall, and I built safari-mcp to climb over it.

So am I changing anything? Yes. Three things, none of them "switch."

Positioning. Apple didn't kill safari-mcp. They told the world what it's for. Theirs is the clean-room debugger; mine drives the browser you live in. I rewrote my README to say that out loud instead of pretending we compete.

A safaridriver backend, eventually. My tool already runs two engines under the hood, a Safari extension and AppleScript. Bolting on a third opt-in WebDriver backend, for people who genuinely want a sterile session, isn't a rewrite. It's a weekend. But it waits until --mcp reaches stable Safari, because right now it only lives in the Preview.

Stealing their best idea. WebDriver synthesizes input events the official, rock-solid way. My native-click path leans on CGEvent, which macOS quietly breaks every other release (ask me how I know). Apple just handed me a sturdier fallback. I'd be silly not to take it.

The takeaway

When the company that makes the browser ships an official version of your side project, the reflex is to panic. Don't. "Official" and "replacement" are different words. I read all 17 tools before I reacted, and the honest comparison turned out to be better marketing than any launch-day panic post could have been.

Apple built the sterile room. I built the tool for the room you already live in. Both should exist.

I just know which one I'll actually reach for on a Tuesday.

safari-mcp is open source (MIT): github.com/achiya-automation/safari-mcp. 96 tools, npx safari-mcp, no Chrome, native macOS. I write about the things I build at achiya-automation.com.

Genuine question, because I keep flip-flopping on it: would you ever trade your logged-in browser for a clean automation session? What would have to be true to make that worth it?

My MCP server had 32 green tests. Not one of them had ever called a tool.

אחיה כהן — Mon, 29 Jun 2026 07:18:15 +0000

For weeks my CI badge was green and I believed it.

Safari MCP is an open-source tool that lets an AI coding agent drive a real, logged-in Safari — click, type, read the page, switch tabs. It registers 96 tools. The test suite ran on every push across three Node versions and came back 32 passed, 0 failed. Green is green. I shipped on it.

Then I went to extract a chunk of index.js into its own module, and while staring at the diff I asked a question I should have asked months earlier:

Which of these 32 tests would fail if I broke the security boundary?

The answer was none of them.

What the tests actually tested

I read the suite line by line. Two of the tests carried almost all the weight:

server starts and lists all registered tools — boots the server, asserts the tool count.
valid schemas + unique names — every tool has a schema, no duplicate names.

The rest were string-escaping and JS-injection helpers. All useful. All real. And all of them answered the same kind of question: does the thing exist and is it shaped correctly?

Not one of them answered: does calling it do the right thing?

It's the test-suite equivalent of checking into a hotel by confirming the building has 96 doors with correct room numbers — and never once trying a key in a lock.

The boundary nobody was watching

The most security-critical code in Safari MCP is tab ownership. The rule is simple to say and easy to get subtly wrong: the agent may only touch tabs it opened. It must never navigate, click, or read a tab the human opened — that's someone's half-written email, their banking session, their unsaved work.

That logic lived in a tangle of module-local state: a map of owned tabs, a TTL so stale entries expire, a blank-URL sentinel for tabs mid-load, a matcher that decides whether https://app.example.com/org is "the same" tab as https://app.example.com/org-evil.

Read that last one again. /org vs /org-evil. If the matcher is even slightly too loose — a startsWith where it needed a path-boundary check — the agent could decide it "owns" a look-alike tab and start typing into it.

There was not a single test exercising that comparison. The suite was 100% green the whole time the security boundary had zero behavioral coverage. A regression there wouldn't have turned CI red. It would have turned CI green and wrong — the worst color a test suite can be.

Why "green and wrong" is worse than red

A red build is honest. It stops you. The failure is the feature.

A green build that proves nothing gives you the feeling of safety without the substance — and you make decisions on that feeling. You refactor confidently. You merge contributor PRs confidently. You tell users the boundary holds. Every one of those is a small bet placed on a test that was never actually watching the thing you care about.

This is the same failure mode I keep running into in this project, wearing a different costume each time:

A macOS API that accepted my click and silently delivered it nowhere — "success" that did nothing.
A README that claimed 80 tools while the code had 96 — a fact nobody had pinned down.
And now a test suite that reported confidence it hadn't earned.

The pattern is always the same: the system doesn't fail loudly. It quietly does less, and the signal you're trusting keeps saying "fine."

The fix: make the boundary fail loudly

Before extracting anything, I wrote the tests that should have existed from day one — behavioral tests that call the ownership logic and assert on its decisions:

/org does not own /org-evil (the path-boundary case).
An entry past its TTL is no longer owned.
The blank-URL sentinel is treated as in-flight, not as a match.
Ownership survives the kind of state round-trip the refactor was about to perform.

Nine of them. The suite went from 32 to 41 (it's 46 today, after a later round for macOS compatibility). More importantly: now if I loosen that matcher by one character, a test goes red and names the boundary in the failure message. The security rule finally has a tripwire.

Only then did I do the refactor — extract the state layer into its own module — and the new tests held identity across the move, which is exactly the confidence I'd been pretending to have.

The rule I'd give past-me

Counting your tools is not testing your tools. Schema validation is not behavior. A green suite tells you what it checks — and stays silent about everything it doesn't, in the most reassuring tone possible.

So the question to ask of any test suite, especially one you've been trusting:

What is the single worst thing that could break in this codebase — and would a test go red if it did?

If the honest answer is "no," your CI badge isn't lying. You just never asked it the right question.

Safari MCP is open source — the ownership tests are in test/ownership-state.test.mjs if you want to see what "test the boundary" looks like in practice. More on what I'm building at achiya-automation.com.

What's the security boundary in your project that your test suite has never once exercised?

My tool said "clicked." Safari never saw it. macOS 26 quietly broke a system API.

אחיה כהן — Thu, 25 Jun 2026 15:04:26 +0000

I maintain an open-source MCP server that lets AI coding agents drive real Safari on macOS. One of its tools sends a native mouse click — an OS-level CGEvent, not a JavaScript element.click() — because some forms (Vue/React with anti-bot checks, OAuth consent screens) reject anything that isn't isTrusted: true. For two years that tool worked.

Then a user on macOS 26 filed a bug, and it took me an embarrassingly long time to believe what I was reading:

The MCP returns Native clicked: BUTTON "Next" at screen (x, y). But the click listener on the page never fires. window.__clicks stays empty.

The tool said it clicked. The page swears nothing happened. Both were telling the truth.

The most expensive kind of bug: the one that succeeds

Here's the failure mode that cost me a weekend. The API call returned success. No exception, no error code, no permission dialog. CGEvent.postToPid(safariPID) took my event, said "sure," and dropped it on the floor.

A bug that throws is a gift — it points at itself. A bug that silently succeeds sends you hunting everywhere except the actual cause. So I hunted.

Accessibility permission? Granted. Verified auth_value=2 in the TCC database for the exact helper binary.
Code-signing identity stable? Yes — signed with a fixed identifier so the grant survives reinstalls. (An earlier macOS bug had silently revoked it; I'd already fixed that.)
Coordinates wrong? No. document.elementFromPoint(x, y) returned the exact <button> I was aiming at, to within a pixel.
Did Apple remove the private window-targeting fields? No. kCGMouseEventWindowUnderMousePointer and its can-handle-this-event sibling are still public in the macOS 26.5 SDK headers.

Every single thing that's supposed to make a synthetic click land was correct. And the click still didn't land.

What actually changed

macOS 26 (Tahoe) tightened the delivery semantics of CGEvent.postToPid for processes that render sandboxed WebKit content. The private fields are still accepted at the API surface — that's why there's no error — but the event never crosses the boundary into Safari's WebContent process. It's authorized, it's well-formed, and it goes nowhere.

This is the gap that breaks debugging: the API contract ("post this event to that PID") still holds, while the behavioral contract ("and the target will receive it") quietly does not. Your code is correct against the documentation. The documentation is correct about the API. Neither is correct about reality on this OS version.

And nothing in the stack tells you which macOS you're on, because for two years it never mattered.

The fix wasn't a permission. It was a fact.

My first instinct was wrong: keep chasing the grant. Try a different event tap. Re-sign the binary again. That's the trap — treating an OS behavior change as a misconfiguration you can fix with one more checkbox.

The real fix was to stop pretending the environment is uniform and surface the one fact that disambiguates the whole bug class: the macOS version itself.

My server has a doctor command — run it first when "clicks don't work even with permissions granted." It checked Safari, Apple Events, the helper daemon, Accessibility, Screen Recording, codesigning… and never printed the OS version. The single most relevant number for a "native input silently fails" report was missing.

So I added a small, pure function — no I/O, unit-tested directly — that classifies the version and flags the risky range:

export function macosCompatNote(productVersion) {
  const major = parseInt(String(productVersion ?? "").trim().split(".")[0], 10);
  if (!Number.isFinite(major)) {
    return { risky: false, line: "macOS version: unknown" };
  }
  const risky = major >= 26;
  const line = risky
    ? `macOS ${productVersion} ⚠ CGEvent native clicks/keys may silently no-op on ` +
      `macOS 26+ even with Accessibility granted (issue #29) — for trust-gated ` +
      `forms prefer JS evaluation or extension-based clicks.`
    : `macOS ${productVersion} — CGEvent native input supported.`;
  return { version: productVersion, major, risky, line };
}

Then doctor calls it as best-effort — sw_vers is macOS-only and absent in CI sandboxes, so it's wrapped in a try/catch that can never block the rest of the diagnostics:

try {
  const { stdout } = await execFileAsync("sw_vers", ["-productVersion"], { timeout: 2000 });
  osLine = macosCompatNote(stdout).line;
} catch { /* sw_vers unavailable — skip the line, the other checks still stand */ }

That's the entire change. It doesn't fix the regression — I can't patch Apple's event delivery. What it does is convert a multi-hour phantom-permission hunt into a single line at the top of the diagnostic output: you're on a version where this API path is known to no-op; reach for the JavaScript or extension path instead.

The lesson I keep relearning

Three things stuck:

A success that does nothing is worse than a failure that screams. When you wrap a platform API, the dangerous case isn't the one that errors — it's the one that returns OK and silently misbehaves. Assume your dependencies can lie politely.
Put the environment in the diagnostics. Every "works on my machine" bug is really "my machine differs from yours in a way neither of us is looking at." The cheapest fix is to make your tool print the difference. The OS version cost me a weekend precisely because nothing surfaced it.
Detect-and-warn beats assume-and-fail. I can't make postToPid work on Tahoe. I can make sure nobody else spends a weekend re-deriving why it doesn't.

The native click still doesn't land on macOS 26 — that's Apple's to change, and I'm tracking it. But now the very first thing the tool tells you is the truth about where you're standing. Sometimes the best you can ship isn't a fix. It's an honest map.

This is from Safari MCP, an open-source MCP server for native Safari automation on macOS (no Chrome, no WebDriver). The full macosCompatNote + doctor change is on main. I write about the unglamorous edges of browser automation and indie automation work at achiya-automation.com.

What's the worst "the API said success but did nothing" bug you've hit — and how long before you stopped blaming your own code?

How Far You Can Actually Customize Chatwoot (Self-Hosted)

אחיה כהן — Wed, 24 Jun 2026 12:17:44 +0000

Originally published on achiya-automation.com.

Most "customer support platform" comparisons end the same way: pick a SaaS, accept its limits, pay per seat forever. This one doesn't. Chatwoot is open-source, and when you self-host it, "customization" stops meaning "which toggles did the vendor expose" and starts meaning "what does your team actually need." I've been running Chatwoot in production for clients long enough to know where that line really is — so here's the honest map of how far you can push it.

There's a specific reason I keep recommending Chatwoot over a closed platform like Intercom, and it isn't price. It's that with a closed SaaS, your customization ceiling is whatever the vendor decided to put in the settings page. With self-hosted Chatwoot you have the source code, the database, and the deployment — so the ceiling is essentially "what can you build." This article is a practical tour of that gap.

TL;DR

Widget — colors, position, locale, behavior, and custom CSS are all configurable; on self-hosted you can patch the widget strings and launcher icon directly
White-label — INSTALLATION_NAME, BRAND_NAME, BRAND_URL remove Chatwoot branding (self-hosted only)
Two APIs — the Application API works inside one account (conversations, contacts, messages); the Platform API manages accounts, users, and bots across the whole install
Webhooks — events like conversation_created and message_created push to n8n / your CRM / custom logic
Dashboard apps — embed your own web app inside the agent inbox via an iframe, with conversation context passed in
Self-hosted unlocks — direct DB access, custom code/forks, no API rate limits, custom channels, full rebranding

A note before the technical part: every fact below maps to Chatwoot's official developer documentation at developers.chatwoot.com. I run this stack daily, but I'd rather you trust the docs than trust me — so check anything load-bearing for your project against them.

1. Widget Customization

The website live-chat widget is the most visible surface, and it's also the easiest to bend. The standard embed is the Chatwoot SDK script plus a settings object you define before the script loads:

<script>
  window.chatwootSettings = {
    locale: "en",            // any locale Chatwoot ships, e.g. "he", "ar", "fr"
    position: "right",       // "left" or "right"
    type: "expanded_bubble", // "standard" or "expanded_bubble"
    launcherTitle: "Chat with us",
    darkMode: "auto",        // "light" or "auto"
  };

  (function (d, t) {
    var BASE_URL = "https://app.chatwoot.com"; // your self-hosted URL
    var g = d.createElement(t), s = d.getElementsByTagName(t)[0];
    g.src = BASE_URL + "/packs/js/sdk.js";
    g.defer = true; g.async = true;
    s.parentNode.insertBefore(g, s);
    g.onload = function () {
      window.chatwootSDK.run({
        websiteToken: "YOUR_WEBSITE_TOKEN",
        baseUrl: BASE_URL,
      });
    };
  })(document, "script");
</script>

The widget color and avatar come from the inbox settings in the dashboard, so non-developers can change them without touching code. Beyond that, the SDK gives you runtime methods to make the widget aware of who's chatting — which is where it stops being a generic bubble:

// Identify the logged-in user so conversations attach to the right contact
window.$chatwoot.setUser("USER_IDENTIFIER", {
  name: "Jane Doe",
  email: "jane@example.com",
});

// Attach structured context that shows up on the agent side
window.$chatwoot.setCustomAttributes({
  plan: "business",
  signup_date: "2026-01-15",
});

// Route or segment by setting a conversation label
window.$chatwoot.setLabel("vip");

// Switch locale at runtime (e.g. when the user changes site language)
window.$chatwoot.setLocale("he");

That setCustomAttributes call is the underrated one: whatever you pass shows up next to the conversation for the agent, so support sees the customer's plan, account age, or cart value without asking. On a closed platform you'd be limited to whatever attributes the vendor supports; here it's just key-value data you define.

Where self-hosting changes the game: the widget strings and the launcher icon are part of the source. On the installs I run, the default widget copy assumed a team ("we're online"), but the business is a solo operator — so the right phrasing was singular ("I'm online"). On Cloud you'd file a feature request and wait. On self-hosted I patched the locale file and swapped the launcher SVG with an idempotent script that re-applies automatically on every container start, so it survives version upgrades with zero manual steps. That's the difference between configuring and owning.

2. White-Label / Rebranding

This is the cleanest example of "self-hosted only." Chatwoot exposes branding through environment variables:

# Replaces the product name across the dashboard and system emails
INSTALLATION_NAME="Acme Support"

# Brand name + URL used in branding references
BRAND_NAME="Acme"
BRAND_URL="https://acme.example.com"

Set those, restart, and the dashboard, the page titles, and the transactional emails reflect your brand instead of Chatwoot's. For an agency reselling support-as-a-service, or a company that simply doesn't want a third-party product name in front of staff and customers, this matters. Combined with a custom domain and the widget tweaks above, a client never has to know which open-source project is underneath.

To be precise about the boundary: full rebranding is a self-hosted capability. Chatwoot Cloud keeps its own branding — which is fair, it's their hosted product. If white-label is a hard requirement, that requirement alone decides self-hosted for you.

3. Application API vs Platform API

This distinction trips people up, so it's worth getting right because it determines what you can automate.

The Application API (you'll also see it called the Client/Agent API) is authenticated with a user access token and operates inside a single account. It's the workhorse for integrations — listing and creating conversations, sending messages, managing contacts, applying labels, reading reports. Example: posting an outgoing message into a conversation:

curl -X POST \
  "https://app.chatwoot.com/api/v1/accounts/{account_id}/conversations/{conversation_id}/messages" \
  -H "api_access_token: USER_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Thanks for reaching out — an agent will be with you shortly.",
    "message_type": "outgoing"
  }'

The Platform API sits a level above accounts. It's authenticated with a Platform App access token and is used to create and manage accounts, users, and agent bots across the whole installation. This is what you reach for when you're provisioning tenants — for example, spinning up a fresh account for every new client and creating their first admin user programmatically:

curl -X POST "https://app.chatwoot.com/platform/api/v1/accounts" \
  -H "api_access_token: PLATFORM_APP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "name": "New Client Workspace" }'

The mental model: Application API = act within an account; Platform API = manage the accounts themselves. Most day-to-day automation lives in the Application API. The Platform API is the multi-tenant / provisioning layer — and having it at all is part of why Chatwoot scales from "one inbox" to "a platform you run for many clients."

4. Webhooks and Automation

Webhooks are the integration backbone. Chatwoot can fire an HTTP POST on account events — conversation_created, message_created, conversation_status_changed, conversation_updated, and more — to any URL you register. That's the hook that lets external logic react to what's happening in the inbox.

The pattern I use constantly: Chatwoot → n8n → back into Chatwoot.

A message_created webhook hits an n8n webhook node.
n8n inspects the payload (sender, content, conversation, inbox), runs whatever logic the client needs — classify intent, look something up in a CRM, call an LLM.
n8n calls the Application API to post the reply, add a label, or update a contact attribute.

That loop is how you build an AI first-responder, a CRM sync, or a routing rule that's smarter than anything a settings page offers — without a vendor-specific "app." Because it's just webhooks and REST, the same approach connects Chatwoot to n8n, Make, your own backend, or all three.

Automation rules and macros (no code required)

Not everything needs a webhook. Chatwoot ships two built-in tools that cover a lot of ground:

Automation rules — event-driven if/then logic configured in the dashboard. On conversation creation you can auto-assign to a team, add a label, send a canned reply, or set an attribute based on conditions. No code.
Macros — a saved sequence of actions an agent runs with one click (e.g. "send the refund template, label it billing, resolve"). Great for repetitive multi-step handling.

The rule of thumb: use automation rules and macros for in-app workflow, and reach for webhooks + the API when you need external data or real logic.

5. Custom Integrations and Dashboard Apps

This is the feature that most surprises people coming from closed platforms. Chatwoot lets you embed your own web application inside the agent dashboard as a Dashboard App. You register a URL, and Chatwoot renders it in an iframe in a panel beside the conversation — and it passes the current conversation and contact context to your app via a postMessage event.

Concretely: your app listens for the context Chatwoot sends in.

// Inside your embedded dashboard app
window.addEventListener("message", function (event) {
  // Chatwoot posts the conversation + contact context here
  try {
    var data = JSON.parse(event.data);
    if (data.event === "appContext") {
      // data.data.conversation and data.data.contact are available
      renderCustomerPanel(data.data);
    }
  } catch (e) {
    /* ignore non-Chatwoot messages */
  }
});

Now your agents see your tooling — order history, a subscription manager, internal notes from another system — right next to the chat, without leaving Chatwoot. On a closed SaaS you'd be waiting for an official integration or a marketplace app. Here you build the panel you actually want and point Chatwoot at it.

6. Why Self-Hosted Unlocks What Cloud/SaaS Can't

Pulling the thread together — here's what specifically becomes possible once you own the deployment:

Direct database access. Chatwoot stores everything in PostgreSQL. For reporting beyond the built-in dashboards, you can query the database directly or pipe it into a BI tool. Closed SaaS exposes only what its export API allows.
Custom code and forks. It's open-source. If a behavior doesn't fit, you can change it and run your fork. The widget-string and launcher patches I described above are exactly this — small, surgical, and impossible on a hosted product.
No API rate limits. Self-hosted, the API is bounded by your server, not by a vendor's throttle. Heavy syncs and high-volume bots don't hit a per-plan ceiling.
Custom channels via the API channel. Beyond the built-in channels, Chatwoot's API channel lets you pipe messages from any source into a Chatwoot inbox and send replies back out — so a proprietary or niche messaging system becomes just another inbox.
Full white-label. As covered above — your brand, end to end.
Data residency and control. Every conversation lives on infrastructure you choose. For regulated industries or strict data-protection regimes, that's often non-negotiable.

None of this is a knock on hosted products. It's a description of a different trade: Cloud trades flexibility for zero maintenance; self-hosted trades maintenance for total control. Which one is "right" depends entirely on whether the customizations above are nice-to-haves or requirements for you.

The fork in the road: Cloud or self-hosted?

Both are legitimate. Pick by what you're optimizing for:

You want it managed, with zero maintenance → Chatwoot Cloud is the pragmatic choice — the vendor handles updates, backups, and uptime, and you still get the API, webhooks, and automation rules. Readers here get 5% off Chatwoot Cloud: chatwoot.com (5% off), coupon ACHIYADEV. > Affiliate disclosure: that's an affiliate link — if you subscribe through it, I may earn a commission at no extra cost to you (the coupon gives you 5% off either way). I recommend Chatwoot because I run it in production, not because of the link.
You need the customizations in this article — white-label, custom code, dashboard apps, direct DB access, no rate limits → that's self-hosted, and it's exactly what I set up and manage for clients. One-time setup, no recurring SaaS seat fees.

A Realistic Word of Caution

Customization is a capability, not a to-do list. The most common mistake I see is treating "we can change everything" as "we should change everything." Every fork you maintain is a thing you have to re-test on upgrade; every webhook is a thing that can fail at 2 a.m. The discipline that makes self-hosted Chatwoot pay off is restraint: start with the dashboard settings, use automation rules and macros before you write code, keep custom patches small and idempotent, and only reach for a fork when configuration genuinely can't get you there. Done that way, customization is an asset. Done carelessly, it's a maintenance bill.

I'm Achiya Cohen, founder of Achiya Automation. I build WhatsApp bots and business automation, and I run self-hosted, customized Chatwoot in production for clients. If you want open-source customer support tailored to how your business actually works — get in touch. And if managed Cloud fits you better, start here for 5% off with code ACHIYADEV (affiliate link).