Every deploy this week logged 'wrangler CLI not found' before quietly succeeding via npx. Understand what npx actually does, then kill the daily noise on purpose.
The plan-day deploy leg probes for wrangler, logs a failure line, then falls back to `npx wrangler` — every single morning. A log line that always cries wolf trains you to skim past the morning log, which is the same alarm-fatigue mechanism as the 8/20 false-green lesson, applied to your own eyes.
npm installs packages; npx RUNS them. `npx wrangler pages deploy` checks a per-user cache (~/.npm/_npx), downloads the wrangler package if it's missing or stale, and executes its binary — no permanent install. It's brilliant for one-offs and terrible as invisible infrastructure: it adds seconds and a network dependency to a scheduled job, and version drift happens whenever the cache refreshes.
A global install (`npm install -g wrangler`) puts the binary on PATH permanently: fast, offline-safe, but now YOU own updating it — and LaunchAgents only find it if their minimal PATH includes npm's global bin directory (the interpreter lesson from Monday, in JavaScript clothing).
The third option is a devDependency pinned in PDB/output's package.json: the version is committed, reproducible, and `npx` resolves it locally without any network. For a repo that deploys itself daily, pinning is the grown-up answer. Whichever you pick, the real bug is the probe: a fallback that fires 100% of the time is not a fallback — it's the primary path wearing a failure costume.
Look at what the deploy leg actually does, then time the npx tax.
grep -n -B2 -A6 "wrangler" /Users/tom/Claude/PDB/scripts/run_plan_day.sh | head -30
time npx wrangler --version
time npx wrangler --versionA fallback that fires every time is your primary path — name it, pin it, and stop logging it as failure.