[joelgallardoclippy-lgtm]

What

Bumps puppeteer / puppeteer-core from 25.11.0 to 25.13.0, so chromium-bidi (and the zod copy under it) moves to a patched line in bun.lock and in both Lambda runtime locks.

Package	Before	After
puppeteer, puppeteer-core	25.11.0	25.13.0
chromium-bidi	17.0.2	157.0.8090-0
zod (under chromium-bidi)	3.25.76	4.6.7
@puppeteer/browsers	3.2.2	3.2.4
devtools-protocol	0.0.1680125	0.0.1696802
webdriver-bidi-protocol	0.4.3	1.0.1

bun.lock also picks up typed-query-selector 2.12.3 and modern-tar 0.8.6. Both are required by the new puppeteer line.

Why

GHSA-mrhx-c7xc-m3w5 (high): zod < 4.6.6 can run out of memory while it validates oversized constrained collections. The first patched version is 4.6.6.

chromium-bidi 17.x pins zod ^3.24.1, so no zod 3 release clears the advisory. Puppeteer 25.13.0 is the first release whose chromium-bidi (157.0.8090-0) depends on zod ^4.6.5. This clears Dependabot alerts for zod in:

• packages/aws-lambda/scripts/runtime-lock/sparticuz/package-lock.json
• packages/aws-lambda/scripts/runtime-lock/chrome-headless-shell/package-lock.json

Related work

No open Renovate PR covers this. Renovate is disabled for runtime-lock/**, and lock maintenance cannot cross the ~25.11.0 pin. The zod 4.4.3 copies used by @modelcontextprotocol/* and knip are out of scope here.

How

• Puppeteer pin. The engine and producer pin moves from ~25.11.0 to ~25.13.0 (puppeteer-core ^25.13.0). It stays a single minor line. The workspace still resolves one puppeteer-core (25.13.0) and one @puppeteer/browsers (3.2.4), which the CLI's ^3.2.2 range shares. This keeps the single-launcher setup from fix(engine): a render on Windows opens no console windows #6613. The other workspaces' ^25.x ranges resolve to the same 25.13.0.
• Not latest. I chose 25.13.0 because it is the lowest release that clears the advisory; 25.17.0 is 3 days old. Workspace version churn from bun install is left out, and bun install --frozen-lockfile accepts the lock.
• Runtime locks. lock-runtime.ts writes the same direct pins (puppeteer-core 25.13.0, @sparticuz/chromium 148.0.0). It deletes and re-resolves the whole lock, though, and that pulled in unrelated transitives published less than a day ago (ws 8.23.0, bare-*). Instead, I updated each lock in place with npm install --package-lock-only --ignore-scripts, starting from the new package.json. Only the puppeteer subtree changes, and every other resolution stays as reviewed.
• Why not an overrides entry. Overriding zod to 4.x under chromium-bidi 17 would force a major version outside its declared ^3.24.1 range. lock-runtime.ts also regenerates these package.json files, so the override would be dropped.

Release age (7-day window; every newly resolved version qualifies):

Version	Published
zod 4.6.6 (fix release)	2026-10-11
zod 4.6.7 (resolved)	2026-10-12
puppeteer / puppeteer-core 25.13.0	2026-10-08
@puppeteer/browsers 3.2.4	2026-10-08
chromium-bidi 157.0.8090-0	2026-10-07
devtools-protocol 0.0.1696802	2026-09-12
webdriver-bidi-protocol 1.0.1	2026-09-14
typed-query-selector 2.12.3	2026-09-29
modern-tar 0.8.6	2026-10-14

Test plan

• bun install --frozen-lockfile accepts the lock. bun.lock has a single puppeteer-core@25.13.0 and chromium-bidi/zod@4.6.7.
• npm ci --ignore-scripts in a clean copy of each runtime lock. npm ls shows puppeteer-core@25.13.0 > chromium-bidi@157.0.8090-0 > zod@4.6.7.
• On each runtime lock install, chromium-bidi's zod-backed protocol parser accepts a valid browsingContext.navigate payload and rejects an invalid one, and puppeteer-core loads.
• bun test packages/aws-lambda/scripts/runtimeLock.test.ts (direct pins match bun.lock).
• bun run build; engine and producer typecheck; oxfmt check on changed files.
• Hosted CI, including the Windows render and test jobs.

🤖 Generated with Claude Code

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 78 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

Unstable (1)

• seqplainkeys-none-pct-r0-nested-z100: tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true

[jrusso1020]

Reviewed at 26971d656834e0b76e24d4141543bc8a6a05a221. No blockers found.

The workspace and both Lambda runtime manifests/locks agree on puppeteer-core 25.13.0. Parsed lock comparison shows only the Puppeteer subtree changes; the unchanged Lambda resolutions remain byte-for-byte equal as JSON values. There are intentional transitive major moves: chromium-bidi 17→157, webdriver-bidi-protocol 0→1, and nested zod 3→4. They follow the new Puppeteer dependency declarations rather than forcing a Zod override across an incompatible range. The renderer continues using CDP; the upstream launcher/CDP delta preserves its existing options. Lambda's explicit Chromium 148 remains unchanged; I did not run a Lambda render.

Validation: frozen install and full build pass; runtimeLock.test.ts 3/3 and focused browser-manager/pool tests 132/132 pass. Both isolated runtime-lock npm ci --ignore-scripts installs pass. Each installed BiDi parser accepts a valid navigate payload and rejects an invalid one; each installed Puppeteer launches cached Chrome 153 and passes DOM, PNG screenshot and CDP checks. The first probe against the obsolete system Chrome 113 timed out; no Lambda Chromium 148 execution was performed. Changed manifests pass formatting. Hosted checks at this head: 94 successful, 9 skipped, 0 pending, 0 failed. Upstream release.

Need: yes, patched BiDi/Zod dependency chain · Size: ok · Reuse: existing runtime lock generator and consistency guard · Simpler: already minimal · Structure: fine (checked shared browser manager and runtime lock staging; no split)
Risk: medium — runtime browser dependency update, including upstream transitive major changes.

Verdict: APPROVE
Reasoning: The dependency and runtime lock contracts remain consistent and no compatibility blocker was found.

— Rames