chore(deps-dev): bump @types/node from 25.9.3 to 26.0.0

[dependabot]

Bumps @types/node from 25.9.3 to 26.0.0.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 28, 2026, 4:08 PM ET / 20:08 UTC.

Summary
The PR bumps the direct dev dependency @types/node to ^26.0.0 and refreshes pnpm-lock.yaml, including undici-types, nanoid, and peer snapshot entries.

Reproducibility: not applicable. this is a dependency-maintenance PR rather than a reported bug. The relevant check is package policy and type-baseline compatibility, not reproducing a runtime failure.

Review metrics: 3 noteworthy metrics.

• Changed package files: 2 modified, 0 added, 0 removed. The review surface is limited to package.json and pnpm-lock.yaml.
• Dependency surface: 1 direct dev dependency, 2 transitive versions, peer snapshots refreshed. The lockfile also moves undici-types and nanoid, which is the dependency surface maintainers should sanity-check.
• Visible PR checks: 11 passed, 1 skipped dispatch. CI is a useful patch-quality signal, but it does not settle the Node type-baseline policy decision.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Have a package owner confirm whether @types/node 26 is the intended development type baseline while Node 22/24 remain supported.

Risk before merge

• [P1] Merging would move the normal compile-time Node API surface to Node 26 declarations while the package still advertises Node 22 and Node 24 runtime support.
• [P1] The passing CI matrix verifies current code under Node 22/24, but it does not decide whether future changes should be allowed to typecheck against Node 26-only declarations.

Maintainer options:

1. Accept the type baseline
   Merge after a package owner confirms that Node 26 ambient declarations are acceptable for a package whose runtime contract still includes Node 22 and Node 24.
2. Hold the major update
   Close this PR or configure Dependabot to ignore this @types/node major until the supported runtime or type-policy baseline moves forward.

Next step before merge

• [P2] A maintainer or package owner needs to decide the Node type-declaration baseline; there is no narrow automation repair for that policy choice.

Security
Cleared: The diff changes only dev dependency metadata and integrity-pinned lockfile entries, with no scripts, workflows, permissions, secrets, or publish settings changed.

Review details

Best possible solution:

Merge the narrow bump only if package owners accept @types/node 26 as the development type baseline; otherwise close or configure Dependabot to hold this major until the runtime/type policy moves.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a dependency-maintenance PR rather than a reported bug. The relevant check is package policy and type-baseline compatibility, not reproducing a runtime failure.

Is this the best way to solve the issue?

Yes, with maintainer acceptance: the branch uses the normal package.json plus pnpm-lock.yaml path for a dev dependency update. The unresolved part is whether this semver-major Node types baseline belongs in the package now.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 8ffb44049333.

Label changes

Label justifications:

• P3: This is a narrow dev-dependency maintenance PR with limited direct runtime blast radius.
• merge-risk: 🚨 compatibility: The semver-major Node type declarations can move the compile-time API guard ahead of the package's Node 22/24 runtime contract.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This is a bot-authored Dependabot dependency PR, so the external-contributor real behavior proof gate does not apply; CI is the relevant validation signal.

Evidence reviewed

Acceptance criteria:

• [P1] Review the existing PR CI results for the Node 22/24 pnpm check matrix.
• [P1] If maintainers choose to merge locally, run pnpm check with the repository-declared pnpm version.

What I checked:

• Repository policy read: AGENTS.md was read fully; its runtime, package-surface, compatibility, and pnpm workflow guidance applies to this dependency PR. (AGENTS.md:1, 8ffb44049333)
• Current main dependency baseline: Current main still declares @types/node as ^25.9.2, so the PR's central change is not already implemented on main. (package.json:91, 8ffb44049333)
• Current runtime contract: The package engines still support Node ^22.18.0 || >=24.11.0, which is why moving the ambient Node types to major 26 is compatibility-sensitive. (package.json:110, 8ffb44049333)
• PR dependency diff: The PR changes package.json to @types/node ^26.0.0 and updates the lockfile to @types/node 26.0.0, undici-types 8.3.0, and nanoid 3.3.15. (package.json:91, aa31cecebeed)
• Node types affect normal typecheck: The main TypeScript config includes node in compilerOptions.types, so this dev dependency controls the Node API surface accepted by the normal typecheck path. (tsconfig.json:14, 8ffb44049333)
• Portable typecheck guard: The portable config clears compilerOptions.types, preserving a Node-free check path for browser and worker entry points even if the main Node types move. (tsconfig.portable.json:4, 8ffb44049333)

Likely related people:

• Vincent Koc: Blame and log history tie the current dependency block, TypeScript config, and recent release-validation package script changes to this area. (role: package surface introducer and recent area contributor; confidence: high; commits: af898fe0cdd3, c1ca6f199108; files: package.json, pnpm-lock.yaml, tsconfig.json)
• @openclaw/openclaw-secops: CODEOWNERS assigns package.json, pnpm-lock.yaml, protocol, source, and governance files to this team under package and compatibility surface ownership. (role: code owner for package and compatibility surfaces; confidence: high; commits: af898fe0cdd3; files: .github/CODEOWNERS, package.json, pnpm-lock.yaml)
• dependabot[bot]: Recent merged dependency-maintenance commits touched the same package and lockfile area, so this branch follows the established automated dependency-update path. (role: recent dependency automation; confidence: medium; commits: ed9ce515e4a2, 1793e5398cb7; files: package.json, pnpm-lock.yaml)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[dependabot]

Superseded by #20.