DEV Community: אחיה כהן

An AI agent overwrote two of my browser tabs. The fix took three releases.

אחיה כהן — Thu, 07 May 2026 12:45:23 +0000

I was eating dinner when my AI agent ate my tabs.

I had Safari open with a Chatwoot Meta dashboard in one tab and an n8n executions view in another — both with unsaved state, both in the middle of real work. In a third tab, my own tab, my agent was supposed to be testing a new feature in the MCP server I maintain (Safari MCP).

I came back to the laptop and both real-work tabs had been navigated to URLs the agent picked. The Chatwoot tab was now showing some test page. The n8n tab was on a Reddit comment thread the agent had been debugging an unrelated module against.

The agent hadn't gone rogue. The MCP server had a state-tracking bug — and instead of failing loudly, it had silently fallen back to "use whatever tab the user is on."

This is a postmortem. The fix took three releases — v2.10.0, v2.10.1, and v2.10.3 — and the iteration is the interesting part.

The shape of the bug

Safari MCP exposes a safari_new_tab(url) tool. Internally, it tracks "the tab MCP owns" via:

A tab index (_activeTabIndex) — Safari's positional handle.
A DOM marker (window.__mcpTabMarker) — injected JS that lets future calls verify "yes, this is still our tab."

Every subsequent safari_navigate, safari_click, safari_fill etc. resolves "where to act" by:

if marker still in current tab → use it
else if _activeTabIndex still valid → switch to it, re-verify
else → fall back to "front document of front window"

That last branch is the catastrophe. "Front document of front window" is, by definition, whatever the user is looking at right now.

So why did the fallback fire? Three different reasons, across three releases.

v2.10.0 — the original failure mode

The original safari_new_tab(url) did exactly what its name said: open a new tab and navigate it to url in one call.

async function newTab(url) {
  const idx = await openBlankTab();     // creates blank tab
  await navigate(idx, url);              // navigates immediately
  await injectMarker(idx);               // marker for future calls
  _activeTabIndex = idx;
}

Spot the bug? It's about what happens when navigate(idx, url) fails to load — file:// blocked by Safari, network error, an app:// scheme that Safari doesn't understand. The new tab stays at about:blank. The marker injection runs, but then the next user-driven navigation in any tab can wipe it. By the time the next safari_navigate arrives, our marker check fails. Our _activeTabIndex still points at a tab, but Safari's real DOM in that tab has been replaced.

The "front document" fallback fires. We navigate the user's current tab.

I shipped this. I tested it on a clean Safari with one window. I never hit the bug because in clean state, the user's tab is my tab.

v2.10.1 — the grace window (almost-fix)

The first fix was a NEW_TAB_GRACE_MS = 30_000 window. For 30 seconds after safari_new_tab, ANY mutating operation that would fall back to the user's tab now throws a clear error:

if (Date.now() - _lastNewTabAt < NEW_TAB_GRACE_MS && !markerOk) {
  throw new Error(
    "tab tracking lost shortly after new_tab — call safari_new_tab again instead of letting MCP touch your active tab"
  );
}

Plus a fix for the marker wipe — safari_navigate now re-injects window.__mcpTabMarker after every successful navigation, so JS-context resets don't lose tracking.

This passed all my tests. It also worked correctly for ~95% of real sessions.

The 5% it missed: sessions longer than 30 seconds where the tab-ghost recovery path nullified _activeTabIndex mid-session.

v2.10.3 — the permanent guard

runJS (the workhorse for every JS-driven tool) has a tab-ghost recovery path. If a JavaScript evaluate fails because the tab Safari thinks is at index N has been closed/replaced, runJS nullifies _activeTabIndex so the next call resolves cleanly.

The intent: avoid using a stale index after Safari shuffles tabs.

The unintended consequence: 30+ minutes into a session, after a routine ghost-recovery, _activeTabIndex is null. The grace window from v2.10.1 has long expired. The marker check fails (the agent has navigated several times since). Fallback fires. User's current tab gets clobbered.

The bug pattern: a "safe" recovery path created the exact failure mode the grace window was designed to prevent.

The permanent fix is a one-line change in spirit:

let _hasOwnedTab = false;  // session-scoped, sticky

async function newTab(url) {
  // ... existing logic ...
  _hasOwnedTab = true;     // ← set once, never reset
}

function _assertNotFallingBackToUserTab() {
  if (_hasOwnedTab) {
    throw new Error(
      "MCP previously owned a tab in this session, but tracking was lost. " +
      "Refusing to fall back to the user's current tab. Call safari_new_tab to re-establish."
    );
  }
  // sessions that never called new_tab can still use front-document fallback
}

The flag is set the first time safari_new_tab succeeds, and it never resets for the lifetime of the MCP process. The four entry points that can target a tab — _assertNotFallingBackToUserTab (used by navigate and navigateAndRead), runJS's tab-ghost fallback path, and runJSLarge — all call this assertion before falling back to the user's current tab.

If the assertion throws, the agent gets a clear error pointing back at safari_new_tab. The user's tab is untouched.

Sessions that never call safari_new_tab (e.g. tools that explicitly read the user's current tab) are unaffected — _hasOwnedTab stays false, and the front-document fallback still works for them.

What I'd take away if I were writing my own MCP server

1. The fallback you don't notice is the fallback that bites.
"Use the user's current tab" looks like a reasonable degraded mode in isolation. In context — an autonomous agent acting on the user's real, logged-in browser — it's the worst possible default. The fix wasn't "make the fallback work better." It was "the fallback should not exist in this branch of the state machine."

2. State-tracking bugs aren't subtle. They're catastrophic.
A misidentified tab is a misidentified action. The class of bug here — I think I'm acting on X but I'm actually acting on Y — is the same class as a deployment script targeting prod instead of staging, or a Git rebase rewriting the wrong branch. There's no "minor version" of this bug. Engineering effort should be priced accordingly.

3. "Sticky" flags beat "windowed" flags for invariants you actually need.
The v2.10.1 grace window was time-bounded. That made sense for the failure mode I'd seen. But sessions are unbounded. Anything that can happen during the session can happen after the grace window expires. If the property "MCP has owned a tab in this session" is the actual thing protecting the user, that property must hold for the whole session — not 30 seconds.

4. Tests on clean state miss the bugs that matter.
I tested v2.10.0 on a fresh Safari with no other tabs. The user-tab-clobber bug is invisible in that environment, because the user's tab and MCP's tab are the same tab. Real users have eight tabs open and were just clicking around in tab six. If your tool drives a user's real browser, your test environment must have unrelated, in-progress tabs — and your failure modes must be loud when you brush against them.

5. Errors are a feature.
The replacement for "silent fallback to user tab" is a thrown error with a remediation message: "Call safari_new_tab to re-establish." That error is better than the original happy path — because the original happy path was sometimes a disaster. A loud, fixable error is always better than a quiet, irreversible mistake.

The diff that mattered

+ let _hasOwnedTab = false;

  async function newTab(url) {
    const idx = await openBlankTab();
    await navigate(idx, url);
    await injectMarker(idx);
    _activeTabIndex = idx;
+   _hasOwnedTab = true;
  }

  function getFallbackTarget() {
+   if (_hasOwnedTab) {
+     throw new Error("…re-establish via safari_new_tab");
+   }
    return frontDocumentOfFrontWindow();
  }

That's the load-bearing part. Everything else in v2.10.3 is plumbing.

If you're building an MCP server (or any tool that drives a user's real browser/editor/database), the question I'd ask in code review is:

"What's the worst thing this fallback can do, and does the fallback's existence buy enough to be worth that worst case?"

For tab fallback in Safari MCP, the answer was: no, it doesn't.

Source: github.com/achiya-automation/safari-mcp
Install: npx safari-mcp
Releases discussed: v2.10.0, v2.10.1, v2.10.3

Have you shipped a state-tracking bug that ate user data? What was the failure mode, and what flag/invariant ended up being the real fix?

LinkedIn Quietly Migrated From ProseMirror to Quill — and Broke Every Browser Automation Tool That Touched the Composer

אחיה כהן — Sun, 03 May 2026 07:34:07 +0000

I shipped a fix to my MCP server last week for LinkedIn's ProseMirror composer. It worked. Two days later, every LinkedIn post automation broke.

This is the post-mortem of what changed, how I figured it out, and why "automate the platform" stories almost always end this way.

The crash

The symptom was specific. My MCP server's safari_fill tool — which dutifully filled ProseMirror by walking React Fiber and calling editor.commands.setContent(html) — was now crashing the helper daemon and dismissing the composer dialog the instant it touched the contenteditable.

Same composer URL. Same DOM tree at first glance. Same selectors. Different editor underneath.

The DOM tells the truth

I dropped into the browser console and ran the usual probe:

const el = document.querySelector('[contenteditable="true"]');
el.editor // -> undefined
el.closest('.ProseMirror') // -> null
el.closest('.ql-editor') // -> <div class="ql-editor">

There it was. .ql-editor is the canonical Quill class name. LinkedIn had swapped the post composer from ProseMirror to Quill at some point in early 2026 with no announcement I can find.

Why it was crashing

Quill, like ProseMirror, doesn't let you "just" stuff text into the contenteditable. Both editors hold an internal model — Quill calls it a Delta — and the DOM is downstream of that model.

If you bypass the model and write to the DOM directly, two things happen:

The model and DOM disagree.
The next user-driven event (a keystroke, a save) triggers a re-render that throws because the diff is incoherent.

That's what was killing the composer. My fill was writing to innerText, the Delta state thought the editor was still empty, the React tree tried to reconcile, and the dialog evaporated. The Swift daemon caught the cascading exception and crashed itself for good measure.

The fix: drive Quill the way it expects to be driven

Quill exposes a programmatic API. You just need a reference to the instance. The lookup order I landed on:

Walk up to find an ancestor with class .ql-container.
Try .__quill — Quill 2.x attaches the instance there directly.
Fall back to React Fiber: walk up the fiber chain looking for memoizedProps.quill or stateNode.quill (LinkedIn wraps Quill in a React component that holds the instance in props).
If still nothing, fall back to a real CGEvent Cmd+V paste — Quill respects clipboard events with isTrusted: true.

Once you have the instance, the actual fill is one line:

quill.setContents([{ insert: text + '\n' }], 'api');

The 'api' source flag is the part that matters. It tells Quill "this came from your own API, update your model and the DOM together." The text commits, the Delta stays consistent, and the React parent doesn't try to re-conciliate against a corrupted model.

What this taught me about platform automation

Two lessons, both old, both worth re-learning:

Editors aren't a stable interface. ProseMirror and Quill have different APIs, different state models, and different rules for "what counts as a real edit." Targeting one of them only works until the platform decides it doesn't anymore. LinkedIn made this swap with zero changelog. The only way I knew was that my code broke.

The DOM is the lowest common denominator. The editor model is the actual one. Every automation tool that synthesizes events on the contenteditable is operating one layer below the truth. Sometimes that works (because the editor reconciles). Sometimes it doesn't (because the editor crashes or silently discards the input). The robust path is always to find the editor instance and call its API.

There's a third lesson, which is more uncomfortable: I couldn't fully verify my fix on LinkedIn, because LinkedIn's modal-opening behavior in headless contexts is independently broken right now. The composer button accepts clicks, the dialog DOM materializes, but it never visually opens. So the Quill detection is in place — and verified on test pages — but the LinkedIn-specific live path is still gated on a separate modal issue I haven't cracked.

This is the texture of platform automation. Two unrelated bugs, same week, same target. Each one looks like the other. You ship a fix for one and the other one masquerades as a regression.

The takeaway

If you're building anything that types into a third-party rich text editor — Slack, LinkedIn, Discord, Medium, Notion — the editor identity is part of your contract with the platform, and the platform doesn't owe you stability there. Detect the editor type at runtime. Have a fallback for the unknown case (real clipboard events, ideally). Log what you found, so when it changes you find out from your own telemetry instead of from a Slack message at 11pm.

And read the contenteditable's class list before you touch it. ProseMirror and Quill have different class signatures and the DOM will tell you what you're dealing with — if you ask.

The fix shipped in safari-mcp@2.10.2. Source on GitHub.

When GitHub Actions Goes Silent: The Pending-Forever Bug I Hit Shipping My MCP Server to npm

אחיה כהן — Tue, 28 Apr 2026 19:22:06 +0000

I have an open-source MCP server. I tag a release, push, GitHub Actions builds, npm publishes, MCP Registry updates. That's the contract. It worked for v2.7.6 through v2.8.4.

Then v2.8.5 didn't publish. Neither did v2.8.6. Or v2.9.0. Or v2.9.1. Or v2.9.2. Or v2.9.3.

Six releases stuck. Not failing — stuck. Yellow dot. Forever.

Here's what was actually happening. And how I got the releases out without GitHub Actions.

The symptom that doesn't match any docs

Every release event triggered the workflow. Every workflow showed up in the runs list. None of them ever started a job.

$ gh run view 25001890100 --json status,conclusion,jobs
{
  "status": "queued",
  "conclusion": null,
  "jobs": []
}

No conclusion. No jobs. Empty pending_deployments. Not "waiting for approval". Not "in_progress". Not "failure". Just pending with no work scheduled — for 125 hours.

If you search "GitHub Actions stuck pending", you'll find a hundred forum posts. Every answer assumes one of:

You hit the runner concurrency limit (3 for free-tier macos)
You have a deployment environment requiring approval
Your runs-on: label is unreachable
You're using self-hosted runners with no online agents

None of those applied. My workflow was simple, no environments with required reviewers, runs-on: macos-latest, no self-hosted runners.

The thing GitHub doesn't tell you in the run UI

The runs list shows pending. The run detail page shows pending. The job list shows nothing. The "deployment" tab shows nothing.

But if you look at your billing dashboard, there's a different story:

Your account has used 100% of included macOS minutes for this billing period.

That's it. That's the entire diagnostic. There is no banner on the run page. The workflow doesn't fail with a clear error. It just sits in the queue forever — because the runner that would pick it up doesn't exist, and the queue doesn't time out events.

The minutes counter resets monthly. Until it does, every release event becomes another silent pending row.

Two facts that surprised me

Fact 1: macOS runners cost 10x more than Linux runners. Both runs-on: macos-latest and runs-on: macos-13 charge against your Actions minutes at a 10x multiplier. The free 2,000 minutes/month gets you 200 minutes of macOS — about 20 release builds if each takes 10 minutes.

Fact 2: Switching to Linux didn't fix it. I changed runs-on: macos-latest to runs-on: ubuntu-latest. Same symptom. 0 jobs queued, status "pending". Why?

The macOS minutes meter is one bucket. The Linux meter is another. When the macOS bucket emptied, my pending macOS runs were still in the queue, blocking new runs. Even after switching the workflow to ubuntu, the concurrency group in the YAML serialized everything:

concurrency:
  group: publish
  cancel-in-progress: false

So new ubuntu runs queued behind old stuck macOS runs and never started.

The two-part fix

Part 1: workflow_dispatch with tag input

Adding a manual trigger lets you re-publish a tag whose release-event run got stuck, without deleting and recreating the GitHub Release:

on:
  release:
    types: [published]
  workflow_dispatch:
    inputs:
      tag:
        description: "Tag to publish (e.g. v2.9.3)"
        required: true
        type: string

In every step that needs the tag, fall back through both event types:

- uses: actions/checkout@v6
  with:
    ref: ${{ github.event.inputs.tag || github.ref_name }}

That alone isn't enough — if the runner pool is still empty, the dispatched run also stalls. But it gives you a clean re-trigger path the moment runners are back.

Part 2: portable runner OS

The workflow downloaded mcp-publisher_darwin_${ARCH}.tar.gz — hardcoded "darwin". Switching to ubuntu broke that step. Generalize:

- name: Download mcp-publisher
  run: |
    OS=$(uname -s | tr '[:upper:]' '[:lower:]')
    ARCH=$(uname -m)
    if [ "$ARCH" = "x86_64" ]; then ARCH=amd64; fi
    if [ "$ARCH" = "aarch64" ]; then ARCH=arm64; fi
    curl -sL "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_${OS}_${ARCH}.tar.gz" -o mcp-publisher.tar.gz
    tar -xzf mcp-publisher.tar.gz mcp-publisher

Now the same step works on macOS-arm64, macOS-x86_64, ubuntu-x86_64, and any future runner.

The manual workaround that actually shipped the release

While the workflow stays stuck, here's how I got v2.9.3 to npm and the MCP Registry from my laptop:

npm: the easy part

git checkout v2.9.3
npm publish --provenance --access public

--provenance requires a valid OIDC token, which only works inside GitHub Actions. Skip it locally:

npm publish --access public

You lose the provenance attestation, but the package ships. Provenance is a nice-to-have, not a publish blocker.

MCP Registry: the trickier part

The MCP Registry's CLI authenticates interactively:

mcp-publisher login github
# Opens a browser, asks you to paste a code, etc.

That's fine for humans. For a script — or for a Claude session running headless — you need non-interactive auth. The mcp-publisher binary accepts -token:

GH_TOKEN=$(gh auth token)
mcp-publisher login github -token "$GH_TOKEN"
mcp-publisher publish

The gh CLI you already use for everything else? Its token works as your GitHub PAT for mcp-publisher. No browser, no copy-paste.

After running these, the MCP Registry's io.github.achiya-automation/safari-mcp v2.9.3 went from "stuck on v2.7.6 for 3 weeks" to isLatest: true in about 15 seconds.

What I'd tell past-me

Check the billing dashboard *first* when an Actions run sits pending with no error. The run UI does not surface "you're out of minutes". The billing page does.
Don't trust runs-on: ubuntu-latest to "just be cheaper" — it is, but if you've burned your macOS minutes on stalled runs, the queue can still serialize new ones behind dead ones via your concurrency: group.
Keep a manual publish path documented. Both npm and the MCP Registry have non-interactive auth options. Write the bash one-liners somewhere your future self can find them at 2am.
workflow_dispatch with a tag input is cheap insurance. It costs you 6 lines of YAML and saves you from needing to delete-and-recreate GitHub Releases when the release-event run gets corrupted.

FAQ

Why didn't a timeout-minutes: rescue me?
That's a job-level timeout. It applies once a job starts. A run that never starts a job has nothing to time out.

Couldn't I have used a self-hosted runner?
Yes — and that's the right answer for high-volume projects. For an OSS hobby project, self-hosted is operationally heavier than the manual publish path.

Doesn't --provenance matter for supply-chain security?
For widely-installed packages, yes. For an OSS project's own emergency-publish workaround, the trade-off is "ship the release without provenance" vs "ship nothing". Pick the first one and re-publish with provenance on the next clean release.

Could I have known about the billing limit before hitting it?
GitHub does send an email when you cross 75% of your minutes. The email goes to the address on your billing account, which may not be the address you watch. Worth setting up a filter.

What about Actions minutes for OSS public repos?
GitHub gives unlimited minutes to public repos using GitHub-hosted runners — but that's only for repos owned by organizations on the Free plan, with the runner type matching the included unlimited tier. For personal accounts and certain runner combinations, the standard quota applies. Check the actual numbers under Settings → Billing → Plans for your specific account type.

If you've hit a similar stuck-pending pattern with no error in the run UI — that's the bug. Check your minutes. Then ship from your laptop.

The repo (with the workflow that handles all this now) is safari-mcp on GitHub.

The 3 isTrusted:false Bugs That Made LinkedIn Posts Impossible From My MCP Server

אחיה כהן — Wed, 22 Apr 2026 14:36:56 +0000

TL;DR

I couldn't post to LinkedIn from my MCP server. Not "sometimes fails" — never works. I assumed one bug. I was wrong. I found three, stacked, and each one looked like success to every automation tool I tried. Here is the anatomy of why your agent's "I posted it!" lies to you when a rich-text editor sits inside a dialog.

The symptom

I ship Safari MCP — an MCP server that drives the Safari you are already logged into. 80 tools. safari_fill is the most-used one. For three months it worked everywhere — Gmail, GitHub, Ahrefs, Google Docs, Shopify admin.

Then I tried posting to LinkedIn from an agent.

> agent: safari_fill({text: "Shipping v2.9.0 — modal detection in snapshot!"})
< result: "Filled. 67 chars."

Except the LinkedIn composer was empty. And closed. And I had a cursor in my address bar.

Three hours later I had a list. Three separate boundaries, each silently sabotaging the one before it.

Boundary 1: `focusout` dismisses the dialog

LinkedIn's composer is a <div role="dialog">. Specifically, its share composer listens for focusout on any descendant and closes the modal — the UX intent is "clicked outside → close."

My fill path did this at the end:

// Old: "polite" contenteditable fill (pseudo-code)
setEditableContent(editableEl, text);
editableEl.dispatchEvent(new Event('input', { bubbles: true }));
editableEl.blur();  // ← here's the assassin

The blur() call was there for a reason — some React frameworks only commit state on blur. Perfectly reasonable on a standalone textarea. Inside a dialog? The focusout listener takes the blur, concludes the user clicked away, and runs the dismiss animation.

My fill worked. For ~40ms. Then the dialog DOM disappeared and the text with it.

Fix: Remove the blur(). React commits state from input alone on any modern contenteditable. If a site truly requires blur to persist, it is broken for keyboard users anyway.

But removing blur was not enough. The next run showed the text finally landing, the Post button enabling — and then the button click did nothing. Why?

Boundary 2: ProseMirror's `isTrusted:false` paste rejection

LinkedIn's composer was ProseMirror when I started debugging. (They have since migrated to Lexical. We will get there.) ProseMirror has a paste handler. That handler is strict:

// ProseMirror source, paraphrased
handlePaste(view, event) {
  if (!event.isTrusted) {
    // Synthetic paste events don't reflect real user intent.
    // Reject them — the editor state must only change from real input.
    return false;
  }
  ...
}

This is a security decision, not a UX one. event.isTrusted is only true when the browser itself dispatches the event — a real keystroke, a real paste, a real click. JavaScript new Event() or dispatchEvent() produces isTrusted:false every time.

My fill was dispatching new ClipboardEvent('paste', { clipboardData: ... }). The editor reached its paste handler, saw isTrusted:false, and bailed. The execCommand('insertText') fallback went the same way.

The character-by-character beforeinput dispatch? Also isTrusted:false. Also rejected.

Fix that worked (and broke in Boundary 3): Route through a real OS paste. I already had a _nativeTypeViaClipboard path — uses AppleScript to set the system clipboard, then dispatches a real Cmd+V via macOS CGEvent. The browser sees it as a real user paste. isTrusted is true. Editor accepts it.

Boundary 3: CGEvent Cmd+V steals focus, triggers Boundary 1

Remember Boundary 1 was "focusout dismisses the dialog?" Well —

The CGEvent Cmd+V path delivers the keystroke to the frontmost window. To be the frontmost window, Safari has to be active. When I programmatically activate Safari via NSApplication activateIgnoringOtherApps, the previous window loses focus for a tiny window. Chrome's "focus stealing" behavior is a documented pet peeve of every automation tool; Safari is no different.

So the sequence was:

CGEvent fires Cmd+V
Safari gets activated (taking focus briefly)
The composer editor sees focusout during the ~10ms activation window
Dialog dismisses
Paste lands — but on the feed underneath the now-closed dialog

Cool.

First fix attempt: Use a background-activation variant that does not foreground Safari. This worked but required the user's Safari to already be the active app (fragile — the point of MCP is the user is doing other work).

Second fix attempt — the one that stuck: Bypass the OS keyboard entirely. Drive the editor through its own internal API.

The actual fix: editor-native API access

LinkedIn's composer (as of 2026-04) is Lexical, not ProseMirror. Lexical is Meta's replacement — also used in Shopify admin, some Meta apps, newer Notion surfaces.

Lexical exposes the editor instance on its DOM root element:

const editorEl = document.querySelector('[data-lexical-editor="true"]');
const editor = editorEl.__lexicalEditor;  // the actual LexicalEditor instance

// Build a minimal root → paragraph → text document
const newState = editor.parseEditorState(JSON.stringify({
  root: {
    children: [{
      children: [{ detail: 0, format: 0, mode: 'normal', text: value, type: 'text', version: 1 }],
      direction: 'ltr', format: '', indent: 0, type: 'paragraph', version: 1
    }],
    direction: 'ltr', format: '', indent: 0, type: 'root', version: 1
  }
}));
editor.setEditorState(newState);

Zero synthetic events. Zero focus shift. Zero clipboard. The editor updates its own state directly. Lexical's internal invariants hold. React re-renders the contenteditable tree through its normal diff path. The Post button observes the state change and enables itself.

For ProseMirror (which LinkedIn used to use), the equivalent is:

const pmView = editorEl.pmViewDesc?.view;  // ProseMirror's EditorView
const tr = pmView.state.tr.insertText(value, pmView.state.selection.from);
pmView.dispatch(tr);

Same principle: do not pretend to be a user. Be a caller.

The cascade of falsified "success"

Here is what is unsettling: every stage of every failed attempt returned success to my agent.

Setting the editable element's content → value set, DOM mutation event fires, "success"
dispatchEvent(new ClipboardEvent('paste')) → handler called, preventDefault returned, "looks like paste fired, success"
_nativeTypeViaClipboard → Cmd+V fired, clipboard had the content, "success"

The only honest verification is: did the editor state update? Not the DOM. Not the visible text. Not the event log. The editor's own source of truth.

For Lexical: editor.getEditorState().toJSON(). Compare to what you expected. Now you know.

This is why your agent's "I posted it" lies. Every layer of the automation stack reports local success. None of them verified the editor's internal state matched the intent.

Generalizations

Blur is radioactive in dialogs. Audit every automation tool's fill path. If it calls .blur(), it will close some modal somewhere.
isTrusted:false is a one-way door. Real-world rich-text editors audit it. Your synthetic paste/input/keydown will not cross. Either use a native OS path (Cmd+V via CGEvent/winuser) or drive the editor API directly.
Native OS paste moves focus. Which is fine — unless the target is inside a dialog that listens for focus loss. In that case, drive the editor API directly.
Editor API access is undocumented but stable. __lexicalEditor, pmViewDesc.view, Draft.js's internal store — these are all in production for years because the editors are themselves stable. They are not public but they are not moving.
Trust nothing downstream of the editor. The rendered DOM, text content, visible interface — any of these can be right while the editor's internal state is wrong. Verify editor state, not DOM state.

What this means if you use or build MCP servers

Most MCP browser tools today use page.type() or element.fill() — thin wrappers over DOM events. They will work for 80% of forms and silently fail for rich editors inside dialogs (which is roughly: every post/comment/share UI on every major social site, Notion, Google Docs, JIRA, Salesforce rich notes, Shopify description fields).

If you are evaluating browser-automation MCP servers for agent workflows that involve content creation, test this specifically:

Can it post to LinkedIn?
Can it type a multi-line comment on GitHub?
Can it fill a Notion page with formatted text?

If any of those fail silently (returns "success" but the target app shows nothing), the tool has one of these three bugs.

Safari MCP v2.9.4 ships the Lexical-native path. If you are on macOS and want to try it:

npx safari-mcp

MIT, 80 tools, github.com/achiya-automation/safari-mcp.

Is there a fourth boundary I missed? Drop a comment — I will buy the bug report with a merch sticker if it forces a v2.9.5.

WhatsApp Bot for Business 2026 — $1K-$4K (50+ Real Builds)

אחיה כהן — Mon, 20 Apr 2026 19:54:12 +0000

WhatsApp has over 2 billion users worldwide. If your customers are on WhatsApp (and they probably are), a bot can handle inquiries 24/7, book appointments, and qualify leads — while you sleep.

But there's a catch: do it wrong, and Meta will restrict or ban your number. I've seen businesses lose their primary WhatsApp number because they used the wrong tool, sent messages to people who didn't opt in, or scaled too aggressively.

This guide covers how to build a WhatsApp bot properly — which API to use, how to avoid bans, and what a realistic setup looks like.

TL;DR

Official API (via BSP) — safe, verified, but costs $50-100/month + per-message fees. Best for established businesses
WAHA (unofficial, open-source) — free, flexible, but not endorsed by Meta. Risk of account restrictions. Best for small businesses starting out
Ban prevention — get opt-in before messaging, don't send bulk unsolicited messages, respond to conversations (don't just broadcast)
Realistic cost — $1,000-4,000 setup + $5-100/month ongoing, depending on your approach

Two Ways to Connect: Official API vs. WAHA

This is the first decision you'll make, and it affects everything else — cost, reliability, features, and risk.

Option 1: Official WhatsApp Business API

The WhatsApp Business API is Meta's official solution for businesses. You access it through a Business Solution Provider (BSP) like Twilio, 360dialog, or MessageBird. (If you want a full breakdown of BSPs, fees, and the onboarding process, see our WhatsApp Business API guide.)

How it works:

Sign up with a BSP
Verify your business with Meta
Get a dedicated phone number (or use an existing one)
Send and receive messages through the API

Pricing (as of March 2026):

BSP monthly fee: $50-100/month (varies by provider)
Per-conversation fees (set by Meta):
- Marketing conversations: ~$0.035/conversation (varies by country)
- Utility conversations (order updates, etc.): ~$0.005/conversation
- Service conversations (customer-initiated): free for the first 1,000/month
Template messages must be pre-approved by Meta

Pros:

Officially supported — no risk of account bans for API usage
Green checkmark verification available
Template messages for outbound messaging
Higher rate limits
Multi-device support built in

Cons:

Per-message costs add up at scale
BSP adds another vendor and monthly cost
Template approval process can be slow (24-72 hours)
Less flexibility — you can only do what the API allows

Option 2: WAHA (Unofficial WhatsApp API)

Important: WAHA is NOT an official WhatsApp product. It's an open-source project that provides API access to WhatsApp by connecting through WhatsApp Web's protocol. Meta does not endorse or support it.

How it works:

Self-host WAHA on your server (Docker)
Scan a QR code with your WhatsApp number (like WhatsApp Web)
Send and receive messages through WAHA's REST API

Pricing:

WAHA Core: free and open-source
WAHA Plus: paid version with additional features
Your only cost: server hosting ($5-20/month)

Pros:

No per-message fees
No template approval process
Full flexibility — send any message type
Open-source — you can inspect and modify the code
No BSP middleman

Cons:

Not endorsed by Meta — using it technically violates WhatsApp's Terms of Service
Risk of account restrictions if you trigger spam detection
Relies on WhatsApp Web protocol — can break when WhatsApp updates
No green checkmark
Phone must stay connected (though WAHA handles multi-device well)

Which Should You Choose?

Scenario	Recommendation
Established business, customer communications	Official API
Marketing campaigns and broadcasts	Official API (with opt-in)
Small business, responding to incoming messages	WAHA can work well
Testing and prototyping	WAHA (lower cost to experiment)
Highly regulated industry (healthcare, finance)	Official API
Budget-conscious startup	WAHA to start, migrate to official later

In our experience, many small businesses start with WAHA because the barrier to entry is lower, then migrate to the official API as they scale.

How to NOT Get Banned (Critical)

Whether you use the official API or WAHA, these rules apply:

The #1 Rule: Get Opt-In First

Never send the first message to someone who hasn't explicitly asked to hear from you. This is both a WhatsApp policy requirement and common sense.

Good:

Customer fills out a form and checks "Contact me on WhatsApp"
Customer sends you a message first and you respond
Customer explicitly asks to receive updates via WhatsApp

Bad:

You bought a list of phone numbers and blast them all
You scrape numbers from websites and send cold messages
You add everyone in your phone contacts to a broadcast list

Rate Limiting

Don't send hundreds of messages per minute. WhatsApp's detection algorithms look for:

High volume in short time — sending 500 messages in 5 minutes is a red flag
Identical messages — sending the exact same text to many numbers looks like spam
High block rate — if many recipients block you, your quality rating drops fast
Messaging numbers that don't have you saved — this is a strong spam signal, especially at volume

For a deeper breakdown of the exact thresholds and how WhatsApp's four-layer detection system works in 2026, see the WhatsApp spam detection guide.

Safe practices:

Space out bulk messages (add 2-5 second delays between sends)
Personalize messages (use the recipient's name, reference their specific inquiry)
Keep your block rate under 2-3%
Start slow — send to 50 people first, monitor for blocks, then scale gradually

WAHA-Specific Precautions

If you're using WAHA (unofficial API):

Use a dedicated number — don't risk your primary business number
Don't blast — WAHA is best for responding to incoming messages, not mass outbound campaigns
Monitor your quality — if you notice messages not delivering, stop and investigate
Have a backup plan — if the number gets restricted, you need to be able to switch to the official API or a new number
Keep sessions stable — frequent disconnections/reconnections can trigger flags

Building Your Bot: A Practical Walkthrough

Here's how a typical WhatsApp bot setup looks using n8n (our preferred automation platform) and WAHA.

Architecture Overview

Customer sends WhatsApp message
        ↓
    WAHA (receives message via WhatsApp Web)
        ↓
    Webhook → n8n (processes the message)
        ↓
    Logic: FAQ? Appointment? Lead? → Route accordingly
        ↓
    Response sent back through WAHA
        ↓
    Customer receives reply on WhatsApp

Step 1: Set Up WAHA

WAHA runs as a Docker container. Basic setup:

# docker-compose.yml
services:
  waha:
    image: devlikeapro/waha
    ports:
      - "3000:3000"
    environment:
      - WHATSAPP_DEFAULT_ENGINE=WEBJS
      - WAHA_DASHBOARD_ENABLED=true
    volumes:
      - waha_data:/app/.sessions

volumes:
  waha_data:

After starting it (docker compose up -d), open http://your-server:3000/dashboard, start a session, and scan the QR code with your phone.

Step 2: Connect to n8n

In n8n, create a webhook node that WAHA will call when messages arrive:

Add a Webhook node — this receives incoming messages
Configure WAHA to send webhooks to your n8n webhook URL
Add a Switch node to route messages based on content
Add response nodes to send replies back through WAHA's API

Step 3: Build Your Logic

A basic FAQ bot might look like this in n8n:

Webhook (incoming message)
    → Switch node:
        - Contains "hours" or "open" → Send business hours
        - Contains "price" or "cost" → Send pricing info
        - Contains "appointment" or "book" → Start booking flow
        - Default → "Thanks for reaching out! A team member will reply shortly."

Step 4: Add AI (Optional)

To make your bot smarter, add an AI node:

Webhook (incoming message)
    → OpenAI/Claude node:
        System prompt: "You are a helpful assistant for [Business Name].
        You know: [business hours, services, pricing, FAQ].
        If you can't answer, say you'll connect them with a human."
    → Send AI response via WAHA

This turns your bot from a rigid keyword-matcher into a conversational agent that understands natural language.

Real-World Use Cases

These are use cases we've implemented (described in general terms):

1. Appointment Scheduling

The bot asks what service the customer needs, checks available time slots from Google Calendar, proposes options, and books the appointment — all within WhatsApp. Confirmation and reminder messages are automated.

2. Lead Qualification

When a new lead messages, the bot asks 3-4 qualifying questions (budget, timeline, requirements). Qualified leads get forwarded to a human agent immediately. Unqualified leads get a helpful resource and are added to a follow-up sequence.

3. Order Status Updates

Connected to the business's order management system, the bot responds to "Where's my order?" with real-time tracking information. No human intervention needed for 80%+ of status inquiries.

4. FAQ + Human Handoff

The bot handles common questions (pricing, hours, location, services). When it can't answer or the customer asks for a human, the conversation is routed to a support agent in Chatwoot (open-source customer support platform; 5% off Cloud with code UJR5GXWK) — with full conversation history preserved.

What It Actually Costs

Here's a realistic breakdown for a small business:

DIY with WAHA + n8n (self-hosted)

Component	Monthly Cost
VPS (2GB RAM)	$5-20
WAHA	Free (Core)
n8n	Free (self-hosted)
OpenAI API (if using AI)	$5-50 (depends on volume)
Total	$10-70/month

Professional Setup (someone builds it for you)

Component	Cost
Bot development	$1,000-4,000 (one-time)
Hosting + maintenance	$25-75/month
AI API costs	$5-50/month
Total	$1,000-4,000 setup + $30-125/month

Official API Route

Component	Monthly Cost
BSP subscription	$50-100
WhatsApp conversation fees	$20-200 (depends on volume)
n8n or automation platform	$0-25
Total	$70-325/month

Common Mistakes I See

1. Going straight to mass messaging. Build a bot that responds to incoming messages first. Get that working well. Then — and only then — consider outbound campaigns, and always with opt-in.

2. Not planning for human handoff. No bot handles 100% of conversations. You need a clear path for escalating to a human agent. We use Chatwoot for this — the bot handles routine questions, and complex issues are seamlessly transferred to a person. Reader perk: **5% off Chatwoot Cloud with code UJR5GXWK.

3. Ignoring the conversation window. With the official API, you have a 24-hour window to respond to a customer's message for free. After that, you need to use a pre-approved template (which costs money). Design your bot to respond instantly.

4. Overcomplicating the bot. Start with 5-10 common questions. Get those right. Then expand. A bot that handles 10 things well is better than one that handles 50 things poorly.

5. Not testing with real users. Your team will use the bot differently than your customers. Test with actual customers (or friends who can pretend to be customers) before going live.

Beyond the Bot: Scaling Into Full Automation

A WhatsApp bot is usually the first automation businesses deploy — but it's rarely the last. Once you have conversations flowing in, the natural next steps are:

AI agents for business — move from scripted replies to autonomous agents that handle multi-step tasks (lookup orders, escalate tickets, schedule appointments) without hand-written flows.
Broader business automation — the same n8n instance that powers your bot can automate invoicing, CRM updates, lead routing, and inventory sync. One workflow engine, many business processes.
Dedicated customer service chatbots — once your WhatsApp flow is stable, the same stack can power an omnichannel support bot (web chat + Messenger + email) with ticket routing and SLA tracking.

Most of our clients start with a WhatsApp bot and expand outward as they see ROI.

Getting Started

Building a WhatsApp bot doesn't have to be complicated or expensive. Start with a clear goal ("I want to handle appointment bookings automatically"), choose your API approach, and build from there.

If you want help building your WhatsApp bot — whether it's a simple FAQ responder or a full AI-powered agent — reach out to us. At Achiya Automation, we specialize in WhatsApp bots, business automation, and CRM integration using open-source tools.

I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked)

אחיה כהן — Sun, 19 Apr 2026 18:48:16 +0000

Or: why every browser-automation MCP uses Chromium, and why that's the wrong default on macOS.

The problem I kept hitting

Every browser automation MCP server I tried on my Mac — chrome-devtools-mcp, playwright-mcp, browsermcp, puppeteer-mcp — did the same thing: spin up a fresh Chromium instance with nothing in it. No logins, no cookies, no session state. Then my AI agent would spend the first 5 minutes of every task navigating Cloudflare, solving reCAPTCHA, or explaining to me that it couldn't log into Gmail.

Which is weird, because I was already logged into Gmail. In Safari. In the window right next to me.

The disconnect bothered me enough that I started reading Chromium-MCP source code. And what I found is that the entire ecosystem is built on an assumption that quietly doesn't hold for macOS users: "just spin up Chromium, it'll be fine."

It isn't fine.

What Chromium costs on Apple Silicon

Every Chromium process on M1/M2/M3 Macs pays a non-trivial tax:

Multiple helper processes per tab (GPU, renderer, network, storage)
WebKit-parity emulation that duplicates what Safari's WebKit gives you for free
RAM spike on tab open, and fans audibly spinning up
No access to the user's existing Safari extensions, iCloud Keychain, Apple Pay, or ApplePay-linked banking session

When you have a laptop on your lap, you feel every one of these.

The headless-browser fallacy

The first thing people say is: "use headless mode, it's lighter." Sort of. Headless Chromium is still Chromium — you've just hidden the window. More importantly, headless mode is what gets you blocked. Cloudflare, reCAPTCHA v3, Akamai, DataDome — they all fingerprint headless browsers within seconds. Your agent's first action on 30% of the real web becomes "prove you're human."

A headful browser running on your actual machine, with your actual fingerprint, doesn't have this problem. But headful Chromium-MCP means now you have two browsers open — Safari (which you're using) and Chromium (which your agent is using). That's a fan-melting setup.

The alternative no one was building

What I wanted was obvious once I said it out loud:

Drive the Safari the user already has open. Inherit their logins, cookies, extensions, Apple Pay session. Use the WebKit process that's already running. Don't spin up a second browser.

What I found out when I tried to build it: macOS has made this weirdly hard, and I think that's why nobody had done it.

The three things that kept breaking

1. React's _valueTracker.
You can't just set input.value = "hello" and call dispatchEvent("input"). React has an internal _valueTracker on every controlled input that decides whether your "input" event is real. If the tracker thinks the value didn't change, React ignores you. Fixing this means reaching into React's internal state and calling setter.call(input, value) via the prototype's native setter. It works, but it's the kind of code you don't write until you've spent an afternoon wondering why your form submission silently fails on every SPA.

2. Shadow DOM traversal.
Modern web components hide everything behind shadowRoot. document.querySelector stops at the shadow boundary. You need a recursive walker with a MutationObserver cache, because otherwise traversing a single YouTube page costs you 200ms. And if you get the cache invalidation wrong, clicks land on stale element refs.

3. CSP.
About 30% of high-value pages (Google Search Console, LinkedIn, Gmail's admin console, many banks) block inline eval and Function() via strict Content Security Policy. Pure JavaScript injection fails silently. The workaround is a 4-strategy fallback chain: try regular JS → try document.evaluate → try AppleScript do JavaScript → try an injected content script via a Safari extension. Each one has its own failure modes and you only know which applies by trial.

I ended up writing this out on HackerNoon last week, because the reverse-engineering took long enough that it felt worth sharing: the three hardest problems.

The unintentional side effects

After a couple of months of using Safari-backed MCP instead of Chrome-backed MCP, I noticed a few things I wasn't expecting:

My battery lasted measurably longer on coding-agent-heavy days. No surprise in retrospect — one browser instead of two.
My agent's success rate on "just book this for me" tasks went up. It was already logged into the calendar, the banking app, the booking portal.
I stopped having to re-authenticate everything every time I rebooted. Because the agent uses the browser I was already using.
Safari stays in the background. MCP calls run via AppleScript + a persistent Swift daemon. The window doesn't steal focus, so I can keep working while an agent finishes a long task.

Boring outcomes, maybe. But they compound over a workday.

Why this doesn't generalize

A caveat: this approach only makes sense on macOS. On Linux or Windows, Chromium is the right default — there's no equivalent "browser the user is already using" with the same automation surface. And you give up Chrome DevTools' performance traces and Lighthouse, which don't have Safari equivalents. I still keep Chrome DevTools MCP installed for those specific audits.

But "daily browsing tasks" — navigate, click, fill a form, extract some data, take a screenshot — those are 95% of what AI agents do with browsers. And for that 95%, on macOS, it's worth reconsidering the default.

If you want to try it

The project is called Safari MCP. It's MIT-licensed, one npx command to install, and works with Claude Code, Claude Desktop, Cursor, Windsurf, and VS Code:

npx safari-mcp

80 tools covering the full MCP surface — navigation, clicks, forms, screenshots, network mocking, cookies, accessibility snapshots, performance metrics. The README covers setup for each MCP client.

If you've been feeling the Chromium tax on Apple Silicon, maybe give this a try. And if it works for you, a star on GitHub helps other macOS developers find it.

Written after a few months of running Safari MCP as my primary browser automation tool on an M3 MacBook Air. Your mileage will vary — I'd love to hear what breaks for you.

Tags: mcp, claude, macos, webautomation, webdev

I Tried to Auto-Launch My MCP Server Using My MCP Server. It Found Its Own Bug.

אחיה כהן — Tue, 14 Apr 2026 20:04:02 +0000

TLDR

I built safari-mcp, an MCP server that lets AI agents drive Safari natively on macOS. This week I shipped a discoverability push for it: post the launch announcement to Hacker News, X, LinkedIn, and Reddit. Naturally, I tried to automate the campaign using safari-mcp itself.

It worked for HN. It worked for X. Then LinkedIn started running clicks on a completely different tab — Catchpoint Internet Performance Monitoring, which I'd never visited. Three windows, a URL prefix match, and a 500 ms cache TTL conspired to teach me a lesson about tab identity.

Here's the detective story, the root cause, and the fix that ships in v2.8.3 today.

The Setup: Eating My Own Dog Food

I had four launch targets:

Show HN — submit the link, post a first comment
X (Twitter) — a single thread that quotes the article
LinkedIn — a Hebrew-English bilingual long-form post
Reddit r/ClaudeAI — a tool-launch-with-context post

I'd just shipped a HackerNoon technical deep-dive about how I built browser automation for a browser that has no Chrome DevTools Protocol. The launch was the natural follow-on. And of course I was going to drive it through safari-mcp — what's the point of building a Safari automation tool if you don't use it for your own launch?

"Eat your own dog food at launch — bugs surface fast." — me, after this incident.

Round 1: HN and X Worked Beautifully

The HN submission flow was textbook. Open news.ycombinator.com/submit, fill the title and URL inputs, call form.submit() via injected JS, follow the redirect, find the new item ID via submitted?id=<user>. About 8 seconds end-to-end.

// Verify the form is real, not some other tab
JSON.stringify({
  url: location.href,
  hasTitleInput: !!document.querySelector('input[name="title"]'),
  hasUrlInput: !!document.querySelector('input[name="url"]')
})
// → {"url":"https://news.ycombinator.com/submit","hasTitleInput":true,"hasUrlInput":true}

Filled both inputs. Called form.submit(). Got redirected to /newest. Walked back to /submitted?id=Achiyacohen and confirmed the new post sat at #1 with 1 point. Live.

X was even smoother. The compose textbox in x.com/home is a contenteditable with aria-label="Post text". I filled it with the thread text, found the button[data-testid="tweetButtonInline"], dispatched a React-aware pointer event sequence (mousedown → mouseup → click), and watched the textbox empty itself. Verified by reading the user's profile timeline 30 seconds later: the tweet was there, with my exact text and a fresh status/2044134672683110740 URL. Live.

Two for two. I was feeling good.

Round 2: Then LinkedIn Got Weird

LinkedIn's "Start a post" button (in Hebrew: "כתבו פוסט") is a div with class names like _73dfa4c8 ed6e5932 _1d1c97a4. I found it, dispatched the same React-aware click sequence, and waited for the compose modal to appear.

It didn't.

I called safari_evaluate to check whether [contenteditable="true"] had appeared anywhere on the page. The result came back empty — zero contenteditable elements. That was strange. Even the LinkedIn feed itself has search inputs and other interactive elements. So I asked the page for its URL and title to make sure I was in the right place.

The response:

{
  "title": "API Monitoring | Catchpoint Internet Performance Monitoring",
  "url": "https://www.catchpoint.com/application-experience/api-monitoring?utm_campaign=Hackernoon-TOFU-billboard"
}

Catchpoint. I'd never visited Catchpoint.

The First Suspicion: Tab Tracking

The first hypothesis was that safari-mcp's tab tracking had drifted. The MCP keeps a cached _activeTabIndex in memory and uses it for all subsequent operations on a tab it opened. The cache has a TTL of 500 ms, after which resolveActiveTab re-verifies by URL prefix matching.

I called safari_list_tabs and got 12 tabs in the profile window — but with the LinkedIn tab right where I expected it. So the cache and the actual tab layout agreed: tab 12 was LinkedIn.

Then why was safari_evaluate returning Catchpoint?

Detective Work: There Are Three Windows

I dropped down to raw AppleScript to bypass the MCP layer:

tell application "Safari"
  set output to ""
  set wCount to count of windows
  set output to "Total windows: " & wCount & linefeed
  repeat with w from 1 to wCount
    set output to output & "Window " & w & ": " & (count of tabs of window w) & " tabs" & linefeed
    set output to output & "  name: " & (name of window w) & linefeed
    set output to output & "  tab1: " & (URL of tab 1 of window w) & linefeed
  end repeat
  return output
end tell

Output:

Total windows: 3
Window 1: 2 tabs
  name: אישי — Documenso
  tab1: https://mail.google.com/mail/u/0/#starred/...
Window 2: 12 tabs
  name: אוטומציות — API Monitoring | Catchpoint Internet Performance Monitoring
  tab1: https://hackernoon.com/login?redirect=app
Window 3: 3 tabs
  name: אישי — תוכנה קלה לשליחה למחשב מרחוק - Claude
  tab1: https://claude.ai/recents

Three windows. Two profiles ("אישי" / Personal and "אוטומציות" / Automation). Safari MCP was correctly targeting Window 2 ("אוטומציות"), where my LinkedIn tab actually lived as tab 12. So far so good.

The Catchpoint URL? It was tab 5 of Window 2 — a tab the user (me) had clicked open earlier from a HackerNoon ad without thinking. It was sitting there idle. And somehow safari_evaluate was hitting it instead of tab 12.

The Real Bug: Resolve Cache + URL Prefix

I traced through resolveActiveTab line by line:

async function resolveActiveTab() {
  if (!_activeTabURL) return _activeTabIndex;

  const safeUrl = _activeTabURL.replace(/"/g, '\\"');
  const domain = _activeTabURL
    .replace(/^https?:\/\//, '')
    .split('/')[0];

  const result = await osascriptFast(`
    tell application "Safari"
      set w to ${getTargetWindowRef()}
      set tabCount to count of tabs of w

      // Strategy 1: verify cached index still matches URL
      try
        if tabCount >= ${_activeTabIndex} then
          if URL of tab ${_activeTabIndex} of w starts with "${safeUrl}" then
            return ${_activeTabIndex}
          end if
        end try
      end try

      // Strategy 2: search all tabs by URL prefix
      repeat with i from tabCount to 1 by -1
        if URL of tab i of w starts with "${safeUrl}" then return i
      end repeat

      // Strategy 3: search by domain (returns negative — partial match)
      repeat with i from tabCount to 1 by -1
        if URL of tab i of w contains "${domain}" then return -(i)
      end repeat

      return "0:" & tabCount
    end tell
  `);
  // ...
}

The bug was right there in the strategies. When I navigated LinkedIn to https://www.linkedin.com/feed/, that became _activeTabURL. Then LinkedIn's React router silently rewrote the URL to https://www.linkedin.com/feed/?shareActive=true because of the query parameter I'd passed. Strategy 1 — the fast path — failed because URL of tab 12 starts with "https://www.linkedin.com/feed/"... wait, that should still match. The new URL starts with the old prefix.

So why did it fail?

The actual cause was even more subtle: a different Safari instance, in a different profile window, had completed an HTTP redirect that rewrote the URL to a shorter form. AppleScript's URL of tab was returning the post-redirect URL, which did not start with my saved _activeTabURL because _activeTabURL had query parameters that the post-redirect URL didn't.

Strategy 1 fell through. Strategy 2 (full URL search across all tabs) also fell through for the same reason. Strategy 3 (domain search) found... a tab in the wrong profile window? No — it found Catchpoint. Why?

Because of how I'd extracted the domain:

const domain = _activeTabURL.replace(/^https?:\/\//, '').split('/')[0];
// "www.linkedin.com"

And the AppleScript:

if URL of tab i of w contains "${domain}" then return -(i)

contains is a substring match. Catchpoint's ad URL was https://www.catchpoint.com/.../?utm_campaign=Hackernoon-TOFU-billboard&utm_source=hackernoon&utm_medium=paidsocial. Did it contain www.linkedin.com? No.

Wait, then how did it match?

After two more hours of tracing, I found the actual cause. The MCP server runs as a singleton, but Claude Code occasionally spawns a second instance for ~40 ms during connection negotiation. That second instance had its own _activeTabIndex state, and it had set the index to point at Catchpoint because it saw Catchpoint as the active tab when it briefly took over. When the original instance came back, it read the wrong index from a stale cache check that hadn't yet been invalidated by the singleton kill code.

The 500 ms cache window was just long enough for that race.

The Fix: window.__mcpTabMarker

URL prefix matching is fragile. Domain matching is fragile. Cached indices are fragile. What's not fragile?

A unique identifier injected into the page's JavaScript context.

The new fix: every safari_new_tab writes a unique marker into window.__mcpTabMarker:

const tabMarker = `MCP_${SESSION_ID}_${Date.now().toString(36)}_${Math.random().toString(36).slice(2, 8)}`;
await osascriptFast(
  `tell application "Safari" to do JavaScript "window.__mcpTabMarker='${tabMarker}'" in tab ${_activeTabIndex} of ${getTargetWindowRef()}`
);
_activeTabMarker = tabMarker;

The marker survives:

Same-tab navigation — window.__mcpTabMarker lives in the JS realm, which persists across location.href = ... if the new URL is same-origin. For cross-origin navigations it gets wiped, which is fine because that's a deliberate context boundary.
Hash changes — location.hash = "#x" doesn't reload the JS context.
pushState and replaceState — single-page-app routers don't reset the realm.
Query string mutations — same as above.
Redirects within the same origin — still in the same realm.

resolveActiveTab now tries the marker first:

async function resolveActiveTab() {
  // Strategy 1: window.__mcpTabMarker (bulletproof)
  if (_activeTabMarker && _activeTabIndex) {
    const checkScript = `(function(){return window.__mcpTabMarker==='${safeMarker}'?'1':'0'})()`;

    // Check cached index first (fast path)
    const matchAtCached = await osascriptFast(
      `tell application "Safari" to do JavaScript "${checkScript}" in tab ${_activeTabIndex} of ${getTargetWindowRef()}`
    );
    if (matchAtCached === '1') return _activeTabIndex;

    // Cached index doesn't match — scan all tabs in profile window
    const tabCount = Number(await osascriptFast(
      `tell application "Safari" to return count of tabs of ${getTargetWindowRef()}`
    ));
    for (let i = tabCount; i >= 1; i--) {
      const m = await osascriptFast(
        `tell application "Safari" to do JavaScript "${checkScript}" in tab ${i} of ${getTargetWindowRef()}`
      );
      if (m === '1') {
        _activeTabIndex = i;
        return i;
      }
    }
  }

  // Strategy 2: URL prefix (fallback for tabs created before the marker was set)
  // ...
}

The marker check costs about 5 ms per tab via the persistent osascriptFast daemon. On a tab list of 12 tabs, the worst case is 60 ms — slower than the previous "check cached index" path, but correct.

I also dropped the resolve cache from 500 ms to 100 ms. The check is cheap enough that the tighter cache buys us correctness without measurable latency.

The Bypass Tool I Built While Debugging

While I was tracing the bug, I needed a way to test changes against Safari without restarting the MCP server (which would require restarting the Claude Code session). So I wrote a Python wrapper that calls osascript directly, with one job: find a tab by URL prefix in a specific window, then run JS in that exact tab.

def run_js(url_prefix, js_code, window=2):
    js_clean = strip_line_comments(js_code)
    js_escaped = (
        js_clean.replace("\\", "\\\\")
                .replace('"', '\\"')
                .replace("\r", "")
                .replace("\t", " ")
    )
    return subprocess.run(
        ["osascript", "-"],
        input=f'''
tell application "Safari"
  set tCount to count of tabs of window {window}
  set foundIdx to 0
  repeat with i from 1 to tCount
    if URL of tab i of window {window} starts with "{url_prefix}" then
      set foundIdx to i
      exit repeat
    end if
  end repeat
  if foundIdx = 0 then return "ERROR_NO_TAB"
  set jsOut to do JavaScript "{js_escaped}" in tab foundIdx of window {window}
  return "tab:w{window}_" & foundIdx & "|" & jsOut
end tell
''',
        capture_output=True,
        text=True,
        encoding="utf-8",
    )

This bypassed every layer of the MCP and gave me direct, predictable access to whichever tab I wanted in whichever window I wanted. Three rules I learned writing it:

AppleScript's result is a reserved word. Don't name your variable result. Use jsOut or output or anything else. The error message you get is "המשתנה result אינו מוגדר" if your system locale is Hebrew, which is unhelpful unless you happen to know that result is taken.
do JavaScript returns immediately for any expression that's not a synchronously-resolved value. Promises return undefined. Async functions return their [[PromiseState]] representation, which AppleScript silently coerces to "missing value", which then triggers "המשתנה X אינו מוגדר" downstream. Workaround: write the result to window.__myResult from a .then() callback, then poll for it with a second do JavaScript call.
Hebrew text in shell variables breaks AppleScript. When you bash -c "osascript -e '...$VAR...'", the UTF-8 round-trip through shell substitution corrupts Hebrew bytes. The fix is to call osascript - with the script on stdin, in Python or Ruby or any language that handles UTF-8 natively.

How LinkedIn Was Actually Posted

After all that, I still couldn't get LinkedIn's compose modal to open via clicks, even with the bypass tool. LinkedIn's React event handlers check event.isTrusted, which is false for any event dispatched by user JavaScript. Synthetic clicks just get dropped on the floor.

So I gave up on the modal entirely and used LinkedIn's own voyager API directly:

var match = document.cookie.match(/JSESSIONID="?([^";]+)"?/);
var csrf = match[1];

fetch("https://www.linkedin.com/voyager/api/contentcreation/normShares", {
  method: "POST",
  credentials: "include",
  headers: {
    "csrf-token": csrf,
    "content-type": "application/json; charset=UTF-8",
    "accept": "application/vnd.linkedin.normalized+json+2.1",
    "x-restli-protocol-version": "2.0.0"
  },
  body: JSON.stringify({
    visibleToConnectionsOnly: false,
    commentaryV2: { text: postBody, attributes: [] },
    origin: "FEED",
    allowedCommentersScope: "ALL",
    postState: "PUBLISHED",
    media: []
  })
}).then(function(resp){
  return resp.text().then(function(t){
    window.__mcpLinkedinResult = JSON.stringify({status: resp.status, body: t.substring(0, 500)});
  });
});

The csrf-token header is just the value of the JSESSIONID cookie that LinkedIn sets during login. Once you're authenticated, the API accepts your request and returns:

{
  "status": 201,
  "ok": true,
  "body": "{\"status\":{\"urn\":\"urn:li:share:7449905229468274688\",\"toastCtaText\":\"צפייה בפוסט\",\"mainToastText\":\"פרסום הפוסט הצליח.\"}}"
}

"פרסום הפוסט הצליח" — "Post published successfully". The bypass worked. LinkedIn was live.

What Reddit Taught Me

Reddit was my one failure. The user account in window 1 (Personal profile) was logged in. The form on old.reddit.com/r/ClaudeAI/submit filled correctly. The CSRF token (uh field) was present. I built a FormData POST to /api/submit, included all the required fields, and fired it.

Response:

{"json": {"errors": [["BAD_CAPTCHA", "That was a tricky one. Why don't you try that again.", "captcha"]]}}

Reddit's /api/submit endpoint requires a solved reCAPTCHA token, even for fully-authenticated users. There's no API path that bypasses this. There's no honor-system "I'm a real human" header. The only ways through are:

Pay a CAPTCHA-solving service ($1-2 per 1000 captchas, with all the ethical and TOS implications you'd expect)
Have a human solve it
Don't post to Reddit

I picked option 3. I respect the captcha as a clearly-stated boundary.

Lessons

Eat your own dog food at launch. I'd been running safari-mcp for daily browser automation tasks for weeks and never hit this bug. It took the specific combination of "rapid sequence of operations across multiple Safari windows with same-domain tabs and React-driven URL rewrites" to surface it. A launch campaign happens to involve exactly that combination.

Multi-window/multi-profile is a forgotten edge case in browser automation. Most automation tools assume one window or have a strict "first window" convention. Safari's profile feature (introduced in macOS Sonoma) makes multi-window the default for power users. If you write a Safari automation tool, test with three profile windows open from day one.

URL matching is fragile; identity markers in the JS context are bulletproof. This is the takeaway I wish someone had told me three weeks ago. Don't track tabs by URL or title or any other property the page can mutate. Inject a marker into the page's JS realm and check for it.

Cache TTL is a knife edge. 500 ms felt safe. It wasn't. 100 ms with a cheap revalidation check is the sweet spot for this workload. Your sweet spot may differ — measure it.

When debugging, build a bypass tool. Don't fight the bug from inside the affected layer. Route around it. The 60 lines of Python I wrote in the middle of this incident saved me hours of MCP restart cycles, and I get to keep them as a permanent low-level escape hatch.

Some platforms genuinely don't want automation. That's their right. Respect it.

Status

safari-mcp v2.8.3 ships the marker fix today. npm, GitHub, MCP Registry.
The launch campaign worked: HN post live, X tweet live, LinkedIn post live (via the API bypass), Reddit deferred.
The bug-find-fix loop took about 90 minutes. The article you're reading took longer.

If you build MCP servers, automation tools, or anything that touches a multi-window browser, I'd love to hear how you've solved tab identity. Drop a comment or open an issue on achiya-automation/safari-mcp. I learn from every reply.

And if you're considering using your own tool to launch your own tool — do it. The bugs you'll find are the bugs your users would have hit first.

I've Deployed 50+ WhatsApp Bots — Here's How the Spam Detection Algorithm Actually Works in 2026

אחיה כהן — Sun, 12 Apr 2026 19:20:59 +0000

After deploying 50+ WhatsApp bots for businesses, I've learned the hard way how WhatsApp's spam detection works. Not from documentation — from watching accounts get restricted and figuring out why.

Here's the real picture in 2026.

The 4-Layer Detection System

WhatsApp doesn't use a single algorithm. It's a pipeline:

Layer 1: Registration Fingerprinting

Before you send a message, WhatsApp analyzes your registration signal — device metadata, IP clusters, phone number patterns, registration velocity. Bulk-registered numbers on VPS servers get flagged immediately.

Layer 2: Behavioral Analysis (Where Bots Get Caught)

This is the critical layer. WhatsApp monitors:

Send velocity — messages per minute/hour/day
Reply-to-send ratio — if you send 100 messages and get 5 replies, that's a 5% ratio = spam signal
Message timing patterns — bots send at precise intervals; humans don't
Contact interaction history — messages to contacts who never messaged you weigh more heavily

From our deployments, here are the thresholds I've observed:

Metric	Safe	Warning	Danger
Messages/hour	< 30	30-60	> 60
Reply rate	> 30%	15-30%	< 15%
New contacts/day	< 20	20-50	> 50
Identical messages	< 5/hr	5-15/hr	> 15/hr

Based on observations across 50+ deployments, not official Meta docs.

Layer 3: User Reports

Every block or spam report adds negative signal. Block rate > 2% = quality rating drops to "Low". Multiple reports in 24 hours = temporary restriction.

Layer 4: Content Pattern Matching

WhatsApp analyzes message metadata (length, media, links), forward patterns, and template similarity — without reading encrypted content.

The Big 2026 Change: Unanswered Message Counter

The most significant change this year: WhatsApp now tracks messages sent that received no reply within 48 hours.

This counter is:

Cumulative — counts across all conversations
Time-bounded — rolling 30-day window
Universal — affects both official and unofficial API

We saw this hit a dental clinic client running appointment reminders via the official API. Fully compliant, template-approved, opt-in collected. But 40% of patients confirmed by showing up, not replying to WhatsApp.

The fix: We added "Reply 1 to confirm, 2 to reschedule" to every reminder. Reply rate jumped from 60% to 89%. Quality rating recovered in two weeks.

Official vs Unofficial API: Risk Comparison

Aspect	Official API	Unofficial (WAHA/Baileys)
Registration ban	None	Medium
Behavioral ban	Low (templates enforce limits)	High
User report ban	Low (warnings first)	High (direct ban)
Recovery	Appeal through Meta	Permanent, no appeal
Cost	BSP $50-100/mo + per-msg	Server $5-20/mo

Key insight: Unofficial API bots that only respond to incoming messages have <2% ban rate over 12 months. Bots that proactively message new contacts see 15-30% ban rates.

7 Rules We Follow for Every Bot

Official API for proactive messaging — templates exist to keep you compliant
Explicit opt-in — not buried in ToS. Real: "I want reminders via WhatsApp"
Design for replies — quick-reply buttons, yes/no questions. Reply rate = trust signal
Rate-limit sending — 50-100/batch for marketing, 5-min gaps
Monitor quality rating weekly — Meta Business Suite → Phone Numbers
Segment audience — don't message contacts silent for 90+ days
Human escalation after 2 failed bot responses — frustrated users report + block

What If You're Already Restricted?

Official API: Pause marketing templates, improve reply rates, wait 7 days for quality re-evaluation.

Unofficial API: Stop proactive messaging immediately. If banned, the number is gone. Migrate to official API.

The algorithm isn't adversarial toward legitimate businesses. The formula:

Official API + Opt-in + Relevant Messages + Reply-Encouraging Design = Zero Risk

Full deep-dive with all technical details: WhatsApp Spam Detection Algorithm 2026

MCP vs CLI for Browser Automation: I Benchmarked Both and the Results Surprised Me

אחיה כהן — Sat, 11 Apr 2026 23:10:53 +0000

Three weeks ago I published safari-mcp — a macOS-native Safari automation server that speaks the Model Context Protocol. 84 tools, AppleScript + optional extension for speed, keeps Safari logins, zero Chrome overhead. Today it's in the VS Code and Cursor marketplaces.

Then I saw HKUDS/CLI-Anything — a 29k-star project that auto-wraps open-source software as agent-ready CLIs. Their pitch: "Make ALL software agent-native." Their main example is DOMShell wrapped as cli-anything-browser — a shell-pipeable interface for Chrome automation.

I wanted to know: is wrapping safari-mcp as a CLI actually worth it? Or is it pure theater — re-exposing a working MCP server as a strictly worse interface?

So I built the harness (PR #212) and benchmarked it live against the direct MCP path. Real Safari, real macOS, measured on 2026-04-10.

Here's what I found.

TL;DR

	MCP (direct stdio)	CLI (subprocess per call)	Winner
Per-call latency	119ms	3,023ms	MCP, 25×
5-op workflow	2.7s	15.2s	MCP, 5.6×
Tokens per API call (tool defs)	7,986	95	CLI, 84×
Output accuracy	identical	identical	tie

If your agent speaks MCP (Claude Code, Cursor, Cline, Windsurf, Continue, OpenClaw, any MCP-aware client) — use the MCP directly. The CLI is strictly slower.
If you need to drive it from bash, CI, cron, or an agent that doesn't speak MCP — use the CLI. The token savings compound; at Claude Opus pricing, a 100-turn session saves ~$12 in tool-definition overhead alone.

That's the whole story. If you only wanted the numbers, you can stop here. If you want the methodology, the edge cases, and the bugs I hit along the way, read on.

What I actually built

The harness (safari/agent-harness/) is a schema-driven CLI generator:

Offline Zod parser (scripts/extract_tools.py) reads safari-mcp's source and emits resources/tools.json — the full schema for all 84 tools. Depth-aware, handles nested z.array(z.object({...})).describe("outer") correctly.
Runtime Click generator (safari_cli.py) loads the registry at import time and builds one Click subcommand per MCP tool. Argument names, types, enum choices, required flags, and descriptions are all pulled from the schema. Zero manual mapping.
Parity test suite (test_parity.py) iterates the registry and verifies every tool is reachable, every param is wired correctly, every enum matches. If the registry and the CLI ever drift, the tests scream.

The CLI surface ends up looking like this:

$ cli-anything-safari tools count
84

$ cli-anything-safari tools describe safari_click
Name:        safari_click
CLI command: tool click
Description: Click element. Use ref (from snapshot), selector, text, or x/y...
Parameters:
  --ref (string, optional)
  --selector (string, optional)
  --text (string, optional)
  --x (number, optional)
  --y (number, optional)

$ cli-anything-safari --json tool snapshot
"ref=0_0 body\nref=0_1 div\nref=0_2 navigation \"Sidebar\"\n..."

Same interface as the upstream MCP, just behind click.command(...) calls.

The benchmark setup

Both paths hit the same safari-mcp server in the end. The difference is the connection model:

MCP direct:  Python → stdio (persistent) → safari-mcp → Safari
CLI:         Python → subprocess → npx → Node → safari-mcp → Safari

For MCP I used mcp.ClientSession with a persistent stdio connection, measuring only the call_tool() round-trip (initialization amortized). For CLI I measured subprocess.run([...]) wall time. Both had one warmup call that I discarded.

The benchmark script is at /tmp/benchmark_cli_vs_mcp.py (not committed because it's scratch); the key loop is:

# MCP: persistent session, N calls
async with stdio_client(params) as (read, write):
    async with ClientSession(read, write) as session:
        await session.initialize()
        await session.call_tool(tool_name, args)  # warmup
        for _ in range(n):
            t0 = time.perf_counter()
            await session.call_tool(tool_name, args)
            times.append((time.perf_counter() - t0) * 1000)

# CLI: spawn per call
for _ in range(n):
    t0 = time.perf_counter()
    subprocess.run(CLI + ["tool", tool_short_name] + args_list,
                   capture_output=True, text=True)
    times.append((time.perf_counter() - t0) * 1000)

Latency — MCP wins by 25×

Ten calls of safari_list_tabs (warm cache, same Safari state):

                  MCP (ms)    CLI (ms)       ratio
  min                113.3      2970.2       26.2×
  median             119.5      3026.1       25.3×
  mean               119.3      3022.7       25.3×
  max                123.7      3097.2       25.0×

CLI calls land at ~3 seconds every single time, with almost no variance. That consistency is the giveaway: the bottleneck is not safari_list_tabs itself — it's the ~2.9 seconds that go into npx resolution, Node.js startup, safari-mcp initialization, and MCP handshake for every fresh subprocess.

MCP amortizes all of that across a single persistent session. Once the session is up, each additional tool call is just the ~100ms AppleScript operation.

For interactive reactive workflows — agents that take each result and decide the next step — MCP is the obvious choice. Every round-trip matters.

Workflow — MCP still wins on reactive sequences

I ran a 5-op workflow (snapshot → read_page → list_tabs → snapshot → read_page) three ways:

  MCP (persistent, 5 ops)           2,714 ms
  CLI (5 sequential spawns)        15,285 ms
  CLI (1 shell pipeline, 5 ops)    15,153 ms

Shell pipelining — cli-anything-safari tool X && cli-anything-safari tool Y — does not help. Every && still spawns a fresh npx subprocess. The overhead per step is unchanged.

The only way to amortize the cost is to drive the Python API directly (from cli_anything.safari.utils.safari_backend import call). If you do that, you're back to roughly MCP-class numbers because you're just using the MCP Python SDK under a different name.

The CLI's per-call cost is structural. You cannot pipeline your way out of it.

Tokens — CLI wins by 84×

This is where the picture inverts. When an LLM uses MCP tools, every API call includes the full tool definitions in the request. For safari-mcp that's 84 tools × ~95 tokens each = ~7,986 tokens on every turn.

I measured this with the real tools.json and the cl100k_base tokenizer (tiktoken):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
mcp_response = {"tools": [
    {"name": t["name"], "description": t["description"], "inputSchema": t["inputSchema"]}
    for t in tools
]}
tokens = len(enc.encode(json.dumps(mcp_response)))
# 7,986 tokens for 84 tools

The CLI path sends ~95 tokens — just the bash tool definition. The agent learns the CLI surface by running cli-anything-safari tools list --json once (5,236 tokens, one-time) and the info sits in the conversation context.

At Claude Opus pricing ($15/MTok input, no caching):

Session length	MCP overhead	CLI overhead	Savings
10 turns	$1.20	$0.09	$1.11
100 turns	$11.98	$0.22	$11.76
1,000 turns	$119.79	$1.60	$118.19

Prompt caching narrows this considerably — Anthropic lets you cache tool definitions at $3.75/MTok on first write and $1.50/MTok on reads, roughly a 10× discount. With caching the MCP cost drops from ~$12 to ~$1.50 per 100-turn session. Still more expensive than CLI, but the gap is smaller.

The takeaway: for short, reactive sessions (where you care about UX and per-call latency), MCP wins hands-down. For long, scripted sessions at scale (where tool-definition overhead becomes a real line item), the CLI's token efficiency is genuine and measurable.

Accuracy — tie

Both paths call the same safari-mcp server. Both go through the same AppleScript → Safari chain. The CLI is a thin subprocess wrapper that serializes the MCP CallToolResult.content into stdout via a small _unwrap() helper:

def _unwrap(result):
    parts = []
    for item in result.content:
        text = getattr(item, "text", None)
        if text is not None:
            try:
                parts.append(json.loads(text))
            except (json.JSONDecodeError, ValueError):
                parts.append(text)
            continue
        # ImageContent: returned by screenshot tools
        data = getattr(item, "data", None)
        if data is not None:
            parts.append({"type": "image", "data": data,
                          "mimeType": getattr(item, "mimeType", "application/octet-stream")})
            continue
        parts.append(item)
    return parts[0] if len(parts) == 1 else parts

Byte-identical output verified live: the Unicode tab titles returned by cli-anything-safari --json tool list-tabs match the direct MCP output character-for-character, including right-to-left Hebrew.

The bugs that took 5 review rounds to find

I'm not going to pretend the first draft was clean. The schema-driven generator had real bugs that five passes of review (two my own, three by an adversarial code-reviewer agent) surfaced one by one:

Nested .describe() leaked. For z.array(z.object({selector: z.string().describe("CSS selector")})).describe("Array of {selector, value} pairs"), the naive regex picked the inner "CSS selector" as the outer field's description. Four tools had wrong help text. Fixed by walking modifier chains at depth 0 only.
Nested .optional() leaked. Same root cause, different effect — safari_mock_route.response and safari_run_script.steps were marked optional because an inner field had .optional(). The actual MCP schema marks them required. This one silently produced wrong JSON schemas; the fix was depth-aware modifier detection everywhere.
_unwrap() silently dropped screenshot output. It only handled TextContent, not ImageContent. For two tools (safari_screenshot, safari_screenshot_element), the CLI returned null with exit code 0 instead of the base64 JPEG. Caught on the fourth review round after I'd already declared "100% compliance."
safari_evaluate parameter name is script, not code. The tool description said "JavaScript code to execute" so I wrote every documentation example as --code "document.title". The parser auto-generated the CLI correctly from the schema (--script), so the CLI worked, but every doc example in SKILL.md, README.md, and my test file was wrong. Caught on the fourth review round when the reviewer cross-referenced docs against the schema.
doubleClick: z.boolean().default(false) serialized the default as the string "false". Not broken at runtime (Click ignores it) but wrong in the bundled JSON schema. Fixed by adding a _coerce_default() step that parses JS barewords into their Python equivalents.

Every bug except #5 had a corresponding regression test added to test_parity.py after the fix. The file is now 24 tests, including explicit assertions like:

def test_evaluate_param_is_script_not_code(self):
    """Regression: prior versions used 'code' by mistake."""
    tool = self.registry.get("safari_evaluate")
    assert "script" in {p.name for p in tool.params}
    assert "code" not in {p.name for p in tool.params}

The lesson I kept re-learning: if you wrote the code, you can't review it yourself. You read your own docs through your own mental model of what the code does. You need an adversary — either a human with fresh eyes or an agent with no context — to catch the bugs your mental model papers over.

When to use which

Decision tree (read left to right):

Does your agent speak MCP natively?
├── Yes → Use safari-mcp directly. 25× faster, better UX.
└── No
    ├── Is this a one-off / interactive script?
    │   └── Yes → Use cli-anything-safari. jq-pipeable.
    ├── Long-running automation, cost matters?
    │   └── Yes → cli-anything-safari. Token savings compound.
    ├── CI / cron / non-interactive automation?
    │   └── Yes → cli-anything-safari. Subprocess-friendly.
    └── Everything else → try MCP first, fall back to CLI if needed.

For Claude Code, Cursor, Cline, Windsurf, Continue, OpenClaw, VS Code MCP — all MCP-native. Use safari-mcp directly:

npm install -g safari-mcp
# Then add to your MCP client config and restart it.

For Codex CLI, GitHub Copilot CLI, older agent frameworks, shell scripts, cron jobs:

# After the CLI-Anything PR merges
pip install cli-anything-safari
cli-anything-safari tools list
cli-anything-safari tool navigate --url https://example.com

What I'd do differently next time

Write the benchmark first. I built the CLI, shipped it, and then benchmarked it. If I'd measured first, I would have avoided ~3 review rounds of "is this even useful?" angst. The answer is nuanced (MCP for latency, CLI for tokens and reach), but I couldn't see that without the numbers.
Schema-driven from day one. The original plan was to hand-wrap 20 curated tools with a raw escape hatch for the rest. That would have been ~1,500 lines of code I'd be maintaining forever. The schema-driven approach is ~300 lines and maintains itself.
Spin up an adversarial reviewer earlier. I used an independent code-reviewer agent on review rounds 2–4. It caught bugs I'd read past a dozen times. Should have used it on round 1.
Token cost is a first-class metric for MCP design. I was thinking about MCP vs CLI in pure latency terms. The token-cost-at-scale axis is genuinely the more important one for long agent sessions, and I should have been measuring it from the start.

I just hardened my OSS release pipeline to 11 layers of security — here's the playbook

אחיה כהן — Sat, 11 Apr 2026 21:58:18 +0000

I just hardened my OSS release pipeline to 11 layers of security — here's the playbook

This weekend I shipped safari-mcp v2.7.9, a minor release on the surface but a complete overhaul of how the project gets published. Along the way I went from "NPM_TOKEN in a workflow secret" to 11 layers of supply-chain defense, all driven by one realistic question: if my GitHub account gets phished tomorrow, how much damage can an attacker do before somebody notices?

If you're a solo maintainer of a JavaScript package, the playbook below is for you. Every step is something I actually did today, with links to the commits, and most of them took under 10 minutes each.

The starting point

Package: safari-mcp on npm (~2000 monthly downloads, 27 stars, MIT)
Release flow: GitHub Actions workflow triggered by release, authenticating with a long-lived NPM_TOKEN stored as a repo secret
Problem: That token could publish anything on my npm account until it expired. If my GitHub got compromised, step one for an attacker would be grabbing the token and uploading a malicious safari-mcp@2.7.10 within minutes.

The goal: make that attack path as hard as possible without turning my release flow into a 20-minute bureaucracy.

Layer 1: npm OIDC Trusted Publisher (no more long-lived token)

npm now supports Trusted Publishers via OIDC. Instead of storing a token, you configure npm to accept short-lived OIDC tokens issued by GitHub Actions — tokens that are cryptographically bound to a specific repository + workflow + environment and expire within minutes.

Setting this up on npm takes three fields (org, repo, workflow filename) and one click. After that, the workflow no longer needs NPM_TOKEN; it just needs:

permissions:
  contents: read
  id-token: write  # required for OIDC

steps:
  - run: npm publish --provenance --access public

That --provenance flag adds a SLSA build attestation to the published package, so anyone downloading it can cryptographically verify that safari-mcp@2.7.9 was built by the specific GitHub Actions run I claim it was.

Upgrade path: After configuring Trusted Publisher, delete the old NPM_TOKEN secret. Otherwise it's still a liability.

Layer 2: manual-approval environment gate

OIDC stops token theft. It doesn't stop a compromised workflow file from publishing malware. So I added a GitHub deployment environment called npm-publish with required reviewers (just me) and can_admins_bypass: false.

Now every release pauses in GitHub Actions until I explicitly click "Approve" in the UI. I see the exact SHA, the commit message, and the tag before I let the publish proceed. Even if an attacker has the ability to push to main and has my repo admin privileges, they still can't skip the approval.

Important detail: by default, deployment environments allow admins to bypass. I set it to false because the entire point was to defend against my own compromised credentials. If I get locked out I can always re-enable it from the Settings page, which itself requires passkey reauth.

Layer 3: custom branch policy (tags + main only)

First time I tried to release, the publish workflow failed with:

Tag "v2.7.9" is not allowed to deploy to npm-publish due to environment protection rules.

The default deployment_branch_policy is "protected branches only" — tags don't count as branches. The fix was switching to custom_branch_policies: true and adding two rules:

branch: main
tag: v*

Now both push-to-main deployments and version tag deployments work, but only those. Feature branches can't deploy.

Layer 4: SHA pinning required for all actions

The single biggest OSS supply-chain incident of 2025 was tj-actions/changed-files — thousands of secrets leaked because workflows used @v1 tags that the attacker retagged. The fix is simple but painful: pin every action to a full commit SHA instead of a version tag.

GitHub recently added a repo-level setting to require this:

gh api --method PUT /repos/OWNER/REPO/actions/permissions \
  --input - <<'EOF'
{"enabled": true, "allowed_actions": "all", "sha_pinning_required": true}
EOF

After I enabled this, every CI run failed because my workflows used actions/checkout@v4. I updated them to the equivalent SHA:

- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.0

The comment is important — it's how Dependabot auto-updates the SHA while keeping the version readable.

Layer 5: branch protection on main (signatures required, no force push)

Branch protection for solo maintainers is usually reductive (it blocks your own pushes), but three rules are pure upside:

gh api --method PUT /repos/OWNER/REPO/branches/main/protection --input - <<'EOF'
{
  "required_status_checks": null,
  "enforce_admins": false,
  "required_pull_request_reviews": null,
  "restrictions": null,
  "allow_force_pushes": false,
  "allow_deletions": false,
  "required_conversation_resolution": true
}
EOF

allow_force_pushes: false — stops history rewriting, essential with signed commits
allow_deletions: false — stops accidental git push --delete origin main
required_conversation_resolution: true — every PR comment must be resolved before merge

Then, separately:

gh api --method POST /repos/OWNER/REPO/branches/main/protection/required_signatures

Every new commit on main must carry a verified signature. Commits from unsigned laptops get rejected at push time.

Layer 6: SSH commit signing without losing your mind

Setting up commit signing always feels like yak-shaving. Here's the short version for macOS:

# Generate a dedicated signing key (no passphrase, used ONLY for git sign)
ssh-keygen -t ed25519 -f ~/.ssh/git_signing_ed25519 -N "" -C "git-signing"

# Point git at it
git config --local gpg.format ssh
git config --local user.signingkey ~/.ssh/git_signing_ed25519.pub
git config --local commit.gpgsign true

# Upload to GitHub as a *signing* key (not auth!)
gh ssh-key add ~/.ssh/git_signing_ed25519.pub --type signing --title "git signing"

Gotcha: if your primary ~/.ssh/id_ed25519 has a passphrase, git commit -S will hang forever trying to unlock it without prompting (in a non-interactive shell). The dedicated no-passphrase key avoids that, and since it's only usable for signing — not auth — the security trade-off is small.

Second gotcha: commits aren't shown as "Verified" on GitHub unless the committer email matches a verified email on your GitHub account. If yours doesn't, switch to the <user-id>+<username>@users.noreply.github.com format, which GitHub recognizes automatically.

Layer 7: Approval for outside-collaborator workflows

The default GitHub setting is "Require approval for first-time contributors". That means a malicious user who's had one merged PR 5 years ago can push any workflow to your repo without approval. Ramp it up:

In Settings → Actions → General → Fork pull request workflows from outside collaborators, pick "Require approval for all external contributors". Every outside PR now waits for me to click "Approve and run" before its workflow touches any of my secrets.

Layers 8–11: the boring-but-essential ones

CODEOWNERS — auto-request my review on any PR that touches .github/**, package.json, or native code
Dependabot for GitHub Actions — by default Dependabot only monitors npm / pip / etc. Add github-actions to .github/dependabot.yml so action pins get security updates too
npm WebAuthn 2FA — not new, but confirm your npm account uses a hardware-backed second factor, not just TOTP
package.json overrides — when a transitive dep has a security advisory that the parent hasn't fixed, force the patched version with overrides instead of waiting

What the attack surface looks like now

For an attacker to publish malicious safari-mcp@X.Y.Z to npm, they need to simultaneously:

Compromise my GitHub account (phishing-resistant passkey)
Bypass signed commits on main (signing key on a different laptop)
Either compromise the code review process or commit directly (blocked by required_signatures)
Bypass the npm-publish environment approval (can_admins_bypass: false — not even I can skip it)
Either compromise my local keychain (for the approval click) or the npm OIDC signing key at GitHub Actions runtime

Pre-playbook, the attacker needed: (1) my GitHub token, or (2) the NPM_TOKEN secret. One step.

Post-playbook: five independent, cryptographically-bounded steps — four of which require a different device or a human decision.

The 30-minute version

If you're reading this and thinking "I'll do this later", here's the minimum viable version you can copy-paste right now (replace OWNER/REPO):

# 1. SHA pinning (10s)
gh api --method PUT /repos/OWNER/REPO/actions/permissions \
  --input - <<'EOF'
{"enabled": true, "allowed_actions": "all", "sha_pinning_required": true}
EOF

# 2. Branch protection (10s)
gh api --method PUT /repos/OWNER/REPO/branches/main/protection --input - <<'EOF'
{"required_status_checks":null,"enforce_admins":false,"required_pull_request_reviews":null,"restrictions":null,"allow_force_pushes":false,"allow_deletions":false,"required_conversation_resolution":true}
EOF

# 3. Add github-actions to Dependabot (edit .github/dependabot.yml)
# 4. Enable npm Trusted Publisher on npmjs.com for your package
# 5. Delete NPM_TOKEN secret

Five steps. Zero downtime. You're 70% of the way there.

Plug

I do this on a project called Safari MCP — a macOS-only MCP server that lets AI agents drive your real Safari (with all your existing logins) instead of spawning Chrome. It's MIT, runs on npx safari-mcp, and has 80 tools for navigation, form fill, screenshots, and everything in between.

If you're tired of Chrome DevTools MCP eating your M-series battery, give it a spin. And if you have opinions about any of the security layers above — or know one I missed — hit me on GitHub Issues.

Sources and links:

Why 60 seconds beats a perfect message: an automation latency study

אחיה כהן — Sat, 11 Apr 2026 21:54:54 +0000

A few months ago I built what looked like a textbook lead-capture workflow for a real estate company in Israel: Facebook ad → lead form → CRM → agent follow-up. Standard pipeline. The thing that surprised me about how it performed had nothing to do with the agents, the message templates, or the offer. It came down to a single variable I had not been measuring: time between trigger and first touch.

This post is about what that variable does and why I now think it's the first thing to optimize in any marketing automation, not the last.

The setup

Real estate, Hebrew market, Facebook lead ads. The original pre-automation flow looked like this:

Prospect fills out a Facebook lead form
Lead lands in the company's Facebook Lead Center
Once or twice a day, an admin exports it
Lead gets called by an available agent

End-to-end latency: 3 to 6 hours on a good day. The pattern was depressingly familiar to anyone who's looked at lead funnels — by the time the agent called, the prospect had already messaged 2-3 competing brokers, locked in a viewing with whoever responded first, and stopped picking up unknown numbers.

The instinct (mine and theirs) was to fix this with better human routing: rotate agents, set up paging, train people to check more often. I've seen this approach a hundred times. It does not work. Humans are not the right tier for sub-minute response.

What I built

The whole thing is small. Three pieces:

Facebook Lead Form
       │
       ▼
[Webhook → n8n]
       │
       ├─→ WhatsApp Business API: send acknowledgment
       │
       ├─→ Monday CRM: create item with full lead data
       │
       └─→ Notify available agent (email + push)

The n8n flow has six nodes: Webhook trigger, a Set node to normalize the lead payload, a WhatsApp Cloud API node for the acknowledgment, an HTTP Request node to Monday's API, a second HTTP Request to send the agent notification, and an If node to handle the rare malformed payload.

The acknowledgment template is intentionally boring:

Hi {{firstName}}, thanks for your inquiry about {{property}}.
One of our agents will reach out shortly to schedule a viewing.

That's it. No personalization beyond the first name and the property they asked about. No emoji. No marketing copy. No upsell.

What I expected vs. what happened

I expected the automation to mostly help on the operations side — fewer dropped leads, less manual data entry, agents stop chasing stale leads. Conversion impact, I figured, would come from the human follow-up still being good.

What actually happened: the response time dropped from hours to under one minute, and conversion improved significantly. What surprised me was how much of that improvement seemed to come from the automated acknowledgment alone. Prospects who got the WhatsApp ping within 60 seconds were warmer when the human agent eventually called back, and "warmer" mostly meant "still expecting our call instead of three competitors'."

The acknowledgment was not a bridge to the human call. It was the moment the prospect committed to talking to us instead of shopping around.

The model that explains it

Here's what I now believe is happening, and it's pretty simple:

Lead intent has a half-life of minutes, not hours. When someone fills out a form, their attention is on the problem they're trying to solve right now. Every second after submission, that attention is leaking — to a competitor, to a phone notification, to dinner. By the 15-minute mark, you're competing with an entirely different mental state.

An acknowledgment is not a placeholder. It's the conversion event. Most marketers treat the first-touch message as "we got it, real reply coming." Prospects don't read it that way. They read it as "this business is alive and responsive." That signal — "alive and responsive" — is what makes them stop shopping. The actual conversation that follows is downstream of that decision, not the cause of it.

The exact words barely matter as much as the timing. Across the workflows I've built, copy tweaks (better wording, personalization, emoji, social proof) tend to produce small incremental conversion changes. Cutting response latency from hours to minutes consistently produces much larger jumps. The latency variable seems to dwarf the copy variable in almost every test I've watched.

The lesson

If you're building a marketing automation workflow, the order of operations I'd recommend is the opposite of how most teams approach it:

First, measure your current trigger-to-first-response time. Not your trigger-to-human-call time. The time until anything reaches the prospect. If that number is over 5 minutes, you have a latency problem and no amount of better copy will fix it.
Second, get a barebones acknowledgment out the door. Plain language. No personalization beyond what you can parse from the trigger payload. The goal is sub-60-second delivery.
Third, instrument the gap between acknowledgment and human follow-up so you can see what conversion looks like with and without human touch. You will probably find, like I did, that the acknowledgment is doing more work than you thought.
Then, and only then, start optimizing copy, personalization, and follow-up sequences.

This ordering matters because most marketing automation post-mortems end up with a list of recommendations like "rewrite the email," "add more drip steps," "personalize the subject line." Those are real levers but they're second-order. The first-order lever is latency, and almost no one is measuring it.

A few practical notes

Use WhatsApp Business API or another channel with native push delivery, not email. Email-based acknowledgments hit the spam filter latency wall and you lose your sub-minute window.
Make the trigger sync, not poll. Webhooks beat scheduled exports every time.
Don't put your acknowledgment behind a manual approval step. The agent does not need to review the auto-message. Trust the template.
Log the trigger-to-acknowledgment timestamp so you can actually see when it drifts. If it ever goes above 90 seconds you have an outage even if every node is "green."
If you need a CRM, use one with a public API and a real webhook surface. Most of the time spent on these workflows is fighting CRM integrations, not building the automation logic.

If you've built something similar and seen the same effect — or if you've measured the opposite and the human touch matters more than I think — I'd love to hear about it in the comments.

This is one of about 50 automation projects I've built for Israeli SMBs. If you want to see more case studies, including the full pricing breakdown for similar workflows, there's a longer write-up on my site.

7 Things I Learned Building a Safari Browser Automation Tool That Chrome Can't Do

אחיה כהן — Wed, 01 Apr 2026 10:42:21 +0000

Every browser automation tool assumes you're using Chrome.

Playwright? Chrome. Puppeteer? Chrome. Selenium? Technically supports others, but let's be real -- Chrome. Even the new wave of AI-powered browser tools (Chrome DevTools MCP, Browserbase) are all Chromium under the hood.

I use Safari as my daily browser. I have 47 tabs open right now with active sessions -- Gmail, GitHub, Ahrefs, my hosting dashboards. When I started building AI agents that needed to interact with web pages, every tool told me the same thing: "Just use Chrome."

So I spent the last two weeks building Safari MCP -- a native Safari automation server with 80 tools, running entirely through AppleScript and JavaScript injection. No Chrome. No Puppeteer. No headless browser.

Here are 7 things I learned that surprised me.

1. WebKit on macOS Is Not What You Think It Is

When Playwright says it supports WebKit, it's running a custom build of WebKit in a separate process. It's WebKit the engine, not Safari the application.

The real Safari on macOS runs inside the operating system's rendering pipeline. It shares resources with the window server, uses the system's DNS resolver, benefits from Apple's Intelligent Tracking Prevention, and -- this is the part that matters for automation -- it has access to your actual cookies, sessions, and logins.

The practical difference: when my AI agent needs to check Google Search Console, it just... opens it. No login flow. No stored credentials. No OAuth dance. Safari already has my Google session from this morning.

This is what "native" actually means. Not "runs on macOS" -- but "runs as macOS."

2. The CPU Difference Is Real: ~60% Less Than Chrome

I wasn't expecting this to be significant. I was wrong.

Running Chrome DevTools Protocol (via Chrome DevTools MCP) on my M2 MacBook Pro, Activity Monitor showed Chrome Helper processes eating 30-45% CPU during automation tasks. The fans spun up. My laptop got hot.

Safari MCP doing the same tasks: 10-15% CPU. No fan noise. The reason isn't that Safari is "more efficient" in some abstract sense -- it's that Safari's rendering is baked into macOS's WindowServer process, which is already running. There's no separate browser process to spin up, no V8 isolate to warm, no DevTools protocol overhead.

For AI agents that run for hours -- scraping data, filling forms, monitoring dashboards -- this isn't a nice-to-have. It's the difference between a usable laptop and a space heater.

3. Apple's Private Entitlement Wall (The Thing That Almost Killed the Project)

My first approach was obvious: use Safari's Web Inspector Protocol. Safari has a remote debugging protocol -- you can see it in the Develop menu. It's how Safari's built-in DevTools work.

I spent days trying to connect to it programmatically. Here's what I found:

Safari's Web Inspector uses an XPC service (com.apple.WebKit.WebContent) that requires a private Apple entitlement to connect. This entitlement is only granted to Apple-signed binaries -- Safari itself and Xcode's instruments.

You cannot get this entitlement as a third-party developer. There's no API to request it. No workaround. Apple has deliberately locked down programmatic access to Safari's debugging protocol.

This is the wall that stops every "Safari automation" attempt. It's why Selenium's Safari driver is perpetually limited. It's why no one has built a Puppeteer-for-Safari.

I had to find another way in.

4. AppleScript + A Swift Daemon Gets You ~5ms Per Command

The "other way in" turned out to be hiding in plain sight: AppleScript's do JavaScript command.

tell application "Safari" to do JavaScript "document.title" in tab 1 of window 1

This runs arbitrary JavaScript in any Safari tab. It's been in macOS for over a decade. The catch: spawning osascript as a subprocess takes ~80ms per call. For a single command that's fine. For an AI agent issuing hundreds of commands to fill a form, it's painfully slow.

The solution: a persistent Swift daemon (safari-helper.swift -- 301 lines) that keeps an NSAppleScript instance alive in-process. The AI agent sends JSON lines over stdin, the daemon executes them and returns results.

Result: ~5ms per command instead of ~80ms. A 16x speedup from a 301-line Swift file.

The entire codebase is ~6,000 lines across 4 files. Two production dependencies (@modelcontextprotocol/sdk for the MCP protocol, ws for the optional Extension WebSocket). That's it.

5. The Tab Ownership Problem (AI Agents Will Destroy Your Work)

This one cost me a full day of lost work before I solved it.

Here's the scenario: you're writing an email in Safari tab 3. Your AI agent is automating something in tab 5. The agent needs to navigate somewhere -- and it navigates in your tab 3 instead. Your half-written email is gone. The form state is destroyed. There's no undo.

This happens because tab indices shift. You close a tab, every index after it changes. The agent cached "my tab is index 5" but now it's index 4, and your email tab is 5.

My solution: tab tracking by URL. Every command resolves the target tab by its URL, not its index. If the URL doesn't match, the command fails safely instead of hitting the wrong tab. The agent maintains a list of tabs it opened (via safari_new_tab) and refuses to touch any tab it didn't create.

Before EVERY command:
1. Resolve tab by URL, not cached index
2. Verify this is a tab the agent opened
3. If mismatch -> fail safely, never navigate in user's tab

I added this as a hard rule in my MCP configuration: the AI agent must call safari_list_tabs at the start of every session, track which tabs it opens, and verify ownership before every interaction.

It sounds paranoid. It is paranoid. And it's the only way to safely share a browser between a human and an AI agent.

6. Shadow DOM, React State, and CSP -- Why I Had to Build a Safari Extension

AppleScript's do JavaScript is powerful, but it runs in the page's JavaScript context. Three things break it:

Closed Shadow DOM. Reddit, many web components, and design systems use mode: 'closed' shadow roots. JavaScript running in the page context literally cannot see inside them -- element.shadowRoot returns null. The only way in is through a browser extension's content script, which has access to the internal shadow tree.

React's internal value tracker. If you set input.value = 'hello' on a React-controlled input, React ignores it. React tracks the "last known value" via an internal _valueTracker property on the DOM element. You have to reset this tracker before dispatching the input event, or React's synthetic event system thinks nothing changed. I learned this the hard way on LinkedIn, where every form is React-controlled.

// The hack that makes React forms work:
const tracker = input._valueTracker;
if (tracker) tracker.setValue('');
input.value = 'hello';
input.dispatchEvent(new Event('input', { bubbles: true }));

Content Security Policy. Strict CSP headers block dynamic code execution and inline scripts. Some sites (banking, enterprise tools) restrict even more aggressively. The Extension runs in the MAIN world with elevated privileges, bypassing CSP restrictions that would block AppleScript-injected JavaScript.

This led to the dual-engine architecture: the Safari Extension handles modern SPAs and CSP-strict sites (5-20ms per command via HTTP polling), while AppleScript handles everything else (~5ms via the Swift daemon). The system automatically falls back between them.

7. CGEvent Window Targeting -- Clicking Without Stealing Focus

The final boss: some sites (Airtable, complex React apps) don't respond to synthetic JavaScript clicks. They check event.isTrusted -- a read-only property that's true only for events generated by the OS, not by JavaScript.

The obvious solution -- simulate a real mouse click via macOS accessibility APIs -- has a nasty side effect: it moves your physical cursor and brings Safari to the foreground. If you're typing in VS Code while your agent works, suddenly your cursor jumps and Safari appears on top.

The fix lives in safari-helper.swift and uses a largely undocumented CGEvent feature:

// CGEventField 91 = kCGMouseEventWindowUnderMousePointer
// (not in Apple's public headers)
let kWindowField = CGEventField(rawValue: 91)!
event.setIntegerValueField(kWindowField, value: windowId)

By setting the window ID on the CGEvent, the click is delivered directly to Safari's window -- without moving the mouse cursor, without activating the window, without stealing focus. The event registers as isTrusted: true in the browser.

This field isn't in Apple's public CGEvent documentation. I found it by reading Chromium's source code (they use the same trick for their own window targeting) and then confirmed the raw field numbers work on macOS Sequoia.

The Result

Safari MCP is open source (MIT), installs via npm install -g safari-mcp or Homebrew, and works with Claude Code, Claude Desktop, Cursor, Windsurf, and any MCP-compatible client.

By the numbers:

80 tools (navigation, forms, screenshots, network mocking, cookies, accessibility, and more)
~5ms per command via the persistent Swift daemon
~6,000 lines of code across 4 files
2 production dependencies
~60% less CPU than Chrome-based alternatives
MIT license

I use it daily at Achiya Automation for everything from filling client forms to monitoring dashboards to running SEO audits -- all without Chrome ever touching my system.

What I'd Do Differently

If I started over, I'd skip the XPC/Web Inspector rabbit hole entirely and go straight to AppleScript + Extension. I lost three days on the private entitlement wall before accepting it wasn't going to work.

I'd also build tab tracking from day one. The "navigate in the wrong tab" disaster happened because I treated it as an edge case. It's not an edge case -- it's the default failure mode when an AI agent shares a browser with a human.

The Question I Keep Coming Back To

Every MCP server I've seen for browser automation is Chrome-first. Playwright MCP, Chrome DevTools MCP, Browserbase -- all Chromium.

But most Mac developers I know use Safari as their daily browser. And the AI agent use case is fundamentally different from testing: you're not running in CI, you're running on your machine, with your sessions, while you're actively working.

For those of you building AI agents that interact with browsers: what's the biggest pain point you've hit with focus stealing, session management, or CPU overhead -- and did you solve it, or just live with Chrome eating your battery?

I'm genuinely curious whether the "just use headless Chrome" consensus holds when the agent runs on your personal laptop for 8 hours a day.

DEV Community: אחיה כהן

An AI agent overwrote two of my browser tabs. The fix took three releases.

The shape of the bug

v2.10.0 — the original failure mode

v2.10.1 — the grace window (almost-fix)

v2.10.3 — the permanent guard

What I'd take away if I were writing my own MCP server

The diff that mattered

LinkedIn Quietly Migrated From ProseMirror to Quill — and Broke Every Browser Automation Tool That Touched the Composer

The crash

The DOM tells the truth

Why it was crashing

The fix: drive Quill the way it expects to be driven

What this taught me about platform automation

The takeaway

When GitHub Actions Goes Silent: The Pending-Forever Bug I Hit Shipping My MCP Server to npm

The symptom that doesn't match any docs

The thing GitHub doesn't tell you in the run UI

Two facts that surprised me

The two-part fix

Part 1: workflow_dispatch with tag input

Part 2: portable runner OS

The manual workaround that actually shipped the release

npm: the easy part

MCP Registry: the trickier part

What I'd tell past-me

FAQ

The 3 isTrusted:false Bugs That Made LinkedIn Posts Impossible From My MCP Server

TL;DR

The symptom

Boundary 1: focusout dismisses the dialog

Boundary 2: ProseMirror's isTrusted:false paste rejection

Boundary 3: CGEvent Cmd+V steals focus, triggers Boundary 1

The actual fix: editor-native API access

The cascade of falsified "success"

Generalizations

What this means if you use or build MCP servers

WhatsApp Bot for Business 2026 — $1K-$4K (50+ Real Builds)

TL;DR

Two Ways to Connect: Official API vs. WAHA

Option 1: Official WhatsApp Business API

Option 2: WAHA (Unofficial WhatsApp API)

Which Should You Choose?

How to NOT Get Banned (Critical)

The #1 Rule: Get Opt-In First

Rate Limiting

WAHA-Specific Precautions

Building Your Bot: A Practical Walkthrough

Architecture Overview

Step 1: Set Up WAHA

Step 2: Connect to n8n

Step 3: Build Your Logic

Step 4: Add AI (Optional)

Real-World Use Cases

1. Appointment Scheduling

2. Lead Qualification

3. Order Status Updates

4. FAQ + Human Handoff

What It Actually Costs

DIY with WAHA + n8n (self-hosted)

Professional Setup (someone builds it for you)

Official API Route

Common Mistakes I See

Beyond the Bot: Scaling Into Full Automation

Getting Started

I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked)

The problem I kept hitting

What Chromium costs on Apple Silicon

The headless-browser fallacy

The alternative no one was building

The three things that kept breaking

The unintentional side effects

Why this doesn't generalize

If you want to try it

I Tried to Auto-Launch My MCP Server Using My MCP Server. It Found Its Own Bug.

TLDR

The Setup: Eating My Own Dog Food

Round 1: HN and X Worked Beautifully

Round 2: Then LinkedIn Got Weird

The First Suspicion: Tab Tracking

Boundary 1: `focusout` dismisses the dialog

Boundary 2: ProseMirror's `isTrusted:false` paste rejection