Dev-only esbuild advisory (GHSA-g7r4-m6w7-qqqr) keeps npm audit non-clean in web/cli/tui #2062

npm audit (dev included) reports a low severity advisory against esbuild in three of the four client installs. It is not in the production tree — npm audit --omit=dev is clean everywhere after #2058 — so this is the last thing standing between us and a clean plain npm audit.

esbuild  0.27.3 - 0.28.0   severity=low
GHSA-g7r4-m6w7-qqqr — esbuild allows arbitrary file read when running
                       the development server on Windows

Split out of #2058, which deliberately scoped itself to the production tree (--omit=dev) and left this alone rather than widening a one-line security bump.

Where it is

Four copies, and they do not all have the same fix:

Why it needs an overrides, and the trap to avoid

The advisory range is 0.27.3 - 0.28.0, and esbuild@0.27.7 is the latest 0.27.x. So within tsup's declared ^0.27.0 there is no version above the range — the only in-range escape is downward, to 0.27.2.

⚠️ That is exactly what npm audit fix does, and it is a trap: it silently downgrades esbuild 0.27.7 → 0.27.2 across web/cli/tui. This was hit and reverted during #2058 (~700 lines of lockfile churn for a low-severity dev advisory). Do not reach for npm audit fix here.

The three tsup copies therefore need an overrides forcing esbuild above tsup's declared range:

"overrides": { "esbuild": "^0.28.2" }

clients/tui/package.json already carries an overrides block (for ink-select-input@6), so there is precedent for the mechanism.

The tsx copy needs none — a plain npm update esbuild in clients/tui moves it 0.28.0 → 0.28.2.

Reachability is nil, which is why this is Low and not urgent

The advisory is against esbuild's development server (esbuild --serve / the serve() API), on Windows only. Nothing here runs it:

• tsup and tsx use esbuild as a bundler/transformer, never its serve mode.
• The web dev server is Vite's, not esbuild's.
• It is dev-only regardless — it does not ship in the published tarball.

So this is hygiene, not an incident. The argument for doing it is the same one made in #2058: a permanently non-clean npm audit trains people to skim the channel, and the real finding added later lands where everyone has learned to look past.

Scope

• Add the overrides to clients/{web,cli,tui}/package.json and re-resolve; npm update esbuild in clients/tui for the tsx copy.
• Confirm the override doesn't break the bundlers — this forces tsup onto an esbuild major it does not declare support for, so npm run build for web/cli/tui is the real gate here, not just the audit. If tsup turns out to be incompatible with esbuild 0.28.x, close this as "wait for a tsup release that widens its range" rather than downgrading to 0.27.2.
• Verify plain npm audit is clean in all five installs, and that npm audit --omit=dev stays clean.
• Confirm no unrelated lockfile churn (the High-severity nanoid advisory in the production tree (via vite → postcss), on both branches #2058 lesson).
• npm run ci.