[t3dotgg]

Releases kept failing or hanging this morning on two network calls the Blacksmith runners make on every run:

• npm registry: pnpm's lockfile policy check fetches metadata for all 2,054 packages, even when the store cache hits. One request took 452s in preflight, and a full CI install took 17m 25s.
• nodejs.org: Windows CLI builds download the target Node.js zip. win-arm64 stalled for 20+ minutes in one release and failed in two others. In a probe, it stalled 12 times in a row.

nodejs.org and npm are not down. Their status pages are green, and the same downloads are instant from outside Blacksmith. A probe from a Blacksmith runner (run 40654192811) showed some connections to Cloudflare IAD dropping to about 11 KB/s while others finished in 0.1s.

Both inputs only change when the lockfile or engines.node changes, so this caches them and stops making the calls.

pnpm lockfile check (setup-ci-deps)

• Caches pnpm's lockfile-verified.jsonl, keyed on the lockfile, workspace config, and package.json.
• pnpm 12 accepts an earlier pass for the same lockfile and policy at any age. I tested this locally with a record 365 days old and a different checkout path. A changed lockfile or policy still runs a full check.
• pnpm_config_cache_dir defaults to $RUNNER_TEMP/pnpm-metadata when the caller does not set it, so every job uses the same path.

Windows target Node.js (release-desktop.yml)

• The zip and SHASUMS256.txt are cached per Node version and architecture. The cache is saved right after the checksum passes, so a later failure keeps the download.
• The checksum is checked again on every run before tsdown's cache is seeded.
• curl now treats under 100 KB/s for 30s as a failure and retries. Before, a stalled transfer could hang until the job's 70-minute timeout.

Proof (throwaway probe workflows, since deleted):

• Lockfile check, cold: each job verified once and saved the record. Warm: all four jobs (Linux x64 and macOS) restored it and reported "verified 18m ago", with no registry calls.
• win-arm64, cold: one stall was cut at 30s, and the retry succeeded. The checksum passed, the cache saved, and tsdown printed "Using cached Node.js 26.12.1 for win-arm64".
• win-x64, warm: restored from cache with no download, and tsdown used the cached copy.
• actionlint shows no new findings. vp run check:changed passes.

Note: the first release after merge still downloads win-arm64 once, with the stall retry. After that, releases do not contact nodejs.org.

Created with Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 46da72a

Macroscope's review found this PR approvable — This reduces repeated registry and Node.js downloads through input-keyed caches and faster stall retries. Node checksum verification remains in place, and reported cold/warm probes support the intended behavior without changing product defaults.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Walkthrough

The CI dependency action now caches lockfile-verification data around installation. The Windows desktop release workflow now caches Node.js archives, verifies downloads on cache misses, and extracts node.exe into tsdown’s cache.

Changes: CI lockfile-verification cache

Layer / File(s)	Summary
Lockfile-verification cache flow .github/actions/setup-ci-deps/action.yml	The action sets the verification file path, restores cached data before installation, and saves it after installation when no matching cache was restored.

Windows Node.js archive cache

Layer / File(s)	Summary
Windows Node.js download and extraction .github/workflows/release-desktop.yml	The workflow resolves the Node.js version and restores a download cache by version and architecture. On a cache miss, it downloads and verifies the archive, saves the cache, and extracts node.exe into tsdown’s cache.

Priority: Low

Estimated code review effort: 2 (Simple) | ~12 minutes

Change: Bug fix

Possibly related PRs

• pingdotgg/t3code#26305: Changes the same dependency action and release workflows with pnpm store reuse and filtered-install inputs.

Suggested reviewers: juliusmarminge, macroscopeapp

Merge Risk: Minimal · up to 46da7

This change caches pnpm lockfile verification data and the Windows Node.js download so releases contact npm and nodejs.org less often. When a cache is not available, the release falls back to the earlier download behavior with retries added. No merge-blocking risk was identified.

Pre-merge checks: 3 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Description check		The description provides detailed problem, change, verification, observed results, and agent attribution. It does not provide the required Scope and approval information or link to a triaged issue, ma…	Add a Scope and approval section. Include the triaged issue or maintainer approval with an approval comment. If this change qualifies as an obvious focused fix or established-capability configuration, explain why and how its scope remains l…

Passed checks: 3 passed

Check name	Status	Explanation
Title check		The title clearly summarizes the main change: releases reuse cached pnpm verification data and Node.js downloads instead of contacting npm or nodejs.org when inputs are unchanged.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description provides detailed problem, change, verification, observed results, and agent attribution. It does not provide the required Scope and approval information or link to a triaged issue, maintainer approval, or a valid exemption rationale.

Resolution

Add a Scope and approval section. Include the triaged issue or maintainer approval with an approval comment. If this change qualifies as an obvious focused fix or established-capability configuration, explain why and how its scope remains limited.

Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🔇 Additional comments: 1

.github/workflows/release-desktop.yml-295-295: 1

295-295: Major · Stability & Availability · Heavy lift

⚠️ Unverified finding
Verification ran but could not confirm this finding. It is shown for review, not as a verified issue.

Make the cache available across release tags.

release.yml supports tag-triggered stable releases. GitHub scopes a cache saved by one tag to that tag, so a later tag cannot restore it. If the default branch has no matching cache, each tag downloads Node.js again and can fail during a nodejs.org stall. (raw.githubusercontent.com)

Populate a shared trusted cache on the default branch, or use storage that is accessible across release tags.

---

Review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: t3/release-cache-lockfile-verification
• File: .coderabbit.config.ts
• Commit: 46da72a
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Team
• Run ID: a2a74123-ed60-4df3-bf32-62d61e5b75cb

Commits

Reviewing files that changed from the base of the PR and between 10e709c and 46da72a.

Files selected for processing: 2

• .github/actions/setup-ci-deps/action.yml
• .github/workflows/release-desktop.yml

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 5 remain after this review.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.3 KiB	1.3 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	21.6 KiB	21.6 KiB	0 B (0.0%)	24.4 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	5.1 KiB	5.1 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.3 KiB	1.3 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.9 KiB	21.9 KiB	0 B (0.0%)	24.4 KiB	✅
Claude	Live turn messages	2	2	0 (0.0%)	8	✅

Baseline: 10e709c · PR result: 46da72a · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[t3dotgg]

Note

🤖 Claude Opus 5.5 responding on behalf of Theo

Re CodeRabbit's unverified note on release-desktop.yml:295 (cache per release tag): not changing this. Tag runs can restore caches saved on the default branch. Nightlies (schedule) and dispatched releases run on main several times a day, and their Windows builds save node-download-v<version>-win-<arch> to main's scope. A tag-triggered stable release restores that entry. Only a tag-scoped save goes unshared, and that save is not needed. The pnpm verification record works the same way: CI on main writes it.