DEV Community: אחיה כהן

I Stopped Merging Pull Requests to My Browser Tool. Contributors Still Ship.

אחיה כהן — Wed, 28 Oct 2026 04:38:01 +0000

I maintain safari-mcp, an MCP server that lets AI agents drive Safari on macOS. Not a fresh browser in a sandbox. The user's own Safari, with their Gmail session, their bank tab, their cookies. That is the whole point of the tool, and it is also why I no longer merge anyone's pull request.

People still contribute, and their ideas still ship. Today's release, v2.23.0, has four of them. But none of the contributor's commits are on main. The ideas are there, rewritten line by line in my own commit, with the contributor credited in the changelog.

Here is why I ended up there, and what it costs.

The pull request that said one thing and did another

On August 27 an account I had never seen opened a PR titled "add x86_64 safari-helper binary variant". The description said it added an x86 build next to the existing arm64 binary and updated the CI workflow to build both.

The file list said something else:

modified  safari-helper      +0 -0
added     safari-helper-x86  +0 -0

No workflow change. And the first line is the one that matters: it modified safari-helper, the signed native binary that ships in the npm package and posts clicks and keystrokes into Safari. A binary shows up in a diff as +0 -0. There is nothing to read. If I had merged it because the description sounded reasonable and CI was green, every user's next npm install would have run a binary I had never seen, with the Accessibility permission they granted to mine.

I closed it the next day. I never found out what the binary did, and I don't want to. Finding out would have meant running it.

The review that ran a stranger's code on my Mac

The second lesson was my own fault, and the code involved was clean.

On September 28 I reviewed an outside PR the usual way: check out the branch, run the test suite, see if it passes. It passed. Then it occurred to me what "run the test suite" means on this machine. The tests are JavaScript that runs as my user. It can read ~/Library, the Safari profile, and every token in my environment. npm test on a contributor's branch is just "run this stranger's program", with a green check at the end.

Nothing bad happened. But "nothing bad happened" is not a review process.

The rules now

I wrote them down so I'd follow them on autopilot, including when I'm in a hurry:

Outside code never runs on my machine. I review by reading: gh pr diff <n> and the PR's file list from the API. No gh pr checkout, no fetching pull/<n>/head, no cloning the fork to "just try it".
Their code runs only in GitHub CI. A fork PR gets a read-only token, and the repo has no Actions secrets for it to reach. I check that this stays true on every run: collaborators, deploy keys, webhooks, secrets, pull_request_target, and who published the latest npm version.
The file list is read before the description. A binary, a lockfile with a new resolved host, a new postinstall script, a change under .github/, or encoded strings ends the review. A description that doesn't match the diff ends it too.
Taking an idea means rewriting it. I read every line, then write the change myself in my own commit, and my tests run on my commit. I never take binaries, lockfiles, workflows, package.json scripts or generated code from a PR, even if they look identical to what I'd produce.

Rule 4 is the one people find odd, so here is what it looked like this week.

Seven PRs in 45 seconds

On October 20 one contributor opened seven PRs within 45 seconds. That pattern is exactly how a payload would hide: PR #N+1 "builds on" PR #N and carries a copy of its commits. You review the first one carefully, skim the rest, and the change you missed lives only in the copy.

So every PR got its own full diff read. The account was eleven years old. No URLs beyond test fixtures, no child_process, no encoded strings, nothing touching the install path. Everything was clean. The ideas were good, too: a diff mode for snapshots, a way to load only the core tools, compacting table layouts. But the stacked PRs couldn't land as they were, so I asked for standalone versions on top of main.

The contributor sent standalone versions the same day I asked. I read the seven new diffs, wrote four of them again from scratch, and shipped them today:

safari_snapshot({ diff: true }) returns only the lines that changed since that tab's previous snapshot. Lines are compared with their element refs stripped, because refs are numbered in page order and one inserted element would otherwise renumber everything after it.
Snapshots drop bare div/span/table/tr/td/th wrappers and show same-origin links as paths. On a table layout those tags were most of the output.
SAFARI_MCP_TOOLS=core registers only the everyday tools, for clients that load every tool definition up front.
When an HTTP session ends, it closes the tabs it opened.

The other three change how the extension handles windows and tabs. I want to see those in a real Safari with the extension rebuilt before they ship, not only in jsdom and stubs, so they wait.

What this costs

It isn't free, and I'm not going to pretend it is.

It's slower. Rewriting four PRs, with tests, took about an hour, and the full suite (962 tests) runs on my commit, not theirs. Merging would have taken minutes.

Contributors lose the commit. GitHub's contributor graph counts commits, so someone whose idea shipped doesn't appear there. The changelog credits them by PR number and handle, and I say so on the PR. It's still less than they would get elsewhere, and some people will reasonably go contribute somewhere that merges.

My rewrite can be worse than their original. When I re-implement, I can introduce a bug they didn't have. The tests catch some of that. The rest is on me, which is at least where the responsibility belongs.

Who should do this

Most projects shouldn't. If your library formats dates, merging a reviewed PR is fine, and making contributors watch their work get retyped is just rude.

But some tools hold the keys: browser automation that runs in a logged-in profile, anything with Accessibility or Full Disk Access, password managers, CI plugins, anything shipping a native binary. For those, "the diff looked fine and CI passed" checks the wrong thing. The question isn't whether the change is correct. It's whether you would run that code as yourself, on the machine where your sessions live, without reading it. For me the answer is no, so I don't.

Out of 32 outside PRs to this repo so far, five were merged as written, all before these rules existed. The ideas from at least seven more shipped as rewrites. That ratio might change. The rule that outside code never runs on my Mac won't.

n8n's Error Trigger Is Opt-In. My Bot Gate Failed for 71 Hours and Alerted Nobody.

אחיה כהן — Thu, 22 Oct 2026 16:04:14 +0000

One of my own workflows — the gate that decides whether a new WhatsApp contact gets the bot or gets me — failed 24 times between Thursday and Sunday. Seventy-one hours. I found out on Monday morning, by opening the executions list for an unrelated reason.

That is embarrassing for someone who sells automation. So instead of fixing the one workflow and moving on, I went and checked error-handling coverage across my production instance. It was far lower than the number in my head.

n8n 2.35.5, queue mode, Postgres.

Why silence is the default

Error handling in n8n is opt-in, per workflow. You build one workflow whose trigger is the Error Trigger node, then in every other workflow you open Settings → Error Workflow and point it at that one. There is no switch that applies it to everything you have already built, or to everything you build next.

That is a per-workflow checkbox on a list that grows every week. Nobody forgets on purpose. You just build yet another workflow at 11pm, it works, you activate it, and you move on. The failure mode of an opt-in safety net is that coverage decays quietly while the number in your head stays at "yeah, we have error handling."

Mine had decayed further than I would have guessed.

What the gap actually cost

I pulled the failures of my own internal workflows, grouped by workflow, with a column for whether that workflow had an error handler attached:

Workflow	Guarded	Failures	Window
WhatsApp group lead detection (AI)	no	34	36.5 h
Personal-line bot gate	no	24	70.9 h
Campaign-failure watchdog	no	11	8.7 h
Website lead intake form	no	4	53.0 h

Read the last column, not the failure counts. The longest is 70.9 hours — a WhatsApp bot gate that failed 24 times over three days while I was working on other things. Nothing was on fire. No customer wrote in. The bot simply did not answer new contacts, and the only reason I found it is that I went looking.

The workflows that did have an error handler attached failed in the same week too, and none of them stayed broken for long, because something told me.

That is the whole value proposition of the Error Trigger, and it is not "fewer failures." It is failures that end in hours instead of days.

The part that actually scared me

A few of my workflows contain an Error Trigger node. Those are the handlers — the things that send the Telegram alert. Every one of them was itself unguarded, and the one covering the most workflows failed during that same week, leaving everything it guarded with no alerting at all and no way to find out. The error handler cannot report its own errors, because the thing that reports errors is the error handler. Quis custodiet ipsos custodes, in YAML.

You cannot fix this by pointing handler A at handler B, either. That just moves the single point of silence one hop and adds a cycle you will forget about. The catcher has to be watched from outside n8n.

The pattern, in four parts

1. One handler, not one per project. Fan-in beats fan-out. A single Error Trigger workflow that formats {{ $json.workflow.name }}, {{ $json.execution.id }} and {{ $json.execution.error.message }} into one alert is easier to keep correct than six near-copies.

2. Audit coverage with a query, not with your memory. This is the whole audit — run it against your n8n Postgres:

SELECT w.name,
       (w.settings->>'errorWorkflow' IS NOT NULL
        AND w.settings->>'errorWorkflow' <> '') AS guarded
FROM workflow_entity w
WHERE w.active = true
ORDER BY guarded, w.name;

Everything with guarded = f is a workflow that can fail into the void. If you are on n8n Cloud, the same check runs off GET /api/v1/workflows?active=true and reading settings.errorWorkflow per item.

That query is now the first line of my weekly runbook, next to the backup check. A new f row gets treated the way a failing test does.

3. Make the handler loud about workflows, not just about errors. The first thing I changed in mine was putting the workflow name in the subject line instead of in the body. That sounds trivial. It is the difference between "an automation failed" (which you snooze) and "the lead intake failed" (which you do not).

4. Guard the guard from outside. The Error Trigger has a blind spot that no amount of coverage fixes: it fires when an execution fails. It does not fire when an execution never starts — a deactivated trigger, a dead cron, a webhook whose URL changed, a worker that is not consuming the queue. A workflow that stopped running entirely produces zero failed executions and therefore zero alerts. It looks exactly like a quiet week.

So the handler pings a dead man's switch on every run, and a plain cron on a different machine screams if the ping stops:

# in the error handler workflow, and in one heartbeat workflow per instance
curl -fsS -m 10 "https://your-monitor/ping/$SLUG" || true

# elsewhere — not on the n8n box
LAST=$(stat -f %m /var/lib/heartbeat/n8n1 2>/dev/null || echo 0)
if [ $(( $(date +%s) - LAST )) -gt 3600 ]; then
  notify "n8n1 heartbeat is $(( ($(date +%s) - LAST) / 60 ))m stale"
fi

The || true matters: a monitoring call that can fail the run it is monitoring is worse than no monitoring.

That is it. Four parts, none clever. The reason it is worth writing down is that I had parts 1 and 3 for as long as I have run this instance and still ate a three-day outage, because I never had part 2 and never imagined I needed part 4.

Where I landed

I am not going to pretend this is finished. As I write this, coverage is still well short of complete. What changed is that I now have the query that produces the number and a list of unguarded workflows in the order I am going to fix them, longest silent window first. The handler-watching-the-handler problem is the part I am fixing today, because it is one workflow and a lot depends on it.

The honest reason I am writing this before finishing it: the audit took twenty minutes and the three-day outage took three days. Those twenty minutes are the cheapest thing in the entire stack I maintain — cheaper than the WhatsApp bots I run in production for clients, and a rounding error against the numbers in this breakdown of what business automation actually costs. Run the query before you finish reading this post and you will probably learn something uncomfortable too.

One genuine question, because I do not think I have solved this part: how do you monitor the trigger that never fires? A heartbeat proves the instance is alive and proves that workflow ran. It does not prove that a webhook from a third party still arrives, or that a specific cron survived the last upgrade. Per-workflow "expected minimum run rate" alerting is the obvious answer and it also sounds like a maintenance burden that decays exactly like error-workflow coverage did.

If you run n8n in production: do you alert on absence of runs, and if so — how do you keep the thresholds from rotting?

WAHA vs Twilio: The SQL That Finds Your Real WhatsApp Bill

אחיה כהן — Thu, 22 Oct 2026 16:04:09 +0000

My WhatsApp stack runs on self-hosted WAHA, and I get no per-message invoice for any of it.

That is not a brag, it is the setup for an honest accounting. Because "self-hosting is cheaper" is the least interesting sentence in infrastructure, and it is usually said by someone who has never been paged at 7am by a bot that went quiet at 2am. I want to put a real number on both sides of that trade: the money Twilio would have charged, and the money self-hosting quietly takes back.

All the rates below were fetched on August 27, 2026. The rate cards move quarterly, so check yours.

The traffic, modeled

Take a hypothetical WhatsApp line bridged from WAHA into a self-hosted Chatwoot, moving 10,000 messages a month, about half inbound and half outbound (illustrative numbers, not a real deployment).

Most benchmarks stop here, multiply by a per-message rate, and publish. That answer is wrong, because Meta does not charge per message. It charges per template sent outside an open customer service window. Multiplying all 10,000 by a template rate overstates the Meta line several times over. Multiplying just the outbound half still overstates it.

Since November 1, 2024 non-template messages are free. Since July 1, 2025 utility templates answering a user inside an open 24-hour window are also free. So the only line that costs money is the outbound message that goes out when nobody has written to you in the last day.

Which means the number you actually need is not "how many messages," it is "how many outbound messages had no inbound message from that contact in the preceding 24 hours."

The query that produces the real bill

Here it is against Chatwoot's schema. It uses a window function rather than a correlated NOT EXISTS, because on a messages table of any size the correlated version will happily eat your connection pool.

WITH src AS (
  SELECT m.conversation_id, m.created_at, m.message_type
  FROM messages m
  WHERE m.inbox_id IN (/* your WhatsApp inbox ids */)
    AND m.created_at > now() - interval '33 days'
    AND m.message_type IN (0, 1)             -- 0 = incoming, 1 = outgoing
), w AS (
  SELECT *,
    max(created_at) FILTER (WHERE message_type = 0) OVER (
      PARTITION BY conversation_id ORDER BY created_at
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING
    ) AS last_in
  FROM src
)
SELECT
  count(*) FILTER (WHERE message_type = 1) AS outbound,
  count(*) FILTER (WHERE message_type = 1
        AND last_in IS NOT NULL
        AND created_at - last_in <= interval '24 hours') AS inside_window,
  count(*) FILTER (WHERE message_type = 1
        AND (last_in IS NULL
             OR created_at - last_in > interval '24 hours')) AS outside_window
FROM w
WHERE created_at > now() - interval '30 days';

Two details worth stealing: pull 33 days of history but count only the last 30, otherwise messages near the boundary look like they have no preceding inbound and you overstate your bill. And ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING is what keeps a message from counting itself as its own window opener.

Run it and you get three numbers: outbound, inside_window and outside_window. Only the last one costs you anything.

What that costs on Twilio

Twilio's WhatsApp pricing is two layers. Its own fee is $0.005 per message, inbound or outbound, and that one applies to every message. On top sits Meta's template fee, passed straight through, which varies by the recipient's country calling code.

I'm in Israel. Meta's USD rate card effective July 1, 2026:

Template category	Israel	UK	Germany	India
Marketing	$0.0353	$0.0635	$0.1365	$0.0118
Utility	$0.0053	$0.0220	$0.0550	$0.0014
Authentication	$0.0053	$0.0220	$0.0550	$0.0014

Israel is a cheap market for utility and a mid market for marketing. Germany is over ten times Israel's utility rate. If you are benchmarking, your country's row is the whole story. A US-centric blog post about WhatsApp costs is nearly useless to you.

The hypothetical month, priced out. Say half of the 5,000 outbound messages (2,500) go out with no open window:

Twilio handling   10,000 × $0.005   = $50.00
Meta (utility)     2,500 × $0.0053  = $13.25
                                    ---------
                                      $63.25

Meta (marketing)   2,500 × $0.0353  = $88.25
                                    ---------
                                      $138.25

About $63 if every billable template is a utility template. About $138 if they are marketing. The gap between those two numbers is not a pricing question, it is a template-categorization question, and Meta decides the category, not you.

The other side of the ledger changed in June, quietly

If you last looked at WAHA a year ago, you priced it wrong. WAHA used to sell a "Plus" license for the features anyone running it in production actually needs. In release 2026.6.1, announced June 21, 2026, every Plus feature moved into the free Core image and the tiers collapsed into a single optional $5/month Community subscription. The project's own words: "100% free and open source, with no limits on messages or time, and no license expiration."

So the software line is now genuinely $0.

The hardware line: WAHA is running on a 2 vCPU / 4 GB / 40 GB x86 VPS. It is not alone on that box: Redis and a second internal service share it. Under day-to-day traffic the CPU sits close to idle. This workload is not compute-bound, it is session-bound. Whatever your provider charges for the cheapest 4 GB instance, single digits a month, it does not move the comparison. Round the infra to $10 and self-hosting is still several times cheaper than the utility-rate scenario at this volume, and the gap widens with traffic.

Which is exactly the point at which an honest post has to stop being a sales pitch.

What self-hosting actually charges you

It bills in incidents, not invoices. Here is last week's, in full.

On August 23 I rotated WAHA_API_KEY. The rotation updated /opt/waha/.env and the nginx snippet that injects the header. What it did not update was a second vhost, an internal tailnet-only copy created weeks earlier by duplicating the public one, where the key had been written as a literal instead of the $waha_api_key variable.

Result: every GET /api/files/… over the internal path started returning 401. Bots that download an image, OCR it, and act on the contents stopped being able to fetch anything. Of the three code nodes involved, one threw and killed its run outright; the other two caught the error and skipped silently, so those pipelines produced output — just output with no images in it. The public vhost was untouched, so every check that went through the domain came back green.

The failure surfaced the next morning, because nobody had sent a photo overnight. A one-line fix, roughly twelve hours of quiet wrongness, and a monitoring path that was structurally incapable of seeing it.

Twilio would have absorbed that entire class of problem. That is what the Twilio bill buys. Not messages. The absence of a category of 2am.

And there is a risk that no amount of care removes. WAHA drives a real WhatsApp Web session. Its own homepage says it plainly: "WhatsApp does not allow bots or unofficial clients on their platform, so this shouldn't be considered totally safe." A banned number is not a support ticket, it is a dead asset. That is a business risk, not a technical one, and it does not belong in a cost table. It belongs in whatever conversation you have before you build.

The line I actually draw

After enough of these deployments, the rule I use with clients is not about volume at all:

The number is the business. A business's only phone line, a store's published contact. Official API, pay Twilio. The ban risk is unpriceable.
Internal, operational, or a secondary channel. Courier groups, staff notifications, an intake line that can be replaced in an afternoon. WAHA. The savings are real and the downside is survivable.
Marketing blasts at any volume. Official API, and check the marketing rate for your country before you promise anyone a budget. At $0.0353 a message in Israel and $0.1365 in Germany, the same campaign has wildly different economics depending on who receives it.

Volume is the wrong axis. Replaceability is the right one. This is roughly the split behind the pricing I quote Israeli businesses for WhatsApp automation: the channel decision comes first, and the bill follows from it.

One more thing worth knowing: Meta has further pricing changes landing October 1, 2026, covering service and utility messages. Whatever you calculate today has a shelf life of about five weeks.

Run the query

The number that decides this for you is your own outside_window count, and it is the one input a vendor pricing page cannot give you.

So: run it against your own inboxes and post the three numbers. Outbound, inside window, outside window. I am specifically curious what share of your outbound lands outside the window, and whether it holds steady across use cases. If that ratio is stable, it is a much better rule of thumb than anything on a vendor pricing page.

What Self-Hosted Chatwoot Actually Costs to Run

אחיה כהן — Thu, 22 Oct 2026 15:50:00 +0000

Disclosure: I run a small automation shop, I set Chatwoot up for clients, and ACHIYAVS is my affiliate code — if you use it on Chatwoot Cloud you pay 5% less and I earn a commission. Self-hosting, which is most of this post, earns me nothing.

Every "Chatwoot pricing" article copies the same four numbers off the pricing page. None of them say what the free option actually consumes, because none of them are running it.

I am. So here is what it takes.

The install

One box. Not a cluster, not a managed database, no autoscaling group.

What it uses

A self-hosted install is four containers: Rails, Postgres, Sidekiq and Redis.

A typical small-business install fits comfortably on a 4 GB VPS.

The structural point: that footprint tracks message volume, not seat count. Adding an agent to a self-hosted install costs nothing. On Cloud, every seat is another line on the bill, every month, for as long as you have it.

The line item nobody quotes

I went looking for what my install would cost on Cloud, and found the thing that actually decides the tier — and it is not the price.

Each Cloud tier caps how long your conversation history is kept. Thirty days on the free tier, a year on the cheapest paid one, two and three years above that.

If your history goes back further than a year, on the entry paid tier the older conversations would already be gone — not archived, gone.

A support inbox is a record. "You told me when we signed up that this was included" is a question someone has to be able to answer. That constraint, not the sticker price, is what pushes a team up a tier.

I put the full tier-by-tier breakdown, with the retention caps and the crossover math at different team sizes, on my own site: what Chatwoot actually costs. It is the version I wish I had found.

The cost that is not in anyone's table

Self-hosting is not free. It costs the thing hardest to price: your attention, at inconvenient hours.

In the months I have run this I have handled Postgres connection-pool exhaustion, a Redis eviction policy that quietly dropped background jobs, a log rotation config that corrupted an access log badly enough to break my own monitoring, and an upgrade that reverted files I had mounted into the container.

None of that was Chatwoot's fault. All of it was the price of the $0 licence.

If your team does not already have someone comfortable in a terminal at 11pm, the honest answer is that Cloud is cheaper for you than self-hosting — because the alternative is not "a server," it is "a server plus a person."

So which one

Self-host if you have ops capacity, more than a handful of seats, and you want history you control. The economics improve with every seat and never get worse.

Take Cloud if support is not your engineering problem and you would rather pay for that boundary. That is a legitimate purchase, not a defeat.

And if you take Cloud, the code is ACHIYAVS for 5% off — which is the disclosure at the top of this post, and the real number. Search for a Chatwoot code and you will find "70% off" and "$100 off" on half a dozen coupon sites. The published affiliate terms give the customer 5%. Anything larger is expired or was never real.

On a bigger team that discount adds up. It is not a reason to choose Cloud. It is just the correct number, which turns out to be surprisingly hard to find.

If you self-host Chatwoot — what does your install actually use, and did the retention cap ever catch you out?

Reinstalling a Safari extension doesn't replace it. I found a dozen copies still running.

אחיה כהן — Mon, 19 Oct 2026 03:24:31 +0000

For two weeks, a bug report on my open-source project said the same thing in slightly different words: a tab receipt worked, and a minute later it didn't.

The project is Safari MCP, an MCP server that lets AI agents drive your real, logged-in Safari on macOS. When an agent opens a tab, the Safari Web Extension hands it a receipt, an opaque token that pins every later call to that exact tab. A receipt is documented to survive reconnects and restarts. In issue #143 it didn't survive two minutes:

Tab safety: this extension has no record of that receipt.

The tab was still open. The agent just couldn't reach it anymore, and it couldn't close it either, because closing a tab you can't prove is yours is how you close the user's tab instead.

I had a theory, and it was wrong. The real cause was something I had never seen described anywhere: Safari keeps the extension context of every app generation it has ever loaded. Reinstalling the extension app doesn't replace the running extension. It adds another one.

The theory that didn't hold

A Safari Web Extension's background worker is not long-lived. Safari stops it when idle and starts it again on the next event. My extension keeps its receipts in storage.local, tagged with a "browser session epoch" so that receipts from a previous Safari launch are thrown away. The epoch lived in storage.session.

So the first theory was: Safari clears storage.session every time it terminates the worker, the epoch rotates, and every receipt from the old epoch is dropped.

That's partly true. Every worker instance does get its own storage.session. But it didn't explain the data. I read the profile's LocalStorage.db and its WAL read-only and listed every envelope the extension wrote. In five minutes on 13 October there were four different epochs. Four envelopes were written in the same millisecond, each under a different epoch.

One worker restarting doesn't write four envelopes in one millisecond. Several workers alive at the same time do.

What was actually running

safari_doctor (the project's diagnostic tool) already counted worker connections. In one five-minute window, 16 workers had connected to the daemon. The extension keeps a one-minute keepalive alarm, so I expected roughly one worker per minute. I was getting three.

Then I looked at what the Safari process had mapped. It held resources from about a dozen different builds of the extension app. Some of those builds had already been deleted from disk.

That machine had been through a lot of extension reinstalls, because I build the extension from source while developing it. Each reinstall registered a new app. Safari started the new one and never stopped the old ones. Every one of those contexts:

wakes on its own one-minute alarm as a fresh worker instance,
connects to the local daemon,
verifies itself, and
competes for the daemon's single lease, the right to receive commands.

About half of them were older generations, running code I had long since fixed. The other half were current, and even those couldn't agree with each other: each context has tab and window ids of its own. A receipt minted in one context resolves only in that context. When a different context wrote the shared envelope, it wrote back only the records it could resolve, which could be none. I watched the envelope go empty after a single close_tab from a different session.

So a receipt "expired" whenever the lease moved to a context that had never heard of it.

The fix that didn't work

My first fix was the obvious one: when a worker that doesn't announce the current build takes the lease, tell it to reload. A reload restarts the extension from the app on disk, so the old code should be gone.

It wasn't. Reloading an old context restarts that same old generation. In 90 minutes the daemon sent 45 reloads and never ran out of old contexts to reload.

What shipped instead

The daemon now decides who leads, instead of hoping the old contexts go away. This is in v2.22.17:

The extension announces its build when it connects. A worker that announces no build never takes the lease while a current one has verified in the last 15 minutes, and a current worker takes the lease from an old holder at once.
Current contexts are told apart by extension origin. The first current context to lead becomes the home context, and no other origin takes the lease while the home context is alive. The daemon logs every handover, so the next time this happens there is a line that says which context lost.
The new build stores its state under storage keys no older build touches. An old context that is still alive can't overwrite what the current one stored.
The daemon names the browser session, not storage.session. It sends the identity of the running Safari process with every response, so every worker instance agrees on the epoch and only a real Safari restart changes it.

And the honest part: the only thing that actually removes the old contexts is quitting Safari and opening it again. Reinstalling, reloading, and disabling and re-enabling the extension don't.

What's still open

The issue is still open. One context can still write an envelope without records it can't resolve. The real fix is merge-on-write, so a write never drops what it doesn't understand, and I'm keeping #143 open until that lands and a full day passes with no refusal on release code.

If you ship a Safari Web Extension

I can't tell you this is how Safari behaves on every machine. I measured it on one Mac after many developer reinstalls. A user who installs once from the App Store may never see two generations side by side. But a few things are worth checking in your own extension:

Don't assume one background context. If you share state through storage.local, more than one live instance of your extension may be writing it, some running older code.
Version your storage keys when the shape changes, so an older generation can't overwrite a newer one's data.
Don't trust storage.session as a session identity. Each worker instance gets its own.
If your extension talks to a native app or a local server, let that side decide which instance is authoritative. It's the only party that sees all of them.
Tell users who see strange state after an update to quit Safari once. It sounds like folk advice. Here it's the documented fix.

The full timeline, with the storage epochs and the daemon log lines, is in issue #143, and the changes are in the changelog. If you've seen the same thing in your own extension, or you know where Safari documents this, I'd like to hear about it in the comments.

Safari gave my blank tab no URL. My security check read that as "not yours."

אחיה כהן — Sat, 10 Oct 2026 19:28:10 +0000

I maintain safari-mcp, an MCP server that lets AI agents drive the real Safari on a Mac, logged-in sessions included. On October 7 an agent opened a blank tab, and its very next command on that tab was refused:

receipt is not valid for this origin

The agent had done everything right. It called safari_new_tab() without a URL, kept the receipt the tool returned, and passed it to safari_navigate. The tab could not be navigated, the receipt could not be rotated, and the tab could not be closed. It sat there in a named Safari profile, and nothing the agent was allowed to do could touch it.

I shipped two releases that day, and each changed one line of code. Both lines were in a guard I had built to be strict on purpose.

What a receipt is

When the safari-mcp Safari extension opens a tab for an agent, it mints an opaque receipt for that tab. Every later command carries the receipt, and before it runs anything the extension checks two things:

the receipt belongs to this tab, and
the tab is still on the origin the receipt was minted on.

The second check is the one that matters. An agent works in a browser that also holds the user's email, bank and admin panels. If a page redirects the agent's tab somewhere else, I want the agent's next evaluate refused, not run against whatever is loaded there now. To keep working, the agent has to ask for a fresh receipt on purpose (getReceipt), and the extension issues one only when it can read an http(s) origin, or about:blank, for the tab.

Fail closed. On paper, that is exactly the behavior you want.

The bug was one missing value

This is how the extension derived a tab's origin before the fix:

function _receiptOrigin(rawUrl) {
  const raw = String(rawUrl || "");
  if (raw === "about:blank") return raw;
  try {
    const parsed = new URL(raw);
    return /^https?:$/.test(parsed.protocol) ? parsed.origin : "";
  } catch {
    return "";
  }
}

A blank tab's receipt is minted on about:blank. I assumed Safari would report a blank tab's URL as about:blank. It doesn't. It leaves url off the tab entirely.

String(undefined || "") is "". new URL("") throws. The function returns "", which in this code means "no origin at all". "about:blank" !== "", so the check refused the tab's own receipt. The escape hatch called the same function, got the same "", and refused as well: Cannot issue a receipt for this tab URL.

The guard did what I built it to do. It just could not tell "this tab moved somewhere else" from "Safari didn't tell me where this tab is", and it treated both as an attack.

The sibling bug, one day earlier

On October 6 a different run left two tabs open in a named profile, both on claude.ai/new. In both cases the page itself had moved the tab, through a redirect or a login bounce. Rotation only works when the new page has an http(s) origin the extension can read; a tab that lands on a page without one, or on a page whose URL Safari doesn't show the extension, can't be rotated.

close_tab was held to the receipt's origin like every other command. The refusal suggested rotating the receipt, which was exactly what these two tabs couldn't do. Nothing could close them.

Same shape as the blank tab: a rule that is right for commands that run code in a page, applied to a command that doesn't.

Two one-line fixes

v2.22.12, the moved tab:

const allowReceiptOriginChange = type === "get_tab_receipt" || type === "close_tab";

Closing a tab runs nothing in the page, so a close now finds its tab the way getReceipt does, by the receipt rather than by the origin. Every other command stays bound to the receipt's origin, and a receipt the extension never issued still closes nothing.

v2.22.13, the blank tab:

if (!raw || raw === "about:blank") return "about:blank";

A tab Safari shows no URL for now counts as blank. A receipt minted on a web origin still takes no page command there, so a tab that went from a real site to a blank page is still refused.

What I got wrong

The origin binding was fine. Two assumptions inside it were not.

I treated "unknown" as "mismatch". A fail-closed check has at least three outcomes: it matches, it doesn't match, or the platform didn't give you enough to decide. My code folded the third into the second, because the function that read the URL returned the same empty string for "no URL reported" and for "an origin I won't trust". Once those two share a value, the guard will sooner or later lock out the owner. The fix was to decide, in code, what a missing URL means for a tab the extension created: it is blank.

I held every command to the same rule. The origin check exists to stop code from running in the wrong page. close_tab runs no code in any page. Binding it to the origin added no protection and took away the only way out. A guard should be as narrow as the harm it prevents, and every guard needs an exit that doesn't depend on the thing it guards.

A test that mocks the extension API with a tidy url: "about:blank" could never have caught the first bug. Both showed up the first time a real Safari profile did something slightly unusual, which is the reason this project drives the real browser in the first place.

If you use safari-mcp's Safari extension, both fixes live in the extension, so they take effect once you rebuild the extension app from 2.22.13 or later (the README's "Installing the Extension" section has the steps).

How do your own guards represent "I couldn't tell"? Does it get its own value, or does it quietly share one with "no"?

Cupom Chatwoot 2026: o único código real dá 5% (e onde colocar)

אחיה כהן — Tue, 06 Oct 2026 08:13:33 +0000

Aviso antes de tudo: ACHIYAVS é o meu código de afiliado do Chatwoot. Se você usar, paga 5% a menos no Chatwoot Cloud e o Chatwoot me paga uma comissão. O acordo é só esse, e é por isso que este texto existe.

Escrevo em português porque o Chatwoot é muito usado no Brasil e, quando procurei "cupom chatwoot", não achei nenhuma página em português com um código que funcione no Chatwoot Cloud. Achei o guia oficial que mostra onde digitar um cupom, uma oferta de parceiro para outro produto e listas de códigos que não existem.

O resumo

Código: ACHIYAVS
Desconto: 5% em todos os pagamentos da assinatura, mensal ou anual, segundo as regras do programa de afiliados do Chatwoot
Vale para: os planos pagos do Chatwoot Cloud (Startups, Business e Enterprise)
Não vale para: o plano gratuito Hacker e o Chatwoot auto-hospedado
Onde colocar: dentro da conta, no portal de faturamento. No cadastro não existe campo de cupom

Quanto isso dá em reais

Os preços são os da página de preços do Chatwoot em português, por agente, por mês:

Plano	Preço	Com ACHIYAVS	Diferença por agente
Startups	R$ 119	R$ 113,05	R$ 5,95 por mês
Business	R$ 249	R$ 236,55	R$ 12,45 por mês
Enterprise	R$ 639	R$ 607,05	R$ 31,95 por mês

É pouco. Numa equipe de cinco atendentes no Business, a diferença fica em R$ 62,25 por mês. Prefiro mostrar esse número pequeno e verdadeiro a prometer um desconto grande que não existe.

Onde digitar o código

O cupom entra depois que a conta já existe. O teste grátis de 15 dias vem primeiro:

Entre no Chatwoot Cloud e abra Configurações → Faturamento.
Clique em Ir para o portal de faturamento.
Escolha o plano, clique em Adicionar código promocional, digite ACHIYAVS e clique em Aplicar.
Confira o resumo do pedido antes de clicar em Enviar. O valor precisa aparecer com o desconto; se não aparecer, o código não foi aplicado.

O próprio Chatwoot tem um guia em português sobre como usar um cupom, com as telas.

Vale saber também: um link de afiliado (aquele com ?via= no final) não dá desconto nenhum sozinho. O Chatwoot registra a indicação só pelo cupom. Sem digitar o código, você paga o preço cheio.

E os cupons de 50%, 60%, 70%?

Quem procura cupom do Chatwoot encontra SINTU, PINTU, START, KUMAR, MALIK, SAVE55, GET50 e outros, prometendo de 20% a 70% de desconto. Nenhum corresponde a um desconto que o Chatwoot oferece. O programa de afiliados dá os mesmos 5% para todos (as regras estão publicadas), então um código que promete mais do que isso não é de afiliado: foi inventado, é de outro produto ou expirou há muito tempo.

E os 15% da fazer.ai?

Esse desconto existe, mas é para outro produto. A fazer.ai é a parceira oficial do Chatwoot no Brasil e oferece 15% na licença Enterprise do Chatwoot auto-hospedado. O cupom é aplicado no painel de Super Admin da sua própria instalação e vale só para operações no Brasil. Se você roda o Chatwoot no seu servidor e precisa do Enterprise, é a melhor oferta que conheço. No Chatwoot Cloud, o desconto disponível é o de afiliado, de 5%.

O que pesa mais do que o cupom

Cada plano do Chatwoot Cloud guarda o histórico de conversas por um tempo limitado e apaga o que passa disso: 30 dias no Hacker, 1 ano no Startups, 2 anos no Business e 3 anos no Enterprise. Se a sua equipe precisa consultar conversas de mais de um ano atrás, o plano certo é o Business, e a diferença de R$ 119 para R$ 249 por agente pesa muito mais do que qualquer cupom. O Business também traz voz, times e regras de automação, que o Startups não tem.

Se você prefere auto-hospedar

O Chatwoot Community Edition é gratuito e roda no seu servidor sem limite de agentes, então ali o cupom não se aplica, e nem precisa. Eu rodo Chatwoot auto-hospedado para clientes, ligado ao WhatsApp, e sei que cuidar do servidor dá trabalho. O Cloud faz sentido para quem não quer esse trabalho, e é aí que o código vale.

Última verificação: 6 de outubro de 2026, no painel de afiliados do Chatwoot, onde o ACHIYAVS aparece como "5% off on all payments". A versão em inglês desta página fica em achiya-automation.com.

n8n's Postgres Node Doesn't Send Parameters. My Dry-Run Did.

אחיה כהן — Mon, 05 Oct 2026 05:49:09 +0000

The n8n docs for the Postgres node say you can use $1, $2 and $3 in a query "to build prepared statements to use with query parameters." On September 18 I found out what that means in practice, from a failure that my own dry-run had told me couldn't happen.

The query that passed in psql

I was running an end-to-end test of a workflow I maintain that books a callback. One Postgres node stores when the callback is due, and the number of minutes comes from earlier in the flow. Sometimes there is no number, so the value is an empty string. Simplified, the node's query looked like this:

SELECT CASE
  WHEN $1 = '' THEN NULL
  ELSE make_interval(mins => $1::int)
END AS delay;

Before deploying, I had tested it in psql the way I'd test any parameterized query:

PREPARE p(text) AS
  SELECT CASE WHEN $1 = '' THEN NULL
         ELSE make_interval(mins => $1::int) END AS delay;
EXECUTE p('');   -- returns NULL

NULL, as expected. The CASE sees the empty string and never reaches the cast.

In n8n, the same node failed with invalid input syntax for type integer: "". I caught it only because I was watching that test step by step. The node had On Error set to Continue (using regular output), so the execution finished green. No retry, no alert, and no callback saved.

What n8n actually sends

The Postgres node runs on pg-promise, pinned at 11.9.1 in n8n 2.41.6, the latest stable release as I write this. pg-promise has its own formatting engine, and its README says the engine is "used by default with all query methods, unless you opt out of it entirely via option pgFormatting." n8n creates its pg-promise instance without that option.

So the values never travel as bind parameters. pg-promise escapes them and writes them into the SQL text on the client, and Postgres receives one plain string. I reproduced it this morning against a local Postgres 16.15 with the same pg-promise version:

const pgp = require('pg-promise')();
const sql = "SELECT CASE WHEN $1 = '' THEN NULL ELSE make_interval(mins => $1::int) END AS delay";
console.log(pgp.as.format(sql, ['']));

SELECT CASE WHEN '' = '' THEN NULL ELSE make_interval(mins => ''::int) END AS delay

Run that against the database and you get error 22P02, invalid input syntax for type integer: "". Send the same SQL with the same value as a real parameter (pg-promise's ParameterizedQuery) and it returns {"delay": null}, exactly like my psql test.

To be fair to n8n, the part of the docs that says it "sanitizes data in query parameters, which prevents SQL injection" holds up. The escaping is real. What changes is how Postgres types the value.

Why the CASE didn't help

$1::int on a real parameter is a run-time cast. It runs when that branch runs, and in my test that branch never ran.

''::int is something else. The Postgres docs on type casts put it this way: "A cast applied to an unadorned string literal represents the initial assignment of a type to a literal constant value." Postgres hands the string to the integer input routine while it is still analyzing the statement, before it evaluates anything. An empty string isn't valid integer input, so the statement fails before the CASE gets a say. psql points the caret right at it:

ERROR:  invalid input syntax for type integer: ""
LINE 1: ...WHEN '' = '' THEN NULL ELSE make_interval(mins => ''::int) E...
                                                             ^

The section on expression evaluation rules says it plainly: CASE "is not a cure-all," and it "does not prevent early evaluation of constant subexpressions." Once your parameters are pasted in as literals, a lot more of your query is constant than it looks.

The first half of the lesson: commas

That workflow had already burned me once through the same Query Parameters field. Earlier, a free-text value with a comma in it shifted every parameter after it. The row was saved without an error, and every value after the comma had moved one column over.

The reason is in executeQuery.operation.ts. For node version 2.5 and up (new nodes get 2.7), n8n evaluates each {{ }} in the Query Parameters field separately. If the result is an array, it takes the items one by one. Anything else becomes a string, and unless that string happens to parse as JSON, it goes through stringToArray:

return String(str)
  .split(',')
  .filter((entry) => entry)
  .map((entry) => entry.trim());

Split on commas, drop the empty pieces, trim the rest. The docs do describe the field as "a comma-separated list of values." They don't mention that the split happens after your expressions are evaluated, inside your data.

Here is what that logic does to one item. I ran a copy of those exact functions:

// Query Parameters: {{ $json.minutes }},{{ $json.note }},{{ $json.id }}
// item: { minutes: '', note: 'call back, after 5pm', id: 7 }
// values -> ["call back", "after 5pm", "7"]

The empty minutes disappeared, and the note became two values. One value vanished and one appeared, so the count still matched three placeholders and nothing failed:

SELECT 'call back'::text AS minutes, 'after 5pm'::text AS note, '7'::int AS id
-- {"minutes":"call back","note":"after 5pm","id":7}

This is the version that worries me more. The ''::int error at least stops the node. A shifted row looks fine until somebody reads it.

What I changed

1. Query Parameters is always one array expression.

{{ [ $json.minutes, $json.note, $json.id ] }}

When the whole field is one expression that returns an array, n8n uses that array as the parameter list and nothing gets split. Commas stay inside their value, and empty strings keep their position. It's also the form the n8n docs themselves use for IN (...) lists.

2. Every cast on a value that can be empty goes through NULLIF.

SELECT make_interval(mins => NULLIF($1, '')::int) AS delay;

After formatting, the empty case becomes make_interval(mins => NULLIF('', '')::int), which returns NULL, and with '15' it returns a 15-minute interval. Both ran clean in the reproduction. NULLIF turns the empty string into NULL before the cast, and NULL cast to an integer is just NULL.

3. Dry-runs test the SQL that n8n will send, not a PREPARE.

I format the query with pg-promise first and run the output inside a transaction that I roll back:

const pgp = require('pg-promise')();
console.log(pgp.as.format(sql, values)); // run it in psql between BEGIN; and ROLLBACK;

My PREPARE test was correct about a query that n8n never runs.

4. On Error → Continue stays off the node that writes the thing that matters.

The node that saves the callback now fails loudly, with Retry On Fail set to three tries. Continue is fine on a step whose failure can't hide anything downstream. On that node, it turned a failure into a quiet success.

The short version

If you write SQL in n8n's Postgres node, assume your values get pasted into the text as quoted literals, because they do. A cast on one of those literals happens when Postgres analyzes the statement, whatever branch it sits in. And a comma inside a value is a parameter boundary unless you pass an array.

I build and maintain n8n integrations for businesses at Achiya Automation, and these four rules now get checked before any Postgres node goes live.

How do you fill Query Parameters in your n8n workflows, comma string or array? If it's the comma string, have you checked what happens when one of the values contains a comma?

I filed it as a flaky test. It was a crash that try/catch can't reach.

אחיה כהן — Sun, 04 Oct 2026 08:46:12 +0000

Safari MCP, the open-source server I maintain, runs one process that owns a local bridge port. Any other instance becomes a secondary: it proxies through that primary, and if the primary goes away, it takes the port over. One test covers exactly that handoff. Start a primary, start a secondary, stop the primary, wait for the secondary to say it's listening.

On October 1 that test failed once on the Node 24 macOS runner, in a pull request run. The rerun passed, Node 20 and 22 passed, and I filed issue #140 as a CI flake. The last line I wrote there was: "Filed to track the flake and the Node version it needs; no code change in this issue yet."

Two days later the same test failed again, this time on main, a few minutes after the pull request with the same code had gone green on the same Node version.

What the secondary died of

The secondary never printed its listening line. Its stderr ended like this:

Uncaught: Error: setTypeOfService EINVAL
    at Socket.setTypeOfService (node:net:911:13)
    at writeH1 (node:internal/deps/undici/undici:8022:16)
    at Object.write (node:internal/deps/undici/undici:7758:18)
    at _resume (node:internal/deps/undici/undici:9656:54)

The code that was supposed to handle a missing primary looks like every health check you have written:

try {
  const res = await fetch(`http://127.0.0.1:${port}/proxy-check`, {
    signal: AbortSignal.timeout(2000),
  });
  // ...
} catch {
  // Nothing answers on the bridge port: the primary is gone. Take it over.
  takeOverThePort();
}

When the primary is gone, fetch() should reject and the catch should run. Instead the process ended.

Why the catch never ran

The undici that ships inside Node 24 calls socket.setTypeOfService() on every HTTP/1.1 request it writes. It's a quality-of-service hint and harmless almost everywhere. On macOS, though, the kernel refuses that option on a socket whose peer has just reset the connection. The call fails with EINVAL, and Node turns that into a thrown error.

The throw happens inside undici's write path, which runs from a socket I/O callback. Nothing there routes the error into the promise that fetch() returned, so the try/catch around await fetch() never sees it. It becomes an uncaught exception, and an uncaught exception ends the process.

So the crash needs three things at once: Node 24, macOS, and a peer that resets at the wrong moment. The test stops the primary a moment after the secondary comes up, close to the secondary's first check, which is about as close to the wrong moment as a test gets. In real use the race is rarer. But a secondary that dies exactly when it should take over is the failure the whole handoff exists to prevent.

Fixed upstream, just not in Node 24

undici fixed it in nodejs/undici#5547, "fix(h1): ignore type of service errors", released in undici 8.8.0. It skips the call when nobody asked for a type of service, and it ignores the error when the call fails. Node 24 didn't get that change.

I measured the difference by counting calls to setTypeOfService during one plain fetch() to a local server:

Node	calls per fetch
24.21.0 (newest 24.x today)	1
26.10.0	0

I'm not the only one who hit this. get-bb/bb, telomi and t3code each have a pull request for the same uncaught EINVAL.

You can't schedule a race, so fail at the boundary instead

My first instinct was to reproduce the real thing: a keep-alive server in a child process, one request to pool the socket, then a reset or a kill, then a second request onto the dead socket. Two harnesses and six timing variants on Node 24.21.0 produced zero EINVALs. The kernel race simply didn't happen on my machine, which is also why the test passed nearly every time in CI.

What worked was failing at the exact boundary instead of waiting for the race. Replace the native method with one that throws what macOS throws, then let undici's own write path call it:

import { Socket } from "node:net";
import http from "node:http";

Socket.prototype.setTypeOfService = function () {
  throw Object.assign(new Error("setTypeOfService EINVAL"), { code: "EINVAL" });
};

const server = http.createServer((req, res) => res.end("ok")).listen(0, "127.0.0.1");
await new Promise((resolve) => server.on("listening", resolve));
try {
  const res = await fetch(`http://127.0.0.1:${server.address().port}/`);
  console.log("resolved:", await res.text());
} catch (err) {
  console.log("rejected:", err.message);
}

On Node 24.21.0 that script prints neither line. It dies on the uncaught EINVAL with exit code 1, try/catch and all. On Node 26.10.0 it prints resolved: ok, because undici there never makes the call.

The fix

Upgrading Node is the real fix, but I don't pick my users' Node version, and the package supports 20 and up. So the server wraps the method once at startup and ignores EINVAL only:

export function ignoreTypeOfServiceEinval(proto) {
  const original = proto.setTypeOfService;
  if (typeof original !== "function" || original.ignoresEinval) return;
  const wrapped = function (...args) {
    try {
      return original.apply(this, args);
    } catch (err) {
      if (err?.code === "EINVAL") return this;
      throw err;
    }
  };
  wrapped.ignoresEinval = true;
  proto.setTypeOfService = wrapped;
}

With the error swallowed, undici carries on writing to a socket that's gone, the write fails the normal way, and fetch() rejects into the catch that was there all along. Any other error from the method still throws. On Node 20 and 22 the method doesn't exist, so the wrapper does nothing.

The test suite now runs the script above in a child process with the wrapper applied and asserts that the fetch resolves. I checked that the test can fail: with the wrapper replaced by a no-op, the child exits 1 on Node 24.21.0 and the test goes red. With the wrapper it passes, on my machine and on Node 24.20.0 in CI. The fix shipped in v2.22.10.

What I got wrong

The label. A test that fails because the process under test died of an uncaught exception isn't flaky in any sense that matters. The code crashed, and the test just couldn't make it crash often. "Flaky" told me to wait and see, and waiting meant the second report came from main instead of from me.

If your project runs on Node 24 on macOS and calls fetch() against something that can go away under you (a local daemon, a sidecar, a dev server you restart), search your crash logs for setTypeOfService EINVAL. It won't show up as a rejected request. It shows up as a process that isn't running anymore.

An LLM Heard Women in 71% of Our 'Male' AI Voice Replies

אחיה כהן — Wed, 30 Sep 2026 09:02:02 +0000

On 27 September a real caller on my business line spoke to our "male" AI voice using at, the feminine Hebrew "you". The voice sits at roughly 135 Hz. We had chosen it with a pitch check, and the pitch check was the mistake.

In English that would be a matter of taste. In Hebrew it's a correctness bug, because present-tense verbs carry gender. Our assistant ends its greeting with "recording and passing it on", which is מקליט ומעביר for a man and מקליטה ומעבירה for a woman. The system prompt fixes the grammatical gender, so the audio has to match it for the whole call. If it doesn't, the sentence contradicts itself.

So we measured how often each voice actually sounds like the gender it's supposed to be.

The setup

The speaker was gemini-3.8-live in he-IL, one prebuilt voice per run, thinking budget 0.
Google's Chirp 3 HD catalogue labels 16 of its voice names male. We ran 13. The other three had been recorded with feminine grammar in an earlier run, which would have confounded the test.
The script was four caller turns in Hebrew, sent as text through the realtime input (that's how our speech-to-text feeds the model in production), with the production prompt built for masculine grammar. Three separate calls per voice.
Every reply of 1.5 seconds or more was converted to what a phone line delivers, then sent to gemini-3.5-flash at temperature 0 with a single one-word question.

The conversion and the judge call, trimmed from the harness:

import audioop, io, wave
import numpy as np, soxr
from google.genai import types

def phone_wav(pcm24: bytes) -> bytes:
    """24 kHz model output -> 8 kHz mu-law round trip, i.e. what the caller hears."""
    x = np.frombuffer(pcm24, dtype=np.int16).astype(np.float32)
    x8 = soxr.resample(x, 24000, 8000, quality="HQ")
    x8 = np.clip(np.round(x8), -32768, 32767).astype(np.int16)
    x8 = audioop.ulaw2lin(audioop.lin2ulaw(x8.tobytes(), 2), 2)
    buf = io.BytesIO()
    with wave.open(buf, "wb") as w:
        w.setnchannels(1); w.setsampwidth(2); w.setframerate(8000)
        w.writeframes(x8)
    return buf.getvalue()

Q = ("Listen to the speaker in this phone recording. Does the voice sound like "
     "a man or a woman? Answer with exactly one word: man, woman, or unclear.")

async def judge(client, pcm24: bytes) -> str:
    r = await client.aio.models.generate_content(
        model="models/gemini-3.5-flash",
        contents=[types.Part.from_bytes(data=phone_wav(pcm24), mime_type="audio/wav"), Q],
        config=types.GenerateContentConfig(temperature=0))
    a = (r.text or "").strip().lower()
    return "woman" if "woman" in a else ("man" if "man" in a else "unclear")

Check for "woman" before "man". The second string is inside the first.

The results

One judging pass, run on 30 September over the recordings made on 27 September:

Voice	man	woman	unclear
Zubenelgenubi	6	6	0
Algieba	5	4	2
Sadaltager	4	8	0
Algenib	3	7	0
Alnilam	3	7	0
Charon	3	8	0
Schedar	3	7	1
Umbriel	3	8	0
Enceladus	2	8	1
Sadachbia	2	9	0
Iapetus	2	10	0
Puck	2	9	1
Fenrir	0	12	0

That's 146 replies: 103 judged female (71%), 38 male (26%), 5 unclear. Only one voice was heard as a man more often than as a woman. None of the 39 calls got through without at least one reply judged female.

These voices were speaking masculine Hebrew the whole time. If the judge were leaning on grammar, that would have pushed it toward "man", so the grammar can't explain the result.

The controls

A judge that says "woman" to everything would produce the same table, so we checked it against clips where the answer is known:

Female voices from the same model, speaking feminine grammar: 34 of 34 replies judged female.
Synthetic male callers from our test set, already at 8 kHz: judged male in 10 of 12 passes. Synthetic female callers: female in 6 of 6.
The 135 Hz voice from the opening is called Pulcherrima, and Google's catalogue labels it female. We had it speak masculine grammar anyway. It was judged male in 0 of 11 replies.

The judge can recognise a man on a phone line. It just doesn't hear one in most of these voices.

Temperature 0 didn't make the judge deterministic

This was the part I didn't expect. The same 11 Algieba clips were judged male 73% of the time on 27 September, then 45% and 55% on two passes on 30 September. One of the male control clips, an angry caller, came back man, woman, woman across three passes.

What that means in practice:

One judging pass is an anecdote. Run at least three and report the spread.
Keep known-answer controls in every run, not only in the first one.
Look at direction before magnitude. In both full passes, at least 12 of the 13 voices came out at or below 50% male. The exact percentages kept moving.

Telling the model to sound male made it worse

The obvious fix was a line in the system prompt. Translated from the Hebrew, it said: "Your voice: a man's voice, low and steady. The whole call at exactly the same pitch, even in a short sentence, a thank-you or a goodbye. Never rise to a woman's pitch."

Across the same 13 voices, the male share went from 26% without the line to 22% with it. Algieba, the only voice that had been winning, dropped to 11%. My guess, which I haven't tested, is that naming "a woman" in the instruction nudges the output toward one. We had shipped the line that afternoon and removed it the same evening.

Pitch isn't the variable

This is old news in speech science. Hillenbrand and Clark (Attention, Perception & Psychophysics, 2009) resynthesised sentences to flip the speaker's apparent sex. Shifting pitch alone, or formants alone, usually failed. Shifting both worked about 82% of the time. An F0 threshold checks one of two cues, and it's the cue our 135 Hz voice already passed while still sounding like a woman.

What we shipped

Customers now choose from 11 voices, all female. The male voices are quarantined and get re-tested whenever the model changes.
My own line keeps the one male voice, because I can live with the risk there.
Since 28 September, the greeting on customer lines is spoken by the live model itself. Before that, a separate text-to-speech model rendered it under the same voice name, and you could hear the switch between the two engines.

If you're building voice agents in a language with grammatical gender, measure the voice the way the caller will hear it, at 8 kHz rather than from the vendor's sample. Pick voices with a judge and controls, not with an F0 cutoff, and don't expect adjectives in the prompt to fix it.

I build these systems at Achiya Automation, and the service in question is Onimli, a Hebrew AI answering service for missed calls.

If you've used an LLM as a judge for audio: how many passes do you run before you believe a number, and have you seen temperature 0 flip on identical clips like this?

My 24-Month Audit Archive Was Keeping a Third of Each Day

אחיה כהן — Mon, 28 Sep 2026 08:07:46 +0000

On September 6 a disk alert fired on the server that runs my voice bots: 75% full. The culprit was /var/log/auth.log, 763 MB after five days, on a box where it normally grows about 0.7 MB a week. Nearly every line started with audispd:.

I knew why. Six days earlier I had switched on auditd's syslog plugin across the fleet so a central collector could receive the audit trail. I compressed the file, wrote the cause down, and moved on.

This morning I measured it on all eight servers. The growth turned out to be the smaller finding. The archive I built to keep audit logs for 24 months had been saving about a third of each day on my busiest server, from the week I set it up.

The setup

Eight Ubuntu 24.04 servers running auditd 3.1.2, with 22 to 25 rules each. Most rules are file watches, -w <path> -p wa, on config files and on each app's directory. Israel's data security regulations require keeping access logs for 24 months. auditd knows nothing about months. Out of the box it keeps a ring:

# /etc/audit/auditd.conf
max_log_file = 8          # MB
num_logs = 5
max_log_file_action = ROTATE

Five files of 8 MB each. When the ring is full, the oldest file is deleted. So on August 25 I added a cron job at 02:17 that forces a rotation, gzips every rotated file into /var/log/audit-archive/, and deletes archives older than 730 days. Each archive's filename carries a hash of its content, so a file that moves from audit.log.1 to audit.log.2 isn't archived twice.

On August 31 I enabled the syslog plugin:

# /etc/audit/plugins.d/syslog.conf
active = yes
args = LOG_INFO LOG_AUTHPRIV

LOG_AUTHPRIV is why the copies land in auth.log. Ubuntu's rsyslog routes auth,authpriv.* there, and logrotate keeps that file for 104 weeks.

What auth.log looks like now

The same seven days of the week, before and after August 31, on six of the eight servers. The other two are dedicated to a client, so their numbers stay out of this post.

Server	Aug 24–30	Sep 21–27	Growth	audispd share
database	2.3 MB	734 MB	×324	99.7%
website	1.4 MB	729 MB	×524	99.6%
voice	0.6 MB	275 MB	×441	99.1%
WhatsApp gateway	1.0 MB	96 MB	×101	98.0%
n8n	1.3 MB	88 MB	×70	95.5%
chatwoot	1.4 MB	1.5 MB	×1	0%

The last row is a control group: the plugin has been off on that server since September 8.

Who is writing all of this?

Not people. aureport shows which rule and which executable produced the events in the local ring:

sudo aureport --input-logs -k --summary   # events per rule key
sudo aureport --input-logs -x --summary   # events per executable

Keep --input-logs. When stdin isn't a terminal, aureport reads stdin instead of the log files and prints <no events of interest were found>. That cost me ten confused minutes this morning.

On the database server, 35,247 of the 35,659 events that matched a rule came from a single watch, -w /opt/supabase -p wa, and the executable behind 35,082 of them was postgres. The app directory contains the database's data volume, so every file Postgres opens for writing (paths like base/5/2601) becomes an audit event.

On the website, 19,120 events hit the site's watch, and rsync (14,988) and rm (4,064) account for nearly all of them. That's the deploy. One deploy last night, between 23:07 and 23:12, produced 13,151 events made of 70,516 records.

On the voice server it's the same picture: 24,687 events on the app's watch, almost all from rsync. The deploy there rewrites about 30,000 files on every run, changed or not.

One write to a watched path isn't one line. It's a SYSCALL record plus CWD, one or two PATH records and PROCTITLE, 5.4 records per event on average in that deploy. The syslog plugin also forwards the EOE (end of event) record, which auditd doesn't keep in its own log, so auth.log gets one more line per event than audit.log does.

The ring runs out before the archive runs

A 40 MB ring is fine as long as 40 MB lasts longer than the gap between archive runs. Here's how long it lasts, from aureport --input-logs -t:

database: the five files cover 13.5 hours
website: around last night's deploy, three 8 MB files filled in 3 min 48 s, then 58 s, then 17 s
chatwoot: the five files cover almost three days

The archive ran once a night. Anything that left the ring before 02:17 was deleted before anyone saved it.

So I measured the archive itself: for every archived file, the first record's timestamp and the file's mtime, merged into intervals and compared with each calendar day. Twenty-nine days, August 30 to September 27:

Server	Mean coverage	Worst day	Complete days
database	33.6%	15.0%	0 of 29
website	52.6%	9.4%	9 of 29
voice	75.0%	22.0%	16 of 29
chatwoot	94.0%	16.4%	26 of 29

On the database server, the "24-month archive" holds 234 of the last 696 hours. On the website, deploy days drop to about 10%, because a deploy late in the evening pushes everything before it out of the ring. chatwoot's three incomplete days were maintenance days: a hardening pass, a Docker update and a fleet-wide reboot.

The plugin didn't cause this. On August 30, the day before I enabled it, the database server's archive already held 28.4% of the day. Postgres had been filling the ring since the archive's first week.

The noise was the backup

The audispd lines in auth.log, the ones I spent September 6 compressing, are kept for 104 weeks. Since August 31 they have been the most complete local copy of the audit trail on these servers.

They're not a perfect copy. I counted SYSCALL records, one per event, by the timestamp inside each record, in both logs, for 23:04 to 02:00 last night:

audit.log: 19,177 events
auth.log: 18,912 events (98.6%)

The missing 1.4% left a trail too. The plugin writes to /dev/log, which on Ubuntu 24.04 is journald's socket, and journald forwards to rsyslog. During that window journald logged four Forwarding to syslog missed N messages lines, 2,789 messages in total. The journal's own copy fared worse: between 23:00 and 23:20 its rate limiter logged Suppressed … messages from auditd.service six times, 101,004 messages in all.

What I changed today

The smallest change that stops the loss is to archive more often without forcing a rotation every time. The script got a flag and a lock:

exec 9>/run/audit-archive.lock
flock -w 120 9

if [ "${1:-}" != "--no-rotate" ]; then
  /sbin/auditctl --signal rotate >/dev/null 2>&1 || pkill -USR1 auditd 2>/dev/null || true
  sleep 2
fi

The cron file got a second line:

17 2 * * * root /usr/local/bin/audit-archive.sh >/dev/null 2>&1
*/15 * * * * root /usr/local/bin/audit-archive.sh --no-rotate >/dev/null 2>&1

The nightly run still forces a rotation, so quiet servers get a daily file. The quarter-hourly run only picks up files auditd already rotated by size, which is exactly the part that used to fall off the end. The lock keeps the 02:15 and 02:17 runs from writing the same temporary file. I rolled it out to all eight servers with the old files backed up. The first run on the database server archived three files that would have been gone before tonight's 02:17.

It doesn't close every hole. A burst bigger than about 32 MB inside fifteen minutes, like two website deploys back to back, can still push a file out before the archive sees it. The durable fixes all mean writing less, and I haven't made them yet:

Stop watching the database's data directory. On August 25 I narrowed a /var/lib/docker watch to /var/lib/docker/containers for the same reason: Postgres block writes say nothing about who accessed what. The /opt/supabase watch needs the same change.
Make the deploys skip unchanged files. Thirty thousand rewritten files per deploy is an rsync problem, and auditd is only reporting it faithfully.
Give the syslog plugin its own facility, LOG_LOCAL6 with its own file, so auth.log goes back to being about logins.

Check your own servers

Three commands:

# how big is the ring?
grep -E '^(max_log_file|num_logs|max_log_file_action) ' /etc/audit/auditd.conf

# how many hours does it hold right now?
sudo aureport --input-logs -t

# who is filling it?
sudo aureport --input-logs -x --summary | head

If the second command shows fewer hours than the gap between your archive runs, your retention policy exists only in a document. I build and run automation infrastructure for small businesses at Achiya Automation, including the voice server in this post. This is the second time in five weeks that a retention number I had written down turned out to be one I had never measured.

A question for anyone who archives auditd logs for compliance: does your archive job run on rotation or on the clock, and how many hours does the ring actually hold on your busiest server? I'd especially like to hear from anyone running max_log_file_action = keep_logs with a separate mover script, and whether that held up the first time the disk got tight.

My sudo Logs Hit Nearly 10 GB. Session Count Told Me Nothing.

אחיה כהן — Thu, 24 Sep 2026 07:41:26 +0000

A disk-usage alert sent me looking at /var/log/sudo-io on a Chatwoot production box. It held 5.9 GB and was adding roughly 654 MB every week. Nothing on that server had changed. No new services, no new admins, no new cron jobs.

My first instinct was the wrong one: I assumed the server was simply busier than the others. It isn't. It runs the fewest sudo sessions of any box in the fleet that logs them.

Here is what the numbers look like, measured live across the whole fleet this morning.

The measurement

Two commands. The first counts sessions, the second measures bytes:

# how many sudo sessions were recorded
sudo find /var/log/sudo-io -name log -type f | wc -l

# how much disk those sessions occupy
sudo du -sk /var/log/sudo-io

Ten hosts in my SSH config. Only four of them have /var/log/sudo-io at all, and one of those four is dedicated to a client, so its numbers stay out of this post. The other five never had log_output enabled, and one was unreachable during the run. That inconsistency is its own finding, and I'll come back to it.

Host	Log volume	Sessions	KB per session
chatwoot	5.48 GB	16,168	356
supabase	2.33 GB	56,794	43
website	1.71 GB	14,289	126
Total	9.52 GB	87,251	114

Read the last two columns together. supabase recorded 3.5x more sudo sessions than chatwoot and produced less than half the volume. Per session, chatwoot is 8.3x heavier.

Session count and log size are not measuring the same thing, and I had been reading the wrong one.

Why bytes and sessions diverge

log_output in sudoers does not record which command ran. It records everything the command writes to its pty. A short admin command that prints two lines costs a few hundred bytes. A command that streams a file costs the size of that file.

So this:

sudo systemctl restart nginx

costs almost nothing, while this:

sudo cat /opt/chatwoot-backups/dump-2026-09-14.sql

costs the full size of the dump, every night. The dump gets written to disk a second time, into the audit log, carrying no information the original didn't already have.

That was the leak. The offsite backup job pulls a database dump every night by reading it through sudo. supabase and website already had those reads exempted in /etc/sudoers.d/iolog-exemptions. chatwoot did not. The fourth host had no exemptions file at all. Same fleet, same backup design, three different configurations — because the exemption file was written by hand on each host, one host at a time, and nothing ever checked that they matched.

The fix is an exemption, not a shutdown

The tempting fix is to turn log_output off. Don't. The recording is the point; you want to know what a human typed at 2am on a box holding customer conversations. What you don't want is a byte-for-byte copy of files you already have.

sudoers lets you carve out specific commands:

Cmnd_Alias IOLOG_EXEMPT = /usr/bin/cat /opt/chatwoot-backups/*, \
                          /usr/bin/stat /opt/chatwoot-backups/*, \
                          /usr/bin/zcat /var/log/caddy/*, \
                          /usr/bin/tail /var/log/caddy/*

Defaults!IOLOG_EXEMPT !log_output

The session still gets logged: who ran what, when. Only the byte stream is dropped.

Two things worth saying out loud about this file:

Validate before you apply it. visudo -cf /etc/sudoers.d/iolog-exemptions parses the file without installing it. A syntax error in sudoers.d can lock you out of sudo on a machine you may only reach through sudo. Keep a timestamped backup next to it.

The paths matter more than the commands. Exempting /usr/bin/cat outright would let anyone pipe any file past the audit log. Exempting cat restricted to the backup directory keeps the hole the size of the actual problem.

What ten days later looks like

I applied the exemptions across all four hosts on September 14 and measured again today, September 24.

At 654 MB/week, chatwoot should have been near 6.8 GB by now. It reads 5.48 GB. The curve turned over. Two things are doing that work together. New writes stopped, and the 60-day retention cron keeps deleting old sessions, so I'd expect the number to keep falling into mid-October as the pre-fix backlog ages out. I'm not claiming the exemption alone recovered 1.3 GB. I'm claiming the growth stopped, and that's the part I was chasing.

The part I'd actually change

The exemption fixed one symptom. The real defect is that five of ten hosts don't record sudo I/O, two of the four that do had drifted apart, and I only noticed because a disk filled up. A config that exists on some machines and not others isn't a policy, it's a habit that happened to repeat.

So the check I added isn't "is the log too big." It's this, run across the fleet:

# does this host record sudo I/O at all, and is the exemption file present?
grep -rl log_output /etc/sudoers /etc/sudoers.d/ 2>/dev/null | head -1
test -f /etc/sudoers.d/iolog-exemptions && echo "exemptions: yes" || echo "exemptions: MISSING"

Two lines, and it answers the question the disk alert was too late to ask. This is the same reasoning behind most of the fleet automation I build at achiya-automation.com — the alert that fires when a threshold breaks is always a worse version of the check that confirms a configuration is still what you think it is.

The metric to steal

If you have log_output enabled anywhere, don't look at total size and don't look at session count. Look at bytes per session:

sudo bash -c 'kb=$(du -sk /var/log/sudo-io | cut -f1); \
  n=$(find /var/log/sudo-io -name log -type f | wc -l); \
  echo "$((kb / (n>0?n:1))) KB per session across $n sessions"'

Across my fleet the number is 114 KB. Anything in that range is ordinary admin work. A host sitting at 350+ has a command streaming a file through sudo, and you can find it in one pass. A host at 43 is doing plenty of work and costing you nothing.

A question for anyone running log_output in production: what's your bytes-per-session number, and did the outlier turn out to be a backup job like mine, or something you'd never have guessed? I'm especially curious whether anyone exempts by path the way I did here, or whether you found a cleaner pattern than hand-maintained Cmnd_Alias blocks that drift between hosts.