6 Dependabot alerts deliberately left open — what each one is waiting on

[radroid]

Tracking issue from the 2026-08-08 Dependabot cleanup (#52, #56, #57), which took the repo from 107 open alerts to 6. Each of the six was left open on purpose. Recording why, so none of them gets re-triaged from scratch or quietly dismissed.

Grouped by what would actually unblock them.

Nothing to bump — the fix does not exist

• image-size@1.2.1 — two high alerts, both with vulnerable range <= 2.0.2 and no patched version published. There is nothing to upgrade to. Re-check periodically; if a fix never lands, the question becomes whether whatever pulls it in can be dropped.

Waiting on a dependency this repo does not control

• @vitest/browser@4.1.9 → 4.1.10 (critical, dev-scoped). 4.1.10 declares an exact peer, "vitest": "4.1.10", so it cannot move alone — it drags @vitest/{expect,mocker,runner,snapshot,spy,utils,pretty-format} with it, and vitest here is supplied by vite-plus@0.2.2, which pins the family at 4.1.9. Bumping the test runner out from under the fork's only CI gate is not worth it for an advisory in Vitest Browser Mode, which no vite.config.ts in this repo configures. Unblocked by: the next vite-plus bump. Check this alert at that point.

• @hono/node-server@1.19.14 → 2.0.5 (medium, runtime). No 1.x fix exists. It arrives via @modelcontextprotocol/sdk@1.29.0, which declares "@hono/node-server": "^1.19.9". SDK 1.30.0 widens that to "^1.19.9 || ^2.0.5", and @anthropic-ai/claude-agent-sdk@0.3.170 already asks for ^1.29.0 — so 1.30.0 is inside the range its own dependant wants, and this looks like a two-line fix. It is not: the SDK is an auto-installed peer, so an overrides: entry rewrites the declared peer range and leaves the resolved instance at 1.29.0, and pnpm update --depth Infinity is a no-op because no workspace manifest declares the SDK. Landing it needs a full --force lockfile re-resolution. Attempted and reverted. Unblocked by: upstream bumping @anthropic-ai/claude-agent-sdk, or a sync that re-resolves the lockfile wholesale.

Deferred on risk, fixable any time we want to pay for it

• sharp@0.34.5 → 0.35.0 (high). A minor bump in 0.x is a breaking change by semver, and sharp is a native package with prebuilt binaries and an allowBuilds: true entry. Forcing it via overrides: risks the desktop build. Wants its own PR with a real desktop build behind it, not a lockfile edit.

• uuid@7.0.3 → 11.1.1 (medium). Four majors. It arrives on a path pnpm already flags as deprecated, so the honest fix is removing whatever still depends on uuid@7, not forcing 11 underneath a caller written against 7.

---

Reproduce the current list with:

gh api repos/radroid/t3code/dependabot/alerts --paginate \
 -q '.[] | select(.state=="open") | "\(.number) \(.security_advisory.severity) \(.dependency.package.name)"'

Note when checking these by hand: pnpm-lock.yaml single-quotes scoped package keys ( '@vitest/browser@4.1.9':), so a ^ @scope/name@ grep matches nothing and looks like the package is absent. That mistake is why the first pass on the two scoped alerts above was wrong.

The 41 alerts against .repos/** are dismissed as not_used and suppressed by .github/dependabot.yml — vendored subtrees, not code this fork builds. See the seam ledger rows 36 and 37 in docs/t3x/SEAMS.md for the pins that are now fork-owned.

[radroid]

Re-checked 2026-08-11 — one of the six has moved, and it is the critical one

All six are still open, same numbers, same packages. Only the @vitest/browser entry has changed status.

@vitest/browser — the fix now exists; the blocker is now purely the toolchain bump

This issue recorded it as "unblocked by: the next vite-plus bump. Check this alert at that point." That bump is now available:

	vitest family
vite-plus@0.2.2 (our catalog pin, and upstream's)	4.1.9
vite-plus@0.2.8 (latest on npm)	4.1.10 — including @vitest/browser: 4.1.10

4.1.10 is exactly the patched version the alert names, and vite-plus now carries the whole family at it, so the exact-peer problem this issue describes resolves by itself at the bump rather than needing to be worked around.

Upstream has not taken it. Checked upstream/main at 9c7622dac (15 commits past our merge-base 78f462c4e): pnpm-workspace.yaml still reads vite-plus: 0.2.2 and vite: npm:@voidzero-dev/vite-plus-core@0.2.2. So nothing has changed in our tree — the difference is that the fix has gone from "does not exist for us" to "exists, six patch releases ahead, waiting on whoever bumps the toolchain".

I did not bump it, deliberately. It is a root pnpm-workspace.yaml catalog edit to the version of the fork's only CI gate, upstream owns that pin and will move it themselves, and a fork edit there conflicts on every sync that touches it. Worth doing as its own PR with a full green run behind it if upstream stays on 0.2.2 for a while — but not as a lockfile change.

The other five, unchanged

• image-size (2 × high) — 2.0.2 is still the latest published version and the advisory range is still <= 2.0.2. Still nothing to upgrade to.
• @hono/node-server (medium) — @anthropic-ai/claude-agent-sdk is now at 0.3.227 on npm, but its @modelcontextprotocol/sdk peer is still ^1.29.0, so the range was never the obstacle and nothing has changed: 1.30.0 was always inside it, and reaching it still needs the wholesale --force re-resolution this issue already describes as attempted and reverted. Both our range and upstream's are still ^0.3.170.
• sharp (high) — unchanged; still wants its own PR with a real desktop build behind it.
• uuid (medium) — unchanged.

Reproduced with the command in the issue body; it still works as written.

[radroid]

Re-checked 2026-08-11 (second pass) — two of the six were never blocked. PR #87.

The 2026-08-11 morning re-check moved @vitest/browser from "no fix exists" to "fix exists, waiting on the toolchain". Going back over the other five with the actual dependency edges rather than the advisory metadata, two of them were not blocked at all — the reasoning recorded in this issue was wrong about each in a specific, checkable way. Both are fixed in #87 with a lockfile re-resolution: no manifest, no catalog, no overrides: entry, zero collateral version changes.

✅ sharp 0.34.5 → 0.35.3 (high) — fixed

This issue filed it under "deferred on risk": 0.x minor is breaking by semver, native package, allowBuilds: true, "forcing it via overrides: risks the desktop build", wants "its own PR with a real desktop build behind it".

Two things wrong with that:

1. It is not the desktop app's dependency. The only sharp edge in the whole lockfile is astro@7.2.0's. The desktop build never sees it, so there is no desktop build to put behind the PR.
2. It is not an override. astro@7.2.0 declares sharp: "^0.34.0 || ^0.35.0". 0.35.x is already inside the range astro asks for — astro itself blesses it. Nothing is being forced; the lock was just holding a stale resolution.

And it is not even reachable: neither apps/coil-home nor apps/marketing uses astro:assets / <Image>. Every image is a static file in public/, copied verbatim. sharp is installed as astro's optional image-service dep and never invoked. Verified anyway that 0.35.3 / libvips 8.18.3 loads and encodes natively, and that both sites build.

✅ @hono/node-server 1.19.14 → 2.1.0 (medium) — fixed

This issue had the diagnosis exactly right — auto-installed peer, pnpm update is a no-op, overrides: rewrites the range but not the resolution — and I re-confirmed both dead ends on pnpm 11.10.0. Where it went wrong was the conclusion: "Landing it needs a full --force lockfile re-resolution", hence "unblocked by upstream bumping @anthropic-ai/claude-agent-sdk, or a sync that re-resolves the lockfile wholesale".

There is a narrower route. Delete the package's own top-level blocks from pnpm-lock.yaml, then pnpm install --lockfile-only. That forces a fresh resolution of just that subtree instead of floating everything:

@modelcontextprotocol/sdk 1.29.0 → 1.30.0
@hono/node-server 1.19.14 → 2.1.0

1.30.0 is inside claude-agent-sdk's ^1.29.0 peer, and 1.30.0 is the release that widens its own dependency to ^1.19.9 || ^2.0.5. So no range was ever the obstacle — this issue was right about that too. The obstacle was only that --lockfile-only preserves a satisfying resolution rather than floating to the newest, which is the same mechanic behind the 6 → 27 regression noted in #52/#63.

Also worth recording: waiting on the agent SDK would not have helped. @anthropic-ai/claude-agent-sdk is now at 0.3.228 and its @modelcontextprotocol/sdk peer is still ^1.29.0.

⛔ image-size ×2 (high) — genuinely blocked, and the blocker is not upstream either

Still nothing to upgrade to: 2.0.2 remains the latest published version (unchanged since 2025-04-02) and the advisory range is still <= 2.0.2.

New detail: the consumer is metro@0.84.4 (the React Native bundler), and metro@0.87.0 — the latest — still declares image-size: ^1.0.2. So bumping metro would not clear it either. The blocker is the image-size maintainer publishing a fix, full stop.

Both advisories (GHSA-w3rx-r6r6-pgpr, GHSA-5p2g-fcmc-qvqq) are infinite-loop DoS in the ICNS / JXL / HEIF parsers. Metro calls it at bundle time to size our own repo assets, so there is no attacker-controlled input on this path.

⛔ uuid 7.0.3 (medium) — genuinely blocked, on Expo

This issue said the honest fix is "removing whatever still depends on uuid@7". Naming it: the dependant is xcode@3.0.1, reached through Expo's iOS prebuild tooling. 3.0.1 is the latest release of that package and it still declares uuid: ^7.0.3. Dev-time only. Nothing to remove and nothing to bump — Expo has to move first.

⏸ @vitest/browser (critical) — fixable by us, still deliberately deferred

Unchanged from this morning's comment, plus two data points that make "wait for upstream" look worse than it read then:

• Upstream has no automated dependency updates at all — no Renovate, no Dependabot config in pingdotgg/t3code. vite-plus moves only when someone opens a PR by hand (Migrate tests to vite-plus test APIs pingdotgg/t3code#2964 on 2026-06-05, Upgrade Vite Plus and enable bundled dev opt-in pingdotgg/t3code#3679 on 2026-07-03). There is no open PR for a newer one.
• They have now skipped 7 releases across ~6 weeks. vite-plus is at 0.2.9; upstream pinned 0.2.2 on 2026-07-03.

So this is not a wait with a scheduled end. Still deferring, for the reason this issue already gave plus one more: the bump is not just the test runner. 0.2.2 → 0.2.9 drags oxfmt 0.57.0 → 0.62.0 (may reformat the repo), oxlint 1.72.0 → 1.77.0 (new rules), oxlint-tsgolint 0.24.0 → 7.0.2001, and @oxlint/plugins 1.68.0 → 1.73.0 — and this repo ships its own oxlint-plugin-t3code. That is a format + lint + typecheck-lint + test-runner change to the fork's only CI gate, and it deserves its own PR with a full green run.

Meanwhile the exposure is nominal. GHSA-p63j-vcc4-9vmv requires Browser Mode to be running with its API reachable. No vite.config.ts in this repo configures browser:, and nothing imports @vitest/browser — the vulnerable code is installed but never executed.

---

Where that leaves it

Alert	Verdict
sharp (high)	Fixed in #87 — was never blocked
@hono/node-server (medium)	Fixed in #87 — was never blocked
image-size ×2 (high)	Blocked on the image-size maintainer; no reachable input
uuid (medium)	Blocked on Expo (xcode@3.0.1 is latest)
@vitest/browser (critical)	Ours to take whenever we pay for a toolchain bump; not reachable today

6 → 4 open, and only 2 of the 4 are actually waiting on someone else.

One new hazard for sync time

None of the three re-resolutions has an overrides: entry — the lock alone carries them. The overrides: block is what carried the 2026-08-08 sweep across a sync; these are not in it. Regenerate the lock from upstream's side and they revert silently, exactly the 6 → 27 way. Seed from the fork's pre-sync lock and diff the three resolved versions. Recorded in docs/t3x/SEAMS.md alongside the re-resolution technique.