Forem: אחיה כהן

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.

I replaced Chrome DevTools MCP with Safari on my Mac. Here's what happened.

אחיה כהן — Mon, 30 Mar 2026 13:49:03 +0000

Everyone in the MCP world uses Chrome. I stopped.

Not because I'm contrarian. Because my MacBook Pro was hitting 97°C running Chrome DevTools MCP during a 3-hour automation session, and the fan noise was louder than my Spotify playlist.

I'm an automation developer who builds AI-powered workflows for businesses (achiya-automation.com). My AI agents need to interact with browsers constantly — filling forms, scraping data, clicking through multi-step flows. Chrome DevTools MCP worked, but the cost was real: heat, zombie processes, and my browser getting hijacked mid-work.

So I built Safari MCP — a native macOS MCP server with 80 tools, running entirely through AppleScript and JavaScript. No Chrome. No Puppeteer. No Playwright.

Here are 7 things I learned along the way.

1. WebKit on Apple Silicon is dramatically cheaper than Chromium

This isn't a fabricated benchmark — it's something any Mac developer can verify themselves. Safari uses the native WebKit engine that Apple optimizes specifically for their hardware. Chrome brings its own Chromium engine, which runs as a separate process architecture.

The difference is measurable. Open Activity Monitor, run the same page in Safari and Chrome, and watch the CPU and energy impact columns. On Apple Silicon Macs, WebKit consistently uses roughly 60% less CPU than Chromium for equivalent workloads. Apple publishes WebKit energy efficiency comparisons on webkit.org, and independent tests from outlets like iMore and Tom's Guide have confirmed the gap on M-series chips.

For MCP automation, this compounds. An AI agent might execute hundreds of browser commands per session. Each one is cheaper when the underlying engine is native.

2. You don't need Chrome DevTools Protocol for browser automation on macOS

This was the biggest mental shift. The MCP ecosystem gravitates toward Chrome DevTools Protocol (CDP) because it's well-documented and cross-platform. But on macOS, AppleScript has been automating Safari since the 90s.

The do JavaScript command in AppleScript lets you execute arbitrary JS in any Safari tab, by index, without activating the window. That single capability covers about 80% of what CDP does for MCP tools — navigation, DOM reading, clicking, form filling, screenshots.

The key insight: AppleScript doesn't spawn a new process for each command if you keep a persistent osascript process running. I use a Swift helper daemon that keeps one process alive and pipes commands through stdin/stdout. Result: ~5ms per command, compared to ~80ms when spawning a fresh osascript each time. That's a 16x improvement from a single architectural decision — keep the process alive instead of spawning one per command. It sounds obvious in retrospect, but I only figured it out after profiling showed that 90% of the latency was process startup, not the actual JavaScript execution.

Claude/Cursor/AI Agent
        ↓ MCP Protocol (stdio)
   Safari MCP Server (Node.js)
        ↓                    ↓
   Extension (HTTP)     AppleScript + Swift daemon
   (~5-20ms/cmd)        (~5ms/cmd, always available)
        ↓                    ↓
   Content Script       do JavaScript in tab N
        ↓                    ↓
   Page DOM ←←←←←←←←←← Page DOM

3. The "no focus steal" problem nearly killed the project

Here's the scenario that made me start this project: I'm typing an email in Safari. My AI agent decides to navigate to a different page for a task I assigned it. Chrome DevTools MCP opens a new Chrome window — which steals focus from Safari. Annoying, but manageable.

But the real nightmare: what if the agent navigates in a tab I'm actively using? Forms I was filling get wiped. Unsaved text disappears. This actually happened to me.

Safari MCP solves this at the architecture level. Every tool targets tabs by index. The safari_new_tab command opens tabs in the background. There is literally no activate command anywhere in the codebase. Safari never comes to the foreground.

I added a safety protocol: the agent must call safari_list_tabs at session start, note which tabs already exist, and only interact with tabs it opened via safari_new_tab. Any tab the agent didn't open is treated as the user's tab — untouchable.

This alone was worth building the entire project.

4. React, Vue, and Angular break naive form filling

This was the hardest engineering problem. If you just set element.value = "text" on a React input, nothing happens. React uses a synthetic event system and tracks internal state via a _valueTracker on the element. You need to:

Get the native HTMLInputElement setter
Call it with Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, 'value').set.call(element, value)
Delete the _valueTracker so React doesn't skip the update
Dispatch input and change events with bubbles: true
Dispatch blur for validation

Vue and Angular have their own quirks. Closure-based editors like Medium's need execCommand insertion or synthetic clipboard paste events.

Safari MCP's safari_fill handles all of these. It auto-detects the framework and applies the correct strategy. This was easily 40% of the development effort for what seems like a trivially simple feature.

5. A Safari Extension unlocks what AppleScript can't touch

AppleScript gets you 80% of the way. But modern web apps have:

Closed Shadow DOM (Reddit, web components) — AppleScript JavaScript can't see inside
Strict Content Security Policy — blocks injected scripts on sites like GitHub
Complex editor state (Draft.js, ProseMirror, Slate) — needs deep framework-level manipulation

So I built a Safari Web Extension that injects a content script into every page. It runs in the MAIN world (not ISOLATED), giving it full access to the page's JavaScript context, Shadow DOM, and framework internals.

The extension communicates with the MCP server via HTTP polling on port 9224. The MCP server exposes a simple REST API, the extension polls it every 100ms for pending commands, executes them, and posts results back.

The dual-engine design means everything works with just AppleScript, but the extension makes it better. If the extension isn't connected, the server falls back automatically. There's no configuration needed — the server tries the extension first, and if it doesn't respond within a few milliseconds, routes through AppleScript. Users who don't want to bother with Xcode and extension setup get a fully working tool out of the box. Power users who need Shadow DOM access or CSP bypass can opt into the extension.

6. The honest limitations matter

I keep Chrome DevTools MCP installed. Here's why:

Lighthouse audits — there's no Safari equivalent. When I need Core Web Vitals scores, I use Chrome.
Performance traces — Chrome's Performance panel and trace format are irreplaceable for debugging rendering bottlenecks.
Memory snapshots — heap snapshots for finding memory leaks.
Cross-platform — Safari MCP is macOS only. Period. If you're on Linux or Windows, this doesn't exist for you.

My actual workflow: Safari MCP handles 95% of daily automation (navigation, form filling, data extraction, screenshots). Chrome DevTools MCP handles the 5% that requires Chromium-specific devtools.

7. Session persistence is the feature nobody talks about

With Playwright or Puppeteer, every session starts with a fresh browser profile. No cookies. No logins. No saved passwords. You need to handle authentication flows every single time, or manage browser profiles and cookie injection.

Safari MCP uses your actual Safari browser. Gmail is logged in. GitHub is logged in. Your company's internal tools are logged in. When your AI agent needs to check something on a site you're authenticated on — it just works.

This saves an absurd amount of time. No OAuth flows to automate. No cookie files to manage. No headless browser profiles. I've literally saved hours per week not having to deal with authentication in automation scripts.

The trade-off is obvious: your agent has access to your real sessions, so you need to trust what it's doing. But for a local development tool running on your own machine, that's the correct trade-off. You're already trusting your AI coding assistant with your filesystem and terminal — browser sessions aren't a meaningful expansion of that trust boundary.

Try it

npm install -g safari-mcp

Prerequisites:

macOS (any version)
Node.js 18+
Safari → Settings → Advanced → "Show features for web developers" ✓
Safari → Develop → "Allow JavaScript from Apple Events" ✓

Add to your MCP client config (Claude Code, Cursor, Windsurf, etc.):

{
  "mcpServers": {
    "safari": {
      "command": "npx",
      "args": ["-y", "safari-mcp"]
    }
  }
}

The GitHub repo has full docs, all 80 tools listed, and a comparison table against Chrome DevTools MCP and Playwright MCP.

If you want to see how I use it in production automation workflows — I run an automation agency (achiya-automation.com) where Safari MCP is a core part of the stack alongside n8n for workflow orchestration.

Mac developers — what's your biggest pain point with browser automation tools in your MCP/AI agent setup? I'm genuinely curious whether the problems I solved (heat, focus stealing, session persistence) are the ones that bother you most, or if there are pain points I haven't addressed yet. If you've built your own MCP server for something unconventional, I'd love to hear about that too.

Every MCP Browser Tool Uses Chromium. That's a Problem.

אחיה כהן — Sat, 28 Mar 2026 20:08:51 +0000

The Model Context Protocol has a browser monoculture problem, and nobody's talking about it.

I just searched the MCP server registry. There are at least 13 browser automation servers listed. Every single one requires Chromium -- Chrome DevTools Protocol, Puppeteer, Playwright with Chromium, or some wrapper around them. If your AI agent needs to interact with a web page, your only option has been "launch Chrome."

This matters more than you think. Not because of some abstract browser diversity argument, but because Chrome is the single biggest resource drain in most developers' MCP setups -- and it's completely unnecessary for 95% of browser automation tasks.

The Realization That Started This

I run an automation business. My daily workflow involves Claude Code connected to 6-7 MCP servers simultaneously. One day I noticed my M2 MacBook Pro fans spinning up during what should have been a simple task -- the AI agent was just reading a dashboard and filling a form.

I opened Activity Monitor. Chrome (spawned by the browser MCP server) was using 38% CPU. Just sitting there. With a debug port open. Waiting for commands.

Meanwhile, Safari -- the browser where I was already logged into everything I needed -- was using 0.3% CPU with 11 tabs open.

That's when it clicked: why am I running two browsers when the one I already have open does everything I need?

Introducing Safari MCP

Safari MCP is a native MCP server that controls Safari directly through AppleScript and JavaScript. No Chrome. No Puppeteer. No WebDriver. No headless browser process.

# Install from npm
npm install -g safari-mcp

# Or clone the repo
git clone https://github.com/achiya-automation/safari-mcp.git
cd safari-mcp
npm install

Enable Safari's JavaScript bridge (one-time setup):

Safari -> Settings -> Advanced -> Show features for web developers
Safari -> Develop -> Allow JavaScript from Apple Events

Add to your MCP client config (~/.mcp.json for Claude Code, .cursor/mcp.json for Cursor):

{
  "mcpServers": {
    "safari": {
      "command": "npx",
      "args": ["-y", "safari-mcp"]
    }
  }
}

That's it. No Chrome to install, no debug ports, no Playwright browser binaries to download.

The Dual-Engine Architecture

Most people look at this project and assume it's "just AppleScript." It's not. Safari MCP runs a dual-engine architecture where two completely different execution paths compete for the best way to handle each command:

AI Agent (Claude Code / Cursor / Windsurf)
        |
        v  MCP Protocol (stdio)
   Safari MCP Server (Node.js)
        |                    |
   Safari Extension      AppleScript + Swift daemon
   (HTTP, ~5-20ms)       (~5ms, always available)
        |                    |
   Content Script        do JavaScript in tab N
        |                    |
        +---> Page DOM <-----+

Engine 1: AppleScript + Swift Daemon (always available)

This is the foundation. A persistent Swift helper process stays running and accepts AppleScript commands via stdin, returning results via stdout. Instead of spawning a new osascript process for every command (~80ms overhead each), the daemon keeps one process alive. Result: ~5ms per command.

Engine 2: Safari Extension (optional, for advanced scenarios)

A native Safari Web Extension that communicates with the MCP server over HTTP (port 9224). This engine handles things AppleScript fundamentally cannot:

Closed Shadow DOM -- Reddit, Web Components, Shoelace UI. AppleScript's do JavaScript runs in the page context and can't pierce shadow boundaries. The extension's content script runs in an isolated world with access to element.shadowRoot.
Strict CSP sites -- Sites with script-src Content Security Policy headers block injected JavaScript. The extension executes in the MAIN world, bypassing CSP entirely.
Deep framework state -- React Fiber tree traversal, ProseMirror editor manipulation, Vue reactivity system hooks. The extension can access internal framework objects that AppleScript-injected JS often can't reach.

The server automatically uses the Extension when it's connected, falling back to AppleScript seamlessly. You don't configure anything -- it just works.

80 Tools Across 20 Categories

Safari MCP isn't a proof of concept with 5 navigation tools. It ships 80 tools that cover everything from basic navigation to network mocking to accessibility auditing:

Navigation & Reading -- safari_navigate, safari_read_page, safari_navigate_and_read (combines both in one round-trip), safari_go_back, safari_go_forward, safari_reload

Interaction -- safari_click (CSS selector, visible text, or coordinates), safari_double_click, safari_right_click, safari_hover, safari_drag, safari_click_and_wait

Forms -- safari_fill (React/Vue/Angular compatible), safari_fill_form (batch), safari_fill_and_submit, safari_select_option, safari_type_text, safari_press_key, safari_clear_field

Screenshots & PDF -- safari_screenshot (viewport or full page), safari_screenshot_element, safari_save_pdf

Network -- safari_start_network_capture, safari_network_details (headers, timing, bodies), safari_mock_route (intercept fetch/XHR), safari_throttle_network (simulate 3G/4G/offline)

Storage -- Full cookie, localStorage, sessionStorage, and IndexedDB access. Plus safari_export_storage / safari_import_storage for backing up and restoring entire browser sessions as JSON.

Accessibility -- safari_accessibility_snapshot returns the full a11y tree with roles, ARIA attributes, and focusable elements.

Data Extraction -- safari_extract_tables (structured JSON), safari_extract_meta (OG, Twitter, JSON-LD), safari_extract_links, safari_extract_images

Advanced -- safari_css_coverage (find unused CSS), safari_analyze_page (full analysis in one call), safari_emulate (device emulation), safari_run_script (batch multiple actions)

The React Form Problem Everyone Hits

If you've automated browser forms with any tool, you've probably hit this wall:

// This doesn't work in React
document.querySelector('#email').value = 'test@example.com';

React's synthetic event system doesn't see direct value assignments. The component state doesn't update. Validation doesn't run. The submit button stays disabled.

Safari MCP handles this correctly by default using native property setters:

// What safari_fill actually does under the hood
const nativeSetter = Object.getOwnPropertyDescriptor(
  window.HTMLInputElement.prototype, 'value'
).set;
nativeSetter.call(element, value);
element.dispatchEvent(new Event('input', { bubbles: true }));
element.dispatchEvent(new Event('change', { bubbles: true }));

This approach works with React, Vue, Angular, Svelte, Solid -- any framework that uses synthetic event listeners or intercepted property setters. When the Extension is active, it goes even deeper: it can reset React's internal _valueTracker to ensure the framework truly sees the new value.

You don't think about any of this. You just call safari_fill and it works.

Head-to-Head: Safari MCP vs The Alternatives

Here's an honest comparison. I use all three of these regularly and each has legitimate strengths:

Feature	Safari MCP	Chrome DevTools MCP	Playwright MCP
Engine	WebKit (native)	Chromium (CDP)	Chromium/WebKit/FF
CPU idle	~0.1%	~8-15% (observed, M2)	~3-8%
CPU active	~2-5%	~25-40% (observed, M2)	~10-25%
Memory	~30MB (Node only)	~200-400MB (Chrome+Node)	~150-300MB
Command latency	~5ms	~15-30ms	~20-50ms
Startup	<1s	3-5s	2-4s
Your logins/cookies	Yes (real Safari)	Yes (your Chrome)	No (clean profile)
Tool count	80	~30	~25
Network mocking	Yes	No	Yes
Lighthouse	No	Yes	No
Performance traces	No	Yes	No
Cross-platform	macOS only	Any OS	Any OS
Headless mode	No	Yes	Yes
Shadow DOM	Yes (with Extension)	Yes	Yes
Dependencies	None	Chrome + debug port	Playwright runtime

Where each tool wins:

Safari MCP: Daily workflow automation, anything involving your existing browser sessions, long-running agent tasks where CPU/battery matters, Mac-native development
Chrome DevTools MCP: Lighthouse audits, Performance traces, CPU profiling, memory snapshots -- the debugging tools Chrome pioneered
Playwright MCP: Cross-platform CI/CD, testing across multiple browser engines, headless server environments

The CPU/memory numbers above are what I observed on my M2 MacBook Pro running each server. Your numbers will vary, but the relative differences should hold -- Chrome simply has more overhead because it's running an entire separate browser process.

Real-World Agent Workflow: Why Sessions Matter

Here's something the comparison table doesn't capture: authenticated sessions.

When I ask Claude to "check my Google Search Console rankings," Safari MCP just... does it. Because I'm already logged into GSC in Safari. The agent navigates to the page, reads the data, done.

With Playwright MCP, I'd need to either:

Store credentials and log in every time (security concern)
Export cookies and import them (fragile, expires)
Use a persistent browser context (more complexity)

With Chrome DevTools MCP, my Chrome also has my sessions, so this works too. But now I'm running two browsers -- Safari for my work, Chrome for the AI agent. That's 400MB+ of RAM and 15% CPU for the privilege.

Safari MCP sidesteps all of this. One browser. One set of sessions. Zero extra overhead.

Setup for Every MCP Client

Claude Code (~/.mcp.json):

{
  "mcpServers": {
    "safari": {
      "command": "npx",
      "args": ["-y", "safari-mcp"]
    }
  }
}

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "safari": {
      "command": "npx",
      "args": ["-y", "safari-mcp"]
    }
  }
}

Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "safari": {
      "command": "npx",
      "args": ["-y", "safari-mcp"]
    }
  }
}

All of these work identically. The server communicates over stdio using the standard MCP protocol.

The Honest Tradeoffs

Safari MCP is not a drop-in replacement for everything:

macOS only -- If you're on Linux or Windows, this doesn't exist for you. Safari is a macOS application.
No headless mode -- Safari is always "real." You can't run it on a CI server without a display.
No Lighthouse -- Performance auditing is Chrome's crown jewel. I still use Chrome DevTools MCP for that.
No CDP -- We use AppleScript, not Chrome DevTools Protocol. This is both a limitation and the reason it's so lightweight.
Extension requires Xcode -- The optional Safari Extension needs a one-time Xcode build. AppleScript mode works without it.

My actual daily setup: Safari MCP for 95% of tasks, Chrome DevTools MCP for the 5% that specifically needs Lighthouse or Performance traces. They coexist peacefully.

What's Next

The project is MIT-licensed, open source, and actively maintained. The codebase is deliberately small -- two main files (index.js for MCP tool definitions, safari.js for the AppleScript bridge) totaling about 5,000 lines.

Some things I'm working on:

Better tab management for multi-window workflows
Improved network capture with response body access
More device emulation presets

PRs are welcome. The architecture is simple enough that most contributors can get productive within an hour of reading the source.

GitHub: github.com/achiya-automation/safari-mcp
npm: npmjs.com/package/safari-mcp

The Question I Actually Want Answered

I built Safari MCP because Chrome's overhead drove me crazy. But I'm genuinely uncertain about something:

How many MCP servers are you running simultaneously in your daily workflow, and what's the total memory footprint?

I run 6-7 and it adds up fast. I'm curious whether other people have hit the same resource ceiling, or whether I'm unusually sensitive to it because I work on a laptop all day without external power.

If you're running Chrome DevTools MCP or Playwright MCP alongside 4+ other MCP servers, I'd love to know: what does your Activity Monitor (or Task Manager) look like right now? Screenshot it. I bet at least one process in there is Chrome eating more resources than all your other MCP servers combined.

I Replaced Zapier with n8n for 12 Clients — Here's What Actually Happened

אחיה כהן — Thu, 26 Mar 2026 18:49:14 +0000

I've been migrating small business clients from Zapier to self-hosted n8n over the past year. The cost difference is dramatic — but it wasn't all sunshine. Here's the honest breakdown of what worked, what broke, and what I'd do differently.

Why I Even Considered the Switch

The trigger was simple: I kept seeing clients paying $200-500+/month for Zapier to run 8-15 basic workflows. Lead capture, CRM sync, appointment reminders, weekly reports. Nothing that actually needs a premium SaaS platform.

When I started mapping out what these workflows actually do — webhook trigger, transform data, HTTP request — I realized n8n on a $20/month VPS could handle all of it. The math was too obvious to ignore.

The Migration: 3 Patterns That Kept Repeating

After migrating multiple clients across industries (real estate, clinics, e-commerce, law firms), I noticed three patterns:

Pattern 1: The "Simple" Workflows Were Actually Simple

About 60% of workflows were straightforward: webhook trigger → transform data → HTTP request to CRM/WhatsApp. These migrated in under 30 minutes each.

// n8n webhook → WhatsApp notification (simplified)
{
  "nodes": [
    {
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "parameters": {
        "path": "new-lead",
        "httpMethod": "POST"
      }
    },
    {
      "name": "Send WhatsApp",
      "type": "n8n-nodes-base.httpRequest",
      "parameters": {
        "url": "https://waha-api.example.com/api/sendText",
        "method": "POST",
        "body": {
          "chatId": "={{$json.phone}}@c.us",
          "text": "New lead: {{$json.name}} - {{$json.email}}"
        }
      }
    }
  ]
}

Pattern 2: Zapier Multi-Step Workflows Became Single n8n Workflows

In Zapier, complex logic requires multiple Zaps chained together. In n8n, one workflow handles everything with IF/Switch nodes.

Example — lead routing:

Lead comes in from form
IF budget > ₪10K → assign to senior agent + send premium template
ELSE IF returning customer → assign to their previous agent
ELSE → round-robin assignment + standard template
ALL paths → log to Google Sheets + notify on WhatsApp

In Zapier, this needs multiple Zaps. In n8n: 1 workflow, no extra cost.

Pattern 3: Error Handling is Where n8n Destroys Zapier

Zapier's error handling is binary: retry or stop. n8n gives you:

Error triggers that catch failures and route them
Retry with backoff on specific nodes
Dead letter queues for manual review
Custom error notifications via WhatsApp/email

// n8n error workflow — notify on WhatsApp when any workflow fails
{
  "name": "Error Handler",
  "type": "n8n-nodes-base.errorTrigger",
  "position": [250, 300]
}
// → Format error message → Send WhatsApp alert to admin

Error workflows alone are a game changer — instead of discovering failures hours later, you get instant WhatsApp alerts.

The Honest Downsides

I'd be lying if I said the migration was painless. Here's what actually went wrong:

1. Initial Setup Complexity

Zapier: sign up, connect apps, done. n8n self-hosted: VPS setup, Docker, SSL, reverse proxy, backups. For non-technical users, this is a dealbreaker.

My solution: I handle all infrastructure. Client never touches a terminal. They get a URL, log in, and see their workflows.

2. Some Integrations Don't Exist

Zapier has 6,000+ integrations. n8n has ~400 built-in + community nodes. For some clients, I needed custom HTTP nodes for Israeli CRMs (Priority, Rivhit) that had native Zapier integrations.

Time cost: ~2 hours per custom integration. But once built, reusable across all clients.

3. Updates Require Management

Zapier auto-updates. Self-hosted n8n needs manual updates (or a cron job). I've set up automated updates with health checks — but it's still my responsibility, not Zapier's.

The Cost Difference

The exact savings depend on the client's Zapier plan and usage. But here's the general pattern I've seen:

Zapier costs scale linearly — every new workflow, every additional task, every premium integration adds to the bill
n8n self-hosted has a flat cost — one VPS handles multiple clients, and adding workflows costs nothing extra
The biggest hidden saving is that clients start automating more when the marginal cost is zero. On Zapier, they'd think twice before adding a new workflow

For context, Hetzner VPS hosting for n8n starts around $20/month and can handle dozens of workflows across multiple clients.

Who Should NOT Switch to n8n

Let me be clear: n8n isn't for everyone.

Stay on Zapier if:

You're non-technical and don't have someone to manage infrastructure
You use 30+ different SaaS tools (Zapier's integration catalog is unbeatable)
Uptime SLA is critical and you can't manage your own infrastructure
Your budget is under $50/month (Zapier's free tier might suffice)

Switch to n8n if:

You're spending $200+/month on Zapier/Make
You need complex logic (branching, loops, error handling)
You work with APIs not in Zapier's catalog
Data privacy matters (self-hosted = your data stays on your servers)
You have someone technical to manage it (or hire someone like me)

The Tool I Actually Recommend for Most Israeli SMBs

For my Israeli clients specifically, the sweet spot is usually:

n8n self-hosted for the automation engine ($20/month VPS)
WAHA for WhatsApp API (self-hosted, ~$0 vs Twilio's per-message pricing)
Supabase for database (free tier covers most SMBs)
Monday/HubSpot for CRM (what the team actually sees)

Total infrastructure cost: $20-40/month vs $500-2,000/month for the equivalent SaaS stack.

What's your automation stack? Still on Zapier, moved to Make, or went self-hosted? I'm genuinely curious what the cost difference looked like for your setup.

I'm Achiya, an automation consultant based in Israel specializing in WhatsApp bots and business workflow automation. If you're considering the switch, feel free to reach out. Try n8n — the platform that made all of this possible.

How I Built a Multi-Tenant WhatsApp Automation Platform Using n8n and WAHA

אחיה כהן — Mon, 23 Mar 2026 11:22:26 +0000

TL;DR: I run WhatsApp automation workflows for 50+ businesses on shared infrastructure using n8n (queue mode), WAHA (unofficial WhatsApp Web API), Supabase, and Chatwoot. This is the technical deep-dive into how the multi-tenant architecture works, the problems I solved, and what it costs.

The Problem

I'm a solo automation engineer based in Israel. My clients are mostly small-to-medium businesses that need WhatsApp automation — appointment reminders, lead qualification, order confirmations, customer support bots. Each client has different workflows, different WhatsApp numbers, and different business logic.

The naive approach is spinning up a separate n8n instance per client. That works for 3 clients. At 50+, you're managing 50 Docker stacks, 50 PostgreSQL databases, 50 sets of credentials. Updates become a nightmare. Monitoring becomes impossible.

I needed a single n8n instance that could:

Handle webhooks from 50+ WhatsApp sessions simultaneously
Route messages to the correct workflow per client
Not let one client's heavy traffic block another's
Survive session disconnects and reconnections gracefully
Cost less than $15/month per client in infrastructure

Here's how I built it.

Architecture Overview

                    ┌─────────────────┐
                    │   WhatsApp Web   │
                    │  (50+ sessions)  │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │      WAHA       │
                    │  (GOWS engine)  │
                    │  Docker + Redis │
                    └────────┬────────┘
                             │ webhooks
                    ┌────────▼────────┐
                    │     Caddy       │
                    │ (reverse proxy) │
                    └────────┬────────┘
                             │
              ┌──────────────▼──────────────┐
              │           n8n               │
              │  ┌─────────┐  ┌──────────┐  │
              │  │  Main   │  │  Worker   │  │
              │  │ Process │  │ (concur.  │  │
              │  │ (UI +   │  │   = 10)   │  │
              │  │ webhook)│  │           │  │
              │  └────┬────┘  └─────┬─────┘  │
              │       │             │         │
              │  ┌────▼─────────────▼────┐   │
              │  │        Redis          │   │
              │  │   (job queue + pub)   │   │
              │  └───────────────────────┘   │
              └──────────────┬───────────────┘
                             │
              ┌──────────────▼──────────────┐
              │        PostgreSQL 16        │
              │   (n8n workflows + data)    │
              └─────────────────────────────┘
                             │
              ┌──────────────▼──────────────┐
              │         Supabase            │
              │  (client data, CRM, logs)   │
              └─────────────────────────────┘
                             │
              ┌──────────────▼──────────────┐
              │         Chatwoot            │
              │  (customer support inbox)   │
              └─────────────────────────────┘

Five containers run the core n8n stack:

n8n (main process) — handles the UI and receives webhooks
n8n-worker — executes workflows, concurrency set to 10
n8n-postgres — PostgreSQL 16 for workflow storage
n8n-redis — Redis 7 for the job queue
caddy — reverse proxy with automatic HTTPS

WAHA runs separately with its own Redis instance, managing all WhatsApp Web sessions.

n8n Queue Mode: Why It Matters

By default, n8n runs in "regular" mode — the same process that serves the UI also executes workflows. If a webhook comes in while a heavy workflow is running, the webhook handler blocks.

Queue mode splits this into two processes:

# docker-compose.yml (simplified)
services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=n8n-redis
      - QUEUE_BULL_REDIS_PORT=6379
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=n8n-postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - EXECUTIONS_DATA_MAX_AGE=168
      - EXECUTIONS_DATA_SAVE_ON_SUCCESS=all
      - EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000
    networks:
      - n8n-net

  n8n-worker:
    image: n8nio/n8n:latest
    command: worker
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=n8n-redis
      - QUEUE_BULL_REDIS_PORT=6379
      - QUEUE_HEALTH_CHECK_ACTIVE=true
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=n8n-postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    networks:
      - n8n-net

  n8n-postgres:
    image: postgres:16-alpine
    environment:
      - POSTGRES_DB=n8n
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n-db-data:/var/lib/postgresql/data
    networks:
      - n8n-net

  n8n-redis:
    image: redis:7-alpine
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
    networks:
      - n8n-net

  caddy:
    image: caddy:2-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
    networks:
      - n8n-net

networks:
  n8n-net:

The main process receives all webhooks and pushes jobs to the Redis queue. The worker picks them up with a concurrency of 10, meaning up to 10 workflows execute simultaneously. If more come in, they queue — no dropped messages.

Execution Retention

I keep 7 days of full execution history (EXECUTIONS_DATA_MAX_AGE=168 hours) with a hard cap at 50,000 executions. This is critical for debugging client issues. When a client says "the bot didn't respond yesterday at 3 PM," I can pull up the exact execution, see the input payload, and trace where it failed.

WAHA: The WhatsApp Gateway

WAHA (WhatsApp HTTP API) is an unofficial, open-source WhatsApp Web API. It wraps the WhatsApp Web protocol in a REST API with webhook support. I use the GOWS engine (Go-based, not the Node.js WEBJS engine) because it's significantly more stable for long-running sessions.

Multi-Session Setup

WAHA supports multiple WhatsApp sessions in a single container. Each client gets their own session, identified by a session name:

# Start a new session for a client
curl -X POST http://localhost:3000/api/sessions/start \
  -H 'Content-Type: application/json' \
  -H 'X-API-KEY: ${WAHA_API_KEY}' \
  -d '{
    "name": "client_acme_corp",
    "config": {
      "webhooks": [{
        "url": "https://n8n.example.com/webhook/waha-gateway",
        "events": [
          "message",
          "message.ack",
          "session.status"
        ]
      }]
    }
  }'

Key detail: all sessions send webhooks to the same n8n endpoint. The routing happens inside n8n, not at the WAHA level. This is deliberate — it means I can add a new client without touching the webhook infrastructure.

Session Persistence

WAHA stores session data on disk. The Docker volume mapping is critical:

# WAHA docker-compose.yaml
services:
  waha:
    image: devlikeapro/waha:latest
    environment:
      - WHATSAPP_DEFAULT_ENGINE=GOWS
      - WAHA_DASHBOARD_ENABLED=true
      - WHATSAPP_RESTART_ALL_SESSIONS=true
    volumes:
      - /opt/waha/sessions:/app/.sessions
      - /opt/waha/media:/app/.media
    ports:
      - "3000:3000"

WHATSAPP_RESTART_ALL_SESSIONS=true means that when the container restarts (deploy, crash, server reboot), all sessions automatically reconnect. Without this, you'd need to manually re-scan QR codes for 50+ phones.

The /opt/waha/sessions directory contains the session auth data. Back this up. If you lose it, every client needs to re-scan their QR code.

Webhook Routing: The Heart of Multi-Tenancy

Every incoming WhatsApp message hits the same webhook endpoint. The n8n workflow needs to figure out which client it belongs to and route it to the correct handler.

The Gateway Workflow

// n8n Function node: "Route by Session"
const sessionName = $input.first().json.session;
const event = $input.first().json.event;
const payload = $input.first().json.payload;

// Extract client identifier from session name
// Convention: "client_{slug}" -> slug is the routing key
const clientSlug = sessionName.replace('client_', '');

// Look up client config from Supabase
const clientConfig = await $getWorkflowStaticData('global');

if (!clientConfig[clientSlug]) {
  // First time seeing this client in this execution context
  // Fetch from Supabase
  const { data } = await this.helpers.httpRequest({
    method: 'GET',
    url: `${process.env.SUPABASE_URL}/rest/v1/clients`,
    qs: { slug: `eq.${clientSlug}`, select: '*' },
    headers: {
      'apikey': process.env.SUPABASE_SERVICE_KEY,
      'Authorization': `Bearer ${process.env.SUPABASE_SERVICE_KEY}`
    }
  });

  if (data && data.length > 0) {
    clientConfig[clientSlug] = data[0];
  }
}

const client = clientConfig[clientSlug];

if (!client) {
  console.log(`Unknown session: ${sessionName}`);
  return []; // Drop unknown sessions silently
}

return [{
  json: {
    client_id: client.id,
    client_slug: clientSlug,
    workflow_id: client.active_workflow_id,
    phone: payload.from,
    message: payload.body,
    timestamp: payload.timestamp,
    session: sessionName,
    raw: payload
  }
}];

The routing key is the session name. When I onboard a new client, I:

Create a row in the Supabase clients table with their config
Start a WAHA session named client_{slug}
Build their specific workflow in n8n
Set active_workflow_id in their client config

The gateway workflow then calls the client's specific workflow using n8n's "Execute Workflow" node, passing the parsed message data.

Why Not Separate Webhook Endpoints?

I tried this first. Each client got their own webhook URL: /webhook/client-acme, /webhook/client-globex, etc. Problems:

WAHA webhook config per session is fragile. If you change the webhook URL, you need to restart the session.
50+ webhook endpoints in n8n are hard to manage. Each one is a separate workflow trigger, and you can't easily see which are active.
Monitoring is harder. With a single gateway, I can log every incoming message in one place.

The single-gateway pattern means all messages flow through one chokepoint, which sounds scary but is actually easier to monitor, rate-limit, and debug.

Rate Limiting and Queue Management

WhatsApp is aggressive about rate limiting and banning numbers that send too many messages too fast. The exact limits aren't documented (it's an unofficial API), but from experience:

New numbers: ~200 messages/day before risk increases
Warmed-up numbers: ~1,000 messages/day is generally safe
Burst limit: No more than 30 messages per minute per number

I implement rate limiting in n8n using a combination of Redis and workflow logic:

// n8n Function node: "Rate Limiter"
const redis = require('ioredis');
const client = new redis(process.env.QUEUE_BULL_REDIS_HOST);

const sessionName = $input.first().json.session;
const minuteKey = `ratelimit:${sessionName}:${Math.floor(Date.now() / 60000)}`;
const dayKey = `ratelimit:${sessionName}:${new Date().toISOString().split('T')[0]}`;

// Check minute limit
const minuteCount = await client.incr(minuteKey);
if (minuteCount === 1) await client.expire(minuteKey, 120);

// Check daily limit
const dayCount = await client.incr(dayKey);
if (dayCount === 1) await client.expire(dayKey, 86400);

const maxPerMinute = $input.first().json.client_config?.max_per_minute || 25;
const maxPerDay = $input.first().json.client_config?.max_per_day || 800;

if (minuteCount > maxPerMinute) {
  // Queue for delayed sending
  return [{
    json: {
      ...$input.first().json,
      delayed: true,
      delay_seconds: 60 - (Date.now() / 1000 % 60)
    }
  }];
}

if (dayCount > maxPerDay) {
  // Log and alert, don't send
  return [{
    json: {
      ...$input.first().json,
      blocked: true,
      reason: 'daily_limit_exceeded'
    }
  }];
}

return $input.all();

The per-client limits are stored in Supabase and cached in the workflow's static data. New clients start with conservative limits; I increase them gradually as their number warms up.

Queue Priority

n8n's queue mode uses Bull (Redis-based job queue). All webhook-triggered workflows get the same priority by default. I haven't needed to implement priority queues because the worker concurrency of 10 handles the load — but if I needed to, Bull supports job priority natively.

The more important optimization is keeping workflows fast. A workflow that takes 500ms instead of 5s means the queue drains 10x faster. I aggressively use n8n's "Execute Workflow" node to break complex logic into small, focused sub-workflows.

Template Message Management

Most clients don't write their own message templates. They describe what they want ("send a reminder 24 hours before the appointment with the client's name and time"), and I build it.

Templates are stored in Supabase:

CREATE TABLE message_templates (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  client_id UUID REFERENCES clients(id),
  slug TEXT NOT NULL,
  body TEXT NOT NULL,
  variables JSONB DEFAULT '[]',
  language TEXT DEFAULT 'he',
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now(),
  UNIQUE(client_id, slug)
);

-- Example insert
INSERT INTO message_templates (client_id, slug, body, variables)
VALUES (
  'abc-123',
  'appointment_reminder',
  'שלום {{name}}, תזכורת לתור שלך ב-{{date}} בשעה {{time}}. לאישור השב 1, לביטול השב 2.',
  '["name", "date", "time"]'
);

The n8n workflow fetches the template, interpolates variables, and sends via WAHA:

// n8n Function node: "Render Template"
const template = $input.first().json.template;
let body = template.body;

const variables = $input.first().json.variables || {};
for (const [key, value] of Object.entries(variables)) {
  body = body.replace(new RegExp(`\\{\\{${key}\\}\\}`, 'g'), value);
}

return [{
  json: {
    session: $input.first().json.session,
    to: $input.first().json.phone,
    body: body
  }
}];

Then an HTTP Request node sends it:

POST ${WAHA_URL}/api/sendText
Headers:
  X-API-KEY: ${WAHA_API_KEY}
Body:
{
  "session": "{{$json.session}}",
  "chatId": "{{$json.to}}@c.us",
  "text": "{{$json.body}}"
}

Monitoring and Health Checks

With 50+ bots running, things break silently. A WhatsApp session disconnects. A workflow errors out. Redis fills up. You need to know before the client calls you.

n8n Health Monitoring

I run a monitoring script via cron every 5 minutes:

#!/bin/bash
# /opt/n8n-docker-caddy/scripts/monitor-n8n.sh

N8N_URL="http://localhost:5678"
WEBHOOK_URL="http://localhost:5678/webhook/monitoring-alert"

# Check n8n main process
if ! curl -sf "${N8N_URL}/healthz" > /dev/null 2>&1; then
  curl -s -X POST "${WEBHOOK_URL}" \
    -H 'Content-Type: application/json' \
    -d '{"alert": "n8n_main_down", "severity": "critical"}'
fi

# Check worker
WORKER_STATUS=$(docker inspect --format='{{.State.Health.Status}}' n8n-worker 2>/dev/null)
if [ "$WORKER_STATUS" != "healthy" ]; then
  curl -s -X POST "${WEBHOOK_URL}" \
    -H 'Content-Type: application/json' \
    -d '{"alert": "n8n_worker_unhealthy", "status": "'$WORKER_STATUS'"}'
fi

# Check Redis memory
REDIS_MEMORY=$(docker exec n8n-redis redis-cli info memory | grep used_memory_human | cut -d: -f2 | tr -d '[:space:]')
# Alert if over 200MB
REDIS_MB=$(echo $REDIS_MEMORY | sed 's/M//')
if (( $(echo "$REDIS_MB > 200" | bc -l) )); then
  curl -s -X POST "${WEBHOOK_URL}" \
    -H 'Content-Type: application/json' \
    -d '{"alert": "redis_memory_high", "usage": "'$REDIS_MEMORY'"}'
fi

# Check PostgreSQL
if ! docker exec n8n-postgres pg_isready -U n8n > /dev/null 2>&1; then
  curl -s -X POST "${WEBHOOK_URL}" \
    -H 'Content-Type: application/json' \
    -d '{"alert": "postgres_down", "severity": "critical"}'
fi

The monitoring webhook triggers an n8n workflow that sends me a WhatsApp alert. Yes, I use my own platform to monitor my own platform. If the whole stack is down, the alert won't fire — but Hetzner's monitoring catches full server outages.

WAHA Session Monitoring

// n8n Cron workflow: runs every 10 minutes
// HTTP Request to WAHA API
// GET ${WAHA_URL}/api/sessions

const sessions = $input.first().json;
const disconnected = sessions.filter(s =>
  s.status !== 'WORKING' && s.name.startsWith('client_')
);

if (disconnected.length > 0) {
  // Try to restart disconnected sessions
  for (const session of disconnected) {
    await this.helpers.httpRequest({
      method: 'POST',
      url: `${process.env.WAHA_URL}/api/sessions/${session.name}/restart`,
      headers: { 'X-API-KEY': process.env.WAHA_API_KEY }
    });
  }

  // Alert me
  return [{
    json: {
      alert: 'sessions_disconnected',
      sessions: disconnected.map(s => s.name),
      action: 'auto_restart_attempted'
    }
  }];
}

return []; // All good, no output

Database Backup Strategy

I learned this the hard way. n8n originally used SQLite, and I experienced data corruption that lost workflow execution history. I migrated to PostgreSQL 16 and implemented automated daily backups:

#!/bin/bash
# /opt/n8n-docker-caddy/scripts/pg-backup.sh
# Runs daily at 3:00 AM via cron

BACKUP_DIR="/opt/n8n-backups"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/n8n_${TIMESTAMP}.dump"

# Create backup using custom format (supports parallel restore)
docker exec n8n-postgres pg_dump \
  -U n8n \
  -d n8n \
  -Fc \
  -f /tmp/backup.dump

# Copy from container
docker cp n8n-postgres:/tmp/backup.dump "${BACKUP_FILE}"

# Clean up old backups (keep 7 days)
find "${BACKUP_DIR}" -name "*.dump" -mtime +7 -delete

# Verify backup is not empty
if [ ! -s "${BACKUP_FILE}" ]; then
  echo "BACKUP FAILED: Empty file" >&2
  exit 1
fi

echo "Backup completed: ${BACKUP_FILE} ($(du -h ${BACKUP_FILE} | cut -f1))"

Restore when needed:

docker exec -i n8n-postgres pg_restore \
  -U n8n -d n8n \
  --clean --if-exists \
  < /opt/n8n-backups/n8n_20260320_030000.dump

Scaling Lessons Learned

1. Worker Concurrency Is Not "More Is Better"

I started with QUEUE_BULL_DEFAULT_JOB_OPTIONS_ATTEMPTS=3 and concurrency at 20. Workflows started failing with database connection pool exhaustion. PostgreSQL's default max_connections = 100, and each concurrent workflow execution holds a connection.

Concurrency of 10 with the default connection pool is the sweet spot. If you need more throughput, add another worker container — don't increase concurrency on a single worker.

2. Static Data Is Your Friend (and Enemy)

n8n's $getWorkflowStaticData('global') persists data across executions in memory. I use it for caching client configs so I don't hit Supabase on every message. But it's per-process — the main process and the worker have different static data. And it's lost on restart.

Pattern: use static data as a cache, always fall back to the database.

3. WAHA Session Limits

A single WAHA container comfortably handles 20-30 active sessions on a 4GB RAM server. Beyond that, I've seen memory pressure cause session disconnects. For 50+ sessions, either allocate more RAM or run multiple WAHA containers with session affinity.

4. PostgreSQL Tuning

Enable pg_stat_statements for query performance tracking. n8n generates some heavy queries for execution history. The default shared_buffers and work_mem settings are fine for up to ~30,000 stored executions, but with the 50,000 cap I use, bumping shared_buffers to 256MB made a noticeable difference.

5. Webhook Timeouts

WAHA has a default webhook timeout. If your n8n webhook takes too long to respond (because the queue is full or the workflow is complex), WAHA will retry. This causes duplicate message processing.

Solution: make the gateway workflow as fast as possible. It should only parse, route, and enqueue — never do the actual work inline. The heavy lifting happens asynchronously via "Execute Workflow."

Cost Breakdown

Here's what it costs to run 50+ WhatsApp bots on shared infrastructure, hosted on Hetzner Cloud (Germany/Finland data centers):

Component	Server Spec	Monthly Cost
n8n (queue mode)	CPX31 (4 vCPU, 8GB RAM)	~$15
WAHA	CPX21 (3 vCPU, 4GB RAM)	~$10
Supabase (self-hosted)	CPX21 (3 vCPU, 4GB RAM)	~$10
Chatwoot	CPX21 (3 vCPU, 4GB RAM)	~$10
Website + misc	CX22 (2 vCPU, 4GB RAM)	~$6
Hetzner daily backups	All servers	~$5
Domain + DNS	Cloudflare	Free
Total		~$56/month

That's roughly $1.10 per bot per month in infrastructure costs.

For comparison, a managed WhatsApp Business API provider charges $50-200/month per number. Official BSP (Business Solution Provider) plans start at $100/month per number for basic messaging.

The tradeoff: I'm using an unofficial API (WAHA wraps WhatsApp Web, not the official Business API). This means:

No green checkmark verification
Risk of number bans if you abuse limits
No official SLA
But: no per-message fees, no approval process, and full control

For my clients — small businesses doing appointment reminders and customer support — this tradeoff makes sense. For enterprise-scale marketing campaigns, use the official API.

What I'd Do Differently

Start with PostgreSQL, not SQLite. The migration was painful and I lost some data. n8n's SQLite mode is fine for personal use, not production.
Build the monitoring first. I added monitoring after the third time a session silently disconnected and I found out from an angry client.
Standardize session naming earlier. I started with freeform names ("johns-dental", "pizzaplace") and later switched to client_{slug}. Migrating was annoying.
Use Supabase Edge Functions for the rate limiter instead of doing it in n8n. The Redis-in-n8n approach works but is harder to test and maintain.

Stack Summary

Tool	Role	Why This One
n8n	Workflow automation engine	Visual builder, self-hosted, queue mode, active community
WAHA	WhatsApp Web API	Multi-session, REST API, Go engine for stability
Supabase	Database + API	PostgreSQL with instant REST API, row-level security
Chatwoot	Customer support	Open-source, WhatsApp inbox, agent assignment
Caddy	Reverse proxy	Automatic HTTPS, simple config
Hetzner Cloud	Hosting	European data centers, great price/performance

If you're building something similar or have questions about the architecture, find me at achiya-automation.com/en.

Achiya Cohen is an automation engineer specializing in WhatsApp automation and business process workflows. He runs Achiya Automation from Israel, serving businesses with n8n-based automation solutions.

Over to You

I want to hear from people running multi-tenant setups:

At what client count did your "one instance per client" approach become unmanageable? For me, it was around client #15 — Docker Compose files everywhere, each one slightly different, zero standardization.

And here's the thing I still haven't solved cleanly: database migrations across 50+ tenant schemas. I've tried Flyway, custom n8n workflows, even bash scripts. None feel right. What's working for you?

Drop your stack below — especially if you've found an elegant solution I missed. 👇

I Built an MCP Server for Safari Because Chrome Was Melting My MacBook

אחיה כהן — Mon, 23 Mar 2026 10:37:34 +0000

Last month I noticed something: every time I used Chrome DevTools MCP or Playwright MCP with Claude, my MacBook Pro fans would spin up. Activity Monitor showed Chrome eating 40-60% CPU just sitting there with a debug port open.

I use Safari as my daily browser. All my logins are there — Gmail, GitHub, Ahrefs, AWS console. Why am I launching a second browser just so an AI agent can click buttons?

So I built Safari MCP — a native MCP server that controls Safari directly via AppleScript. No Chrome. No Puppeteer. No headless anything.

The Architecture (It's Embarrassingly Simple)

AI Agent (Claude, Cursor, etc.)
    ↓ MCP Protocol (stdio)
Safari MCP Server (Node.js)
    ↓ Persistent osascript process
AppleScript → Safari
    ↓ do JavaScript in tab N
Your real browser DOM

The entire server is essentially two files:

index.js — MCP tool definitions
safari.js — AppleScript + JavaScript bridge

The key trick: instead of spawning a new osascript process for every command (~80ms each), I keep a single persistent process running. Commands go in via stdin, results come back via stdout. Result: ~5ms per command instead of 80ms.

80 Tools — Here's What You Actually Get

Not just navigate and click. Safari MCP has 80 tools across 20 categories:

The basics: navigate, click, fill forms, screenshots, scroll, tabs

The good stuff:

safari_fill — works with React/Vue/Angular (uses native property setters, not just DOM value)
safari_upload_file — uploads via JS DataTransfer, no file dialog popup
safari_mock_route — intercept and mock fetch/XHR responses
safari_accessibility_snapshot — full a11y tree with ARIA roles
safari_extract_tables — tables as structured JSON
safari_emulate — device emulation (iPhone, iPad, Pixel, etc.)
safari_run_script — batch multiple actions in a single call

The sneaky stuff:

safari_start_network_capture + safari_network_details — capture all fetch/XHR with headers and timing
safari_export_storage / safari_import_storage — backup and restore entire browser sessions
safari_css_coverage — find unused CSS rules
safari_analyze_page — full page analysis in one call

The React Form Problem (And How I Solved It)

If you've ever tried to automate React forms, you know this doesn't work:

element.value = "hello";

React doesn't see it. The state doesn't update. The submit button stays disabled.

Safari MCP uses the native input setter approach:

const nativeSetter = Object.getOwnPropertyDescriptor(
  window.HTMLInputElement.prototype, 'value'
).set;
nativeSetter.call(element, value);
element.dispatchEvent(new Event('input', { bubbles: true }));
element.dispatchEvent(new Event('change', { bubbles: true }));

This works with React, Vue, Angular, Svelte — anything that uses synthetic event listeners.

Real Numbers: Safari MCP vs Chrome DevTools MCP

I measured this on an M2 MacBook Pro running both servers simultaneously:

Metric	Safari MCP	Chrome DevTools MCP
CPU (idle)	~0.1%	~8-15%
CPU (active)	~2-5%	~25-40%
Memory	~30MB (Node process only)	~200-400MB (Chrome + Node)
Command latency	~5ms	~15-30ms
Startup time	<1s	3-5s (Chrome launch)
Dependencies	0	Chrome browser

The CPU difference is dramatic on laptops. Safari MCP basically doesn't show up in Activity Monitor.

The Tradeoffs (I'm Being Honest)

Safari MCP is not a replacement for everything:

What Safari MCP can't do:

No Lighthouse audits (Chrome-only)
No Performance traces / CPU profiling
No cross-platform (macOS only, obviously)
No headless mode (Safari is always "real")
No CDP (Chrome DevTools Protocol) — we use AppleScript

My actual workflow:

Safari MCP for 95% of browser tasks (navigation, scraping, form filling, testing)
Chrome DevTools MCP for the 5% that needs Lighthouse or Performance traces

Quick Start

git clone https://github.com/achiya-automation/safari-mcp.git
cd safari-mcp
npm install

Enable in Safari:

Safari → Settings → Advanced → Show features for web developers ✓
Safari → Develop → Allow JavaScript from Apple Events ✓

Add to your MCP config (Claude Code, Cursor, etc.):

{
  "mcpServers": {
    "safari": {
      "command": "node",
      "args": ["/path/to/safari-mcp/index.js"]
    }
  }
}

That's it. No Chrome to install, no debug ports to configure, no Playwright browsers to download.

Why I Open-Sourced It

I built this for myself — I run an automation business and needed reliable browser control without the Chrome tax. But I figured if my MacBook was overheating, other Mac developers must be having the same problem.

If you're on a Mac and tired of Chrome eating your battery for AI browser automation, give it a try:

github.com/achiya-automation/safari-mcp

Star it if it saves your fans from spinning up. ⭐

Built with AppleScript, JavaScript, and frustration with Chrome's CPU usage.

Over to You

Here's a quick experiment: open Activity Monitor right now and check what Chrome is using. I bet it's at least 30% CPU even with 3-4 tabs.

I'm genuinely curious:

What browser automation tool are you using — and what's your CPU usage during runs?
Has anyone tried MCP with Firefox or another non-Chromium browser? I picked Safari because macOS, but the architecture works for anything with a JavaScript bridge.

The repo has 4 open issues I haven't cracked yet — if any of them are your pain point, I'd love a PR or even just a "+1" so I know what to prioritize. 👇

How to Build a WhatsApp Appointment Bot with n8n and Supabase (Step-by-Step)

אחיה כהן — Sun, 22 Mar 2026 12:33:31 +0000

Every small business owner I've worked with has the same pain point: appointment scheduling eats their day alive.

They're stuck in an endless loop of WhatsApp messages. Multiply this by 20-30 conversations per day, and you've lost 3-4 hours before you've done any actual work.

Here's how to build a WhatsApp bot that handles this automatically — using open-source tools, self-hosted, for under $30/month.

Architecture Overview

Components:

WAHA — Self-hosted unofficial WhatsApp API (connects to WhatsApp Web)
n8n — Open-source workflow automation (handles all the logic)
Supabase — PostgreSQL database (stores appointments, availability, customer data)

Step 1: Set Up Your Database Schema

In Supabase, create three tables: availability (business hours/slots), appointments (booked slots), and conversation_state (tracks where each customer is in the booking flow).

Why conversation state? WhatsApp conversations are asynchronous. A customer might send "Tuesday" at 10am, then reply with a time at 2pm.

Step 2: Build the n8n Webhook Flow

Create a workflow with a Webhook node as the trigger. WAHA sends incoming messages here. The core logic uses a Switch node to route by conversation state:

State	What We Expect	Next Action
`initial`	Any message	Show welcome + available days
`waiting_for_date`	A date	Show available times
`waiting_for_time`	A time	Confirm booking
`waiting_for_confirm`	"yes"/"no"	Book or restart

Step 3: Add Reminder Workflow

Create a second n8n workflow with a Cron trigger that runs every hour, finds tomorrow's appointments, and sends WhatsApp reminders via WAHA.

Step 4: Handle Edge Cases

The difference between a frustrating bot and a helpful one:

Cancellation flow — detect "cancel" keyword, free the slot
Rescheduling — cancel existing, restart booking
Unrecognized input — show menu of options

Cost Breakdown

Component	Monthly Cost
WAHA (self-hosted)	$5 (VPS)
n8n (self-hosted)	$0 (same VPS)
Supabase (free tier)	$0
VPS (2GB RAM)	~$10-15
Total	~$15-20/month

Why Automated Reminders Matter

No-shows are the silent killer for appointment-based businesses. Research consistently shows that automated reminders — especially via the channel customers already use (WhatsApp) — significantly reduce no-show rates. Studies in healthcare found 40-60% reductions in missed appointments when using SMS/messaging reminders.

The advantage of WhatsApp specifically is the read receipt — you know the reminder was seen, unlike email which might be ignored.

The full code and n8n workflow templates are on my GitHub.

I'm Achiya Cohen, founder of Achiya Automation. I build WhatsApp bots and workflow automation for small businesses using open-source tools like n8n.

Over to You

Two questions for anyone running appointment systems:

What's your no-show rate, and what's your reminder strategy? I've been using 24h + 2h before the appointment, but some businesses swear by 48h + 4h. What works for your industry?
Do you allow rescheduling via bot, or only cancellation? Rescheduling adds complexity but might reduce no-shows even further since the customer has an easy alternative to just not showing up.

If you're building something similar and got stuck on a specific step — drop it below and I'll help debug. 👇

Forem: אחיה כהן

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

Detective Work: There Are Three Windows

The Real Bug: Resolve Cache + URL Prefix

The Fix: window.__mcpTabMarker

The Bypass Tool I Built While Debugging

How LinkedIn Was Actually Posted

What Reddit Taught Me

Lessons

Status

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

The 4-Layer Detection System

Layer 1: Registration Fingerprinting

Layer 2: Behavioral Analysis (Where Bots Get Caught)

Layer 3: User Reports

Layer 4: Content Pattern Matching

The Big 2026 Change: Unanswered Message Counter

Official vs Unofficial API: Risk Comparison

7 Rules We Follow for Every Bot

What If You're Already Restricted?

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

TL;DR

What I actually built

The benchmark setup

Latency — MCP wins by 25×

Workflow — MCP still wins on reactive sequences

Tokens — CLI wins by 84×

Accuracy — tie

The bugs that took 5 review rounds to find

When to use which

What I'd do differently next time

Links

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

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

The starting point

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

Layer 2: manual-approval environment gate

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

Layer 4: SHA pinning required for all actions

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

Layer 6: SSH commit signing without losing your mind

Layer 7: Approval for outside-collaborator workflows

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

What the attack surface looks like now

The 30-minute version

Plug

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

The setup

What I built

What I expected vs. what happened

The model that explains it

The lesson

A few practical notes

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

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

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

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

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

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

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

7. CGEvent Window Targeting -- Clicking Without Stealing Focus

The Result

What I'd Do Differently

The Question I Keep Coming Back To

I replaced Chrome DevTools MCP with Safari on my Mac. Here's what happened.

1. WebKit on Apple Silicon is dramatically cheaper than Chromium

2. You don't need Chrome DevTools Protocol for browser automation on macOS

3. The "no focus steal" problem nearly killed the project

4. React, Vue, and Angular break naive form filling

5. A Safari Extension unlocks what AppleScript can't touch

6. The honest limitations matter

7. Session persistence is the feature nobody talks about

Try it

Every MCP Browser Tool Uses Chromium. That's a Problem.

The Realization That Started This