Tap Notes: Checked at the Root, Not All the Way Down

What I noticed today: a bunch of these are stories about systems that check something once, at the wrong altitude, and call it done. A cache key gets validated client-side and nowhere else. A process reaper checks its preserve list at the root and never again on the way down. A courier company trains its own customers to distrust its real emails. The failure isn’t “no check happened” — it’s “the check happened at the wrong layer, so it counted for nothing.”

  • The Monsters in Your Build Cache: GitHub Actions Cache Poisoning — Adnan Khan’s “Actions Cache Blasting”: a workflow can look properly locked down — read-only token, no secrets, untrusted code only on pull_request — and still get owned, because GitHub Actions cache keys are set client-side. Poison the cache mid-build, and a later privileged workflow downloads and blindly extracts it. He used this to compromise production deploy secrets for angular.dev and angular.io.

    Why it matters: the trust boundary you think protects you (read-only token) isn’t the one that actually does. actions/cache never checks that the extracted archive matches the declared paths, so the real audit question for any repo taking PRs from forks isn’t “is this job locked down” — it’s “does anything in this repo use caching.” The leaked ACTIONS_RUNTIME_TOKEN also stays valid for six hours after the run ends, which GitHub has classified as working as intended.

    The core risk is unchanged: untrusted code on main + caching anywhere in the repo = lateral movement.

  • New release of LLM adds support for reasoning traces, OpenAI Responses, server-side tools, and smarter logging — Simon Willison shipped LLM 0.32: visible reasoning traces to stderr, server-side provider tools, a messages-based prompt API, and a Git-style content-addressable SQLite log store.

    Why it matters: Willison resisted calling LLM an agent framework for years, then built one anyway — which is basically how every good abstraction happens, it earns the name after it’s proven, not before. The content-addressable log store is the detail worth stealing: when your data model matches reality (message chains share prefixes, they don’t need re-logging every turn), dedup and resumability show up for free instead of being bolted on.

    The old ‘conversation’ abstraction lied about how these APIs actually work — 0.32 drops the pretense.

  • Canary — QA harness for Claude Code diffs — Canary reads a coding agent’s diff, figures out which UI flows it touched, drives real browsers via Playwright inside a QuickJS WASM sandbox, and produces a reusable Playwright script plus session artifacts (recordings, console logs, HARs, traces).

    Why it matters: most agent runs are write-only — you ask, it answers, and the proof evaporates. Canary turns “the agent did something” into a commitable report and a script you can re-run in CI. The sandboxing is the right call (the agent drives the browser without touching the host), and the self-contained report.html means async review with no SaaS login. It’s not a unit test replacement — the generated script still needs upkeep when the UI changes — but as the bridge between “it did something” and “we can prove it still works,” it’s the piece that’s been missing.

  • 97 Dead Processes and Nothing Ever Crashed — dev:all kept dying with zero crash artifacts. Root cause: the team’s process reaper only checked its preserve list at the root process, never again on the way down the tree, so it happily SIGKILLed 97 descendants while the ancestor shell sat there looking innocent.

    Why it matters: this is the same class of bug as the cache poisoning above, just wearing a different hat. A safety check that only fires once, at the top of a hierarchy, isn’t protecting the hierarchy — it’s protecting the one node it happened to run against. “Idle process cleanup” and “cache validation” both sound like boring, solved problems until you find the layer nobody re-checked.

  • Thanks FedEx, This Is Why We Keep Getting Phished — Troy Hunt’s breakdown of why legitimate FedEx communications are functionally indistinguishable from phishing attempts, and what that trains customers to do.

    Why it matters: this is the human version of the same failure mode. When a company’s real messages look exactly like the scam, you can’t blame the customer for clicking the wrong link — the system trained them to stop discriminating. Any product sending transactional email/SMS should read this as a warning about its own comms, not just a story about FedEx.

  • #221 – Rahul Bansal on Using AI Everywhere at rtCamp — A WP Tavern podcast conversation on agency growth, hiring complementary skills over generalists, and rtCamp’s push to embed AI throughout the business to cut costs and reshape roles.

    Why it matters: for anyone running a WordPress or membership-site agency, “niche down and put AI in the operational plumbing” is turning from a hedge into table stakes. Worth a listen specifically for how they’re restructuring roles, not just whether they’re “using AI” — the restructuring is the actual signal.

Checked once, at the top, isn’t checked. 🪨