perf(ci): cut about a minute from every release

[rynfar]

Two pieces of every release run are pure waste: publish_cli builds the web client twice, and two startup jobs wait on version resolution they never read. This removes both, and fixes the two scheduling problems upstream found in the same audit.

Pylon's release workflow has diverged too far from upstream's to cherry-pick, so this is a manual port of pingdotgg/t3code#8250 (a3a8cbd60).

What changed

• publish_cli built the web client twice.@t3tools/web is a workspace dependency of t3, so vp run --filter t3 build already builds it. The explicit step repeated the work on the serial publish path. Verified locally: the command runs exactly two tasks (web, then server) and still produces dist/bin.mjs, dist/service-launcher.mjs, and dist/client/index.html.
• relay_public_config and build_wsl_node_pty now start alongside preflight. Both consume only the commit SHA, and Pylon's preflight.outputs.ref is literally ${{ github.sha }}, so the swap is exactly equivalent. They now share preflight's own check_changes condition. Desktop builds still hard-gate on needs.preflight.result == 'success' && needs.relay_public_config.result == 'success', so nothing builds off a failed preflight.
• Nightly cron moves to minute 7. GitHub delays scheduled runs most at the top of the hour; upstream measured a 13-minute median start delay across 56 sampled runs.
• Nightlies queue instead of cancelling. See below.

Why the concurrency policy flips

8dd0d6e06 set cancel-in-progress: ${{ github.event_name == 'schedule' }} after a Blacksmith capacity outage let 23 nightlies stack ~480 VM-hours deep waiting for runners that never arrived. That was the right fix at the time. 124630c3f then moved every workflow onto GitHub-hosted runners yesterday, and the concurrency block was never revisited — its comment still describes a failure mode that can no longer occur.

Cancelling is now the more dangerous half. publish_cli pushes to npm beforerelease creates the GitHub release, so a cancel in that window strands a published CLI version with no matching desktop build, and npm will not take that version number again. cancel-in-progress: false closes it, and queue: max keeps every pending run (100 FIFO slots per group) instead of the default newest-wins single slot, so the "losing a real release to a scheduling race" concern that motivated the run_id grouping is still covered — a queued stable tag waits rather than being dropped. Stable releases now serialize rather than run in parallel, which at Pylon's cadence is the safer trade.

The two settings are not separable: queue: max with cancel-in-progress: true is a workflow validation error.

Checks

• actionlint 1.7.12: 4 findings on pylon today, 5 on this branch. The one new finding is unexpected key "queue" for "concurrency" section — the linter's schema predates the feature, which GitHub shipped in May 2026. No Pylon workflow runs actionlint in CI, so it does not gate anything.
• The other 4 findings (run_started_at, three shellcheck SC2129) are unchanged from pylon.

One behavior change worth noting

relay_public_config no longer skips when preflight fails, so a failed preflight now costs one extra ~5-minute job that resolves production relay config and then goes unused. Upstream accepted the same trade.

Model: Claude Opus 5. Harness: Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.3 KiB	13.3 KiB	+60 B (+0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+9 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+51 B (+0.8%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.6 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	+1 B (+0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−8 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+9 B (+0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 3ba1857 · PR result: 8d17396 · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.0 KiB

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

[rynfar]

Adversarial review before merge turned up two real problems with taking upstream's concurrency block verbatim. Both fixed in 8d1739684.

Stable releases were losing per-run isolation. Upstream's group collapses every tag push and manual stable dispatch into one literal release-stable lane. Upstream had no concurrency block before #8250, so for them that was strictly more serialization from zero — but Pylon has keyed stable runs off run_id since 8dd0d6e06 precisely so they never interact. Combined with cancel-in-progress: false, adopting the shared lane means a P0 hotfix tag pushed while a release is in flight goes pending behind that run's 90-minute build matrix and 30-minute release upload. The group now keeps github.run_id for stable and the shared group only for nightlies, which preserves both properties:

group: release-${{ (github.event_name == 'schedule' || inputs.channel == 'nightly') && 'nightly' || github.run_id }}

check_changes had no timeout-minutes. It was the only job in the file relying on GitHub's 360-minute default. That was survivable while a fresh nightly cancelled a wedged predecessor; with queuing, a stuck checkout there would hold release-nightly across two cron slots. Now bounded at 5 minutes.

One finding left as-is, deliberately: relay_public_config and build_wsl_node_pty no longer skip when preflight fails, so a doomed run still spends up to 30 minutes on node-gyp rebuild. That is the cost of the parallelism and upstream accepted it. Its blast radius drops a lot with the two fixes above — stable runs no longer hold a shared lane at all, and the nightly case is bounded well inside the 3-hour cron gap. Verified production has protection_rules: [] and no deployment branch policy, so there is no approval gate or secret exposure, just wasted minutes.

Also confirmed clean under review: inputs.channel is legal in the concurrency context and resolves to the right group for every event type; preflight.outputs.ref really is literally ${{ github.sha }}, so that swap is a textual no-op; and apps/server/vite.config.ts declares dependsOn: ["@t3tools/web#build"], so deleting the explicit web build genuinely removes duplicated work rather than dropping it.

[rynfar]

Two pieces of every release run are pure waste: publish_cli builds the web client twice, and two startup jobs wait on version resolution they never read. This removes both, and fixes the two scheduling problems upstream found in the same audit.

Pylon's release workflow has diverged too far from upstream's to cherry-pick, so this is a manual port of pingdotgg/t3code#8250 (a3a8cbd60).

What changed

• publish_cli built the web client twice.@t3tools/web is a workspace dependency of t3, so vp run --filter t3 build already builds it. The explicit step repeated the work on the serial publish path. Verified locally: the command runs exactly two tasks (web, then server) and still produces dist/bin.mjs, dist/service-launcher.mjs, and dist/client/index.html.
• relay_public_config and build_wsl_node_pty now start alongside preflight. Both consume only the commit SHA, and Pylon's preflight.outputs.ref is literally ${{ github.sha }}, so the swap is exactly equivalent. They now share preflight's own check_changes condition. Desktop builds still hard-gate on needs.preflight.result == 'success' && needs.relay_public_config.result == 'success', so nothing builds off a failed preflight.
• Nightly cron moves to minute 7. GitHub delays scheduled runs most at the top of the hour; upstream measured a 13-minute median start delay across 56 sampled runs.
• Nightlies queue instead of cancelling. See below.

Why the concurrency policy flips

8dd0d6e06 set cancel-in-progress: ${{ github.event_name == 'schedule' }} after a Blacksmith capacity outage let 23 nightlies stack ~480 VM-hours deep waiting for runners that never arrived. That was the right fix at the time. 124630c3f then moved every workflow onto GitHub-hosted runners yesterday, and the concurrency block was never revisited — its comment still describes a failure mode that can no longer occur.

Cancelling is now the more dangerous half. publish_cli pushes to npm beforerelease creates the GitHub release, so a cancel in that window strands a published CLI version with no matching desktop build, and npm will not take that version number again. cancel-in-progress: false closes it, and queue: max keeps every pending run (100 FIFO slots per group) instead of the default newest-wins single slot, so the "losing a real release to a scheduling race" concern that motivated the run_id grouping is still covered — a queued stable tag waits rather than being dropped. Stable releases now serialize rather than run in parallel, which at Pylon's cadence is the safer trade.

The two settings are not separable: queue: max with cancel-in-progress: true is a workflow validation error.

Checks

• actionlint 1.7.12: 4 findings on pylon today, 5 on this branch. The one new finding is unexpected key "queue" for "concurrency" section — the linter's schema predates the feature, which GitHub shipped in May 2026. No Pylon workflow runs actionlint in CI, so it does not gate anything.
• The other 4 findings (run_started_at, three shellcheck SC2129) are unchanged from pylon.

One behavior change worth noting

relay_public_config no longer skips when preflight fails, so a failed preflight now costs one extra ~5-minute job that resolves production relay config and then goes unused. Upstream accepted the same trade.

Model: Claude Opus 5. Harness: Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.3 KiB	13.3 KiB	+60 B (+0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+9 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+51 B (+0.8%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.6 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	+1 B (+0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−8 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+9 B (+0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 3ba1857 · PR result: 8d17396 · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.0 KiB

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

[rynfar]

Adversarial review before merge turned up two real problems with taking upstream's concurrency block verbatim. Both fixed in 8d1739684.

Stable releases were losing per-run isolation. Upstream's group collapses every tag push and manual stable dispatch into one literal release-stable lane. Upstream had no concurrency block before #8250, so for them that was strictly more serialization from zero — but Pylon has keyed stable runs off run_id since 8dd0d6e06 precisely so they never interact. Combined with cancel-in-progress: false, adopting the shared lane means a P0 hotfix tag pushed while a release is in flight goes pending behind that run's 90-minute build matrix and 30-minute release upload. The group now keeps github.run_id for stable and the shared group only for nightlies, which preserves both properties:

group: release-${{ (github.event_name == 'schedule' || inputs.channel == 'nightly') && 'nightly' || github.run_id }}

check_changes had no timeout-minutes. It was the only job in the file relying on GitHub's 360-minute default. That was survivable while a fresh nightly cancelled a wedged predecessor; with queuing, a stuck checkout there would hold release-nightly across two cron slots. Now bounded at 5 minutes.

One finding left as-is, deliberately: relay_public_config and build_wsl_node_pty no longer skip when preflight fails, so a doomed run still spends up to 30 minutes on node-gyp rebuild. That is the cost of the parallelism and upstream accepted it. Its blast radius drops a lot with the two fixes above — stable runs no longer hold a shared lane at all, and the nightly case is bounded well inside the 3-hour cron gap. Verified production has protection_rules: [] and no deployment branch policy, so there is no approval gate or secret exposure, just wasted minutes.

Also confirmed clean under review: inputs.channel is legal in the concurrency context and resolves to the right group for every event type; preflight.outputs.ref really is literally ${{ github.sha }}, so that swap is a textual no-op; and apps/server/vite.config.ts declares dependsOn: ["@t3tools/web#build"], so deleting the explicit web build genuinely removes duplicated work rather than dropping it.

[rynfar]

Two pieces of every release run are pure waste: publish_cli builds the web client twice, and two startup jobs wait on version resolution they never read. This removes both, and fixes the two scheduling problems upstream found in the same audit.

Pylon's release workflow has diverged too far from upstream's to cherry-pick, so this is a manual port of pingdotgg/t3code#8250 (a3a8cbd60).

What changed

• publish_cli built the web client twice.@t3tools/web is a workspace dependency of t3, so vp run --filter t3 build already builds it. The explicit step repeated the work on the serial publish path. Verified locally: the command runs exactly two tasks (web, then server) and still produces dist/bin.mjs, dist/service-launcher.mjs, and dist/client/index.html.
• relay_public_config and build_wsl_node_pty now start alongside preflight. Both consume only the commit SHA, and Pylon's preflight.outputs.ref is literally ${{ github.sha }}, so the swap is exactly equivalent. They now share preflight's own check_changes condition. Desktop builds still hard-gate on needs.preflight.result == 'success' && needs.relay_public_config.result == 'success', so nothing builds off a failed preflight.
• Nightly cron moves to minute 7. GitHub delays scheduled runs most at the top of the hour; upstream measured a 13-minute median start delay across 56 sampled runs.
• Nightlies queue instead of cancelling. See below.

Why the concurrency policy flips

8dd0d6e06 set cancel-in-progress: ${{ github.event_name == 'schedule' }} after a Blacksmith capacity outage let 23 nightlies stack ~480 VM-hours deep waiting for runners that never arrived. That was the right fix at the time. 124630c3f then moved every workflow onto GitHub-hosted runners yesterday, and the concurrency block was never revisited — its comment still describes a failure mode that can no longer occur.

Cancelling is now the more dangerous half. publish_cli pushes to npm beforerelease creates the GitHub release, so a cancel in that window strands a published CLI version with no matching desktop build, and npm will not take that version number again. cancel-in-progress: false closes it, and queue: max keeps every pending run (100 FIFO slots per group) instead of the default newest-wins single slot, so the "losing a real release to a scheduling race" concern that motivated the run_id grouping is still covered — a queued stable tag waits rather than being dropped. Stable releases now serialize rather than run in parallel, which at Pylon's cadence is the safer trade.

The two settings are not separable: queue: max with cancel-in-progress: true is a workflow validation error.

Checks

• actionlint 1.7.12: 4 findings on pylon today, 5 on this branch. The one new finding is unexpected key "queue" for "concurrency" section — the linter's schema predates the feature, which GitHub shipped in May 2026. No Pylon workflow runs actionlint in CI, so it does not gate anything.
• The other 4 findings (run_started_at, three shellcheck SC2129) are unchanged from pylon.

One behavior change worth noting

relay_public_config no longer skips when preflight fails, so a failed preflight now costs one extra ~5-minute job that resolves production relay config and then goes unused. Upstream accepted the same trade.

Model: Claude Opus 5. Harness: Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.3 KiB	13.3 KiB	+60 B (+0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+9 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+51 B (+0.8%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.6 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	+1 B (+0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−8 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+9 B (+0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 3ba1857 · PR result: 8d17396 · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.0 KiB

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

[rynfar]

Adversarial review before merge turned up two real problems with taking upstream's concurrency block verbatim. Both fixed in 8d1739684.

Stable releases were losing per-run isolation. Upstream's group collapses every tag push and manual stable dispatch into one literal release-stable lane. Upstream had no concurrency block before #8250, so for them that was strictly more serialization from zero — but Pylon has keyed stable runs off run_id since 8dd0d6e06 precisely so they never interact. Combined with cancel-in-progress: false, adopting the shared lane means a P0 hotfix tag pushed while a release is in flight goes pending behind that run's 90-minute build matrix and 30-minute release upload. The group now keeps github.run_id for stable and the shared group only for nightlies, which preserves both properties:

group: release-${{ (github.event_name == 'schedule' || inputs.channel == 'nightly') && 'nightly' || github.run_id }}

check_changes had no timeout-minutes. It was the only job in the file relying on GitHub's 360-minute default. That was survivable while a fresh nightly cancelled a wedged predecessor; with queuing, a stuck checkout there would hold release-nightly across two cron slots. Now bounded at 5 minutes.

One finding left as-is, deliberately: relay_public_config and build_wsl_node_pty no longer skip when preflight fails, so a doomed run still spends up to 30 minutes on node-gyp rebuild. That is the cost of the parallelism and upstream accepted it. Its blast radius drops a lot with the two fixes above — stable runs no longer hold a shared lane at all, and the nightly case is bounded well inside the 3-hour cron gap. Verified production has protection_rules: [] and no deployment branch policy, so there is no approval gate or secret exposure, just wasted minutes.

Also confirmed clean under review: inputs.channel is legal in the concurrency context and resolves to the right group for every event type; preflight.outputs.ref really is literally ${{ github.sha }}, so that swap is a textual no-op; and apps/server/vite.config.ts declares dependsOn: ["@t3tools/web#build"], so deleting the explicit web build genuinely removes duplicated work rather than dropping it.

[rynfar]

Two pieces of every release run are pure waste: publish_cli builds the web client twice, and two startup jobs wait on version resolution they never read. This removes both, and fixes the two scheduling problems upstream found in the same audit.

Pylon's release workflow has diverged too far from upstream's to cherry-pick, so this is a manual port of pingdotgg/t3code#8250 (a3a8cbd60).

What changed

• publish_cli built the web client twice.@t3tools/web is a workspace dependency of t3, so vp run --filter t3 build already builds it. The explicit step repeated the work on the serial publish path. Verified locally: the command runs exactly two tasks (web, then server) and still produces dist/bin.mjs, dist/service-launcher.mjs, and dist/client/index.html.
• relay_public_config and build_wsl_node_pty now start alongside preflight. Both consume only the commit SHA, and Pylon's preflight.outputs.ref is literally ${{ github.sha }}, so the swap is exactly equivalent. They now share preflight's own check_changes condition. Desktop builds still hard-gate on needs.preflight.result == 'success' && needs.relay_public_config.result == 'success', so nothing builds off a failed preflight.
• Nightly cron moves to minute 7. GitHub delays scheduled runs most at the top of the hour; upstream measured a 13-minute median start delay across 56 sampled runs.
• Nightlies queue instead of cancelling. See below.

Why the concurrency policy flips

8dd0d6e06 set cancel-in-progress: ${{ github.event_name == 'schedule' }} after a Blacksmith capacity outage let 23 nightlies stack ~480 VM-hours deep waiting for runners that never arrived. That was the right fix at the time. 124630c3f then moved every workflow onto GitHub-hosted runners yesterday, and the concurrency block was never revisited — its comment still describes a failure mode that can no longer occur.

Cancelling is now the more dangerous half. publish_cli pushes to npm beforerelease creates the GitHub release, so a cancel in that window strands a published CLI version with no matching desktop build, and npm will not take that version number again. cancel-in-progress: false closes it, and queue: max keeps every pending run (100 FIFO slots per group) instead of the default newest-wins single slot, so the "losing a real release to a scheduling race" concern that motivated the run_id grouping is still covered — a queued stable tag waits rather than being dropped. Stable releases now serialize rather than run in parallel, which at Pylon's cadence is the safer trade.

The two settings are not separable: queue: max with cancel-in-progress: true is a workflow validation error.

Checks

• actionlint 1.7.12: 4 findings on pylon today, 5 on this branch. The one new finding is unexpected key "queue" for "concurrency" section — the linter's schema predates the feature, which GitHub shipped in May 2026. No Pylon workflow runs actionlint in CI, so it does not gate anything.
• The other 4 findings (run_started_at, three shellcheck SC2129) are unchanged from pylon.

One behavior change worth noting

relay_public_config no longer skips when preflight fails, so a failed preflight now costs one extra ~5-minute job that resolves production relay config and then goes unused. Upstream accepted the same trade.

Model: Claude Opus 5. Harness: Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.3 KiB	13.3 KiB	+60 B (+0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+9 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+51 B (+0.8%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.6 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	+1 B (+0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−8 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+9 B (+0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 3ba1857 · PR result: 8d17396 · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.0 KiB

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

[rynfar]

Adversarial review before merge turned up two real problems with taking upstream's concurrency block verbatim. Both fixed in 8d1739684.

Stable releases were losing per-run isolation. Upstream's group collapses every tag push and manual stable dispatch into one literal release-stable lane. Upstream had no concurrency block before #8250, so for them that was strictly more serialization from zero — but Pylon has keyed stable runs off run_id since 8dd0d6e06 precisely so they never interact. Combined with cancel-in-progress: false, adopting the shared lane means a P0 hotfix tag pushed while a release is in flight goes pending behind that run's 90-minute build matrix and 30-minute release upload. The group now keeps github.run_id for stable and the shared group only for nightlies, which preserves both properties:

group: release-${{ (github.event_name == 'schedule' || inputs.channel == 'nightly') && 'nightly' || github.run_id }}

check_changes had no timeout-minutes. It was the only job in the file relying on GitHub's 360-minute default. That was survivable while a fresh nightly cancelled a wedged predecessor; with queuing, a stuck checkout there would hold release-nightly across two cron slots. Now bounded at 5 minutes.

One finding left as-is, deliberately: relay_public_config and build_wsl_node_pty no longer skip when preflight fails, so a doomed run still spends up to 30 minutes on node-gyp rebuild. That is the cost of the parallelism and upstream accepted it. Its blast radius drops a lot with the two fixes above — stable runs no longer hold a shared lane at all, and the nightly case is bounded well inside the 3-hour cron gap. Verified production has protection_rules: [] and no deployment branch policy, so there is no approval gate or secret exposure, just wasted minutes.

Also confirmed clean under review: inputs.channel is legal in the concurrency context and resolves to the right group for every event type; preflight.outputs.ref really is literally ${{ github.sha }}, so that swap is a textual no-op; and apps/server/vite.config.ts declares dependsOn: ["@t3tools/web#build"], so deleting the explicit web build genuinely removes duplicated work rather than dropping it.

[rynfar]

Two pieces of every release run are pure waste: publish_cli builds the web client twice, and two startup jobs wait on version resolution they never read. This removes both, and fixes the two scheduling problems upstream found in the same audit.

Pylon's release workflow has diverged too far from upstream's to cherry-pick, so this is a manual port of pingdotgg/t3code#8250 (a3a8cbd60).

What changed

• publish_cli built the web client twice.@t3tools/web is a workspace dependency of t3, so vp run --filter t3 build already builds it. The explicit step repeated the work on the serial publish path. Verified locally: the command runs exactly two tasks (web, then server) and still produces dist/bin.mjs, dist/service-launcher.mjs, and dist/client/index.html.
• relay_public_config and build_wsl_node_pty now start alongside preflight. Both consume only the commit SHA, and Pylon's preflight.outputs.ref is literally ${{ github.sha }}, so the swap is exactly equivalent. They now share preflight's own check_changes condition. Desktop builds still hard-gate on needs.preflight.result == 'success' && needs.relay_public_config.result == 'success', so nothing builds off a failed preflight.
• Nightly cron moves to minute 7. GitHub delays scheduled runs most at the top of the hour; upstream measured a 13-minute median start delay across 56 sampled runs.
• Nightlies queue instead of cancelling. See below.

Why the concurrency policy flips

8dd0d6e06 set cancel-in-progress: ${{ github.event_name == 'schedule' }} after a Blacksmith capacity outage let 23 nightlies stack ~480 VM-hours deep waiting for runners that never arrived. That was the right fix at the time. 124630c3f then moved every workflow onto GitHub-hosted runners yesterday, and the concurrency block was never revisited — its comment still describes a failure mode that can no longer occur.

Cancelling is now the more dangerous half. publish_cli pushes to npm beforerelease creates the GitHub release, so a cancel in that window strands a published CLI version with no matching desktop build, and npm will not take that version number again. cancel-in-progress: false closes it, and queue: max keeps every pending run (100 FIFO slots per group) instead of the default newest-wins single slot, so the "losing a real release to a scheduling race" concern that motivated the run_id grouping is still covered — a queued stable tag waits rather than being dropped. Stable releases now serialize rather than run in parallel, which at Pylon's cadence is the safer trade.

The two settings are not separable: queue: max with cancel-in-progress: true is a workflow validation error.

Checks

• actionlint 1.7.12: 4 findings on pylon today, 5 on this branch. The one new finding is unexpected key "queue" for "concurrency" section — the linter's schema predates the feature, which GitHub shipped in May 2026. No Pylon workflow runs actionlint in CI, so it does not gate anything.
• The other 4 findings (run_started_at, three shellcheck SC2129) are unchanged from pylon.

One behavior change worth noting

relay_public_config no longer skips when preflight fails, so a failed preflight now costs one extra ~5-minute job that resolves production relay config and then goes unused. Upstream accepted the same trade.

Model: Claude Opus 5. Harness: Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.3 KiB	13.3 KiB	+60 B (+0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+9 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+51 B (+0.8%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.6 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	+1 B (+0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−8 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+9 B (+0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 3ba1857 · PR result: 8d17396 · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.0 KiB

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

[rynfar]

Adversarial review before merge turned up two real problems with taking upstream's concurrency block verbatim. Both fixed in 8d1739684.

Stable releases were losing per-run isolation. Upstream's group collapses every tag push and manual stable dispatch into one literal release-stable lane. Upstream had no concurrency block before #8250, so for them that was strictly more serialization from zero — but Pylon has keyed stable runs off run_id since 8dd0d6e06 precisely so they never interact. Combined with cancel-in-progress: false, adopting the shared lane means a P0 hotfix tag pushed while a release is in flight goes pending behind that run's 90-minute build matrix and 30-minute release upload. The group now keeps github.run_id for stable and the shared group only for nightlies, which preserves both properties:

group: release-${{ (github.event_name == 'schedule' || inputs.channel == 'nightly') && 'nightly' || github.run_id }}

check_changes had no timeout-minutes. It was the only job in the file relying on GitHub's 360-minute default. That was survivable while a fresh nightly cancelled a wedged predecessor; with queuing, a stuck checkout there would hold release-nightly across two cron slots. Now bounded at 5 minutes.

One finding left as-is, deliberately: relay_public_config and build_wsl_node_pty no longer skip when preflight fails, so a doomed run still spends up to 30 minutes on node-gyp rebuild. That is the cost of the parallelism and upstream accepted it. Its blast radius drops a lot with the two fixes above — stable runs no longer hold a shared lane at all, and the nightly case is bounded well inside the 3-hour cron gap. Verified production has protection_rules: [] and no deployment branch policy, so there is no approval gate or secret exposure, just wasted minutes.

Also confirmed clean under review: inputs.channel is legal in the concurrency context and resolves to the right group for every event type; preflight.outputs.ref really is literally ${{ github.sha }}, so that swap is a textual no-op; and apps/server/vite.config.ts declares dependsOn: ["@t3tools/web#build"], so deleting the explicit web build genuinely removes duplicated work rather than dropping it.

[rynfar]

Two pieces of every release run are pure waste: publish_cli builds the web client twice, and two startup jobs wait on version resolution they never read. This removes both, and fixes the two scheduling problems upstream found in the same audit.

Pylon's release workflow has diverged too far from upstream's to cherry-pick, so this is a manual port of pingdotgg/t3code#8250 (a3a8cbd60).

What changed

• publish_cli built the web client twice.@t3tools/web is a workspace dependency of t3, so vp run --filter t3 build already builds it. The explicit step repeated the work on the serial publish path. Verified locally: the command runs exactly two tasks (web, then server) and still produces dist/bin.mjs, dist/service-launcher.mjs, and dist/client/index.html.
• relay_public_config and build_wsl_node_pty now start alongside preflight. Both consume only the commit SHA, and Pylon's preflight.outputs.ref is literally ${{ github.sha }}, so the swap is exactly equivalent. They now share preflight's own check_changes condition. Desktop builds still hard-gate on needs.preflight.result == 'success' && needs.relay_public_config.result == 'success', so nothing builds off a failed preflight.
• Nightly cron moves to minute 7. GitHub delays scheduled runs most at the top of the hour; upstream measured a 13-minute median start delay across 56 sampled runs.
• Nightlies queue instead of cancelling. See below.

Why the concurrency policy flips

8dd0d6e06 set cancel-in-progress: ${{ github.event_name == 'schedule' }} after a Blacksmith capacity outage let 23 nightlies stack ~480 VM-hours deep waiting for runners that never arrived. That was the right fix at the time. 124630c3f then moved every workflow onto GitHub-hosted runners yesterday, and the concurrency block was never revisited — its comment still describes a failure mode that can no longer occur.

Cancelling is now the more dangerous half. publish_cli pushes to npm beforerelease creates the GitHub release, so a cancel in that window strands a published CLI version with no matching desktop build, and npm will not take that version number again. cancel-in-progress: false closes it, and queue: max keeps every pending run (100 FIFO slots per group) instead of the default newest-wins single slot, so the "losing a real release to a scheduling race" concern that motivated the run_id grouping is still covered — a queued stable tag waits rather than being dropped. Stable releases now serialize rather than run in parallel, which at Pylon's cadence is the safer trade.

The two settings are not separable: queue: max with cancel-in-progress: true is a workflow validation error.

Checks

• actionlint 1.7.12: 4 findings on pylon today, 5 on this branch. The one new finding is unexpected key "queue" for "concurrency" section — the linter's schema predates the feature, which GitHub shipped in May 2026. No Pylon workflow runs actionlint in CI, so it does not gate anything.
• The other 4 findings (run_started_at, three shellcheck SC2129) are unchanged from pylon.

One behavior change worth noting

relay_public_config no longer skips when preflight fails, so a failed preflight now costs one extra ~5-minute job that resolves production relay config and then goes unused. Upstream accepted the same trade.

Model: Claude Opus 5. Harness: Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.3 KiB	13.3 KiB	+60 B (+0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+9 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+51 B (+0.8%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.6 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	+1 B (+0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−8 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+9 B (+0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 3ba1857 · PR result: 8d17396 · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.0 KiB

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

[rynfar]

Adversarial review before merge turned up two real problems with taking upstream's concurrency block verbatim. Both fixed in 8d1739684.

Stable releases were losing per-run isolation. Upstream's group collapses every tag push and manual stable dispatch into one literal release-stable lane. Upstream had no concurrency block before #8250, so for them that was strictly more serialization from zero — but Pylon has keyed stable runs off run_id since 8dd0d6e06 precisely so they never interact. Combined with cancel-in-progress: false, adopting the shared lane means a P0 hotfix tag pushed while a release is in flight goes pending behind that run's 90-minute build matrix and 30-minute release upload. The group now keeps github.run_id for stable and the shared group only for nightlies, which preserves both properties:

group: release-${{ (github.event_name == 'schedule' || inputs.channel == 'nightly') && 'nightly' || github.run_id }}

check_changes had no timeout-minutes. It was the only job in the file relying on GitHub's 360-minute default. That was survivable while a fresh nightly cancelled a wedged predecessor; with queuing, a stuck checkout there would hold release-nightly across two cron slots. Now bounded at 5 minutes.

One finding left as-is, deliberately: relay_public_config and build_wsl_node_pty no longer skip when preflight fails, so a doomed run still spends up to 30 minutes on node-gyp rebuild. That is the cost of the parallelism and upstream accepted it. Its blast radius drops a lot with the two fixes above — stable runs no longer hold a shared lane at all, and the nightly case is bounded well inside the 3-hour cron gap. Verified production has protection_rules: [] and no deployment branch policy, so there is no approval gate or secret exposure, just wasted minutes.

Also confirmed clean under review: inputs.channel is legal in the concurrency context and resolves to the right group for every event type; preflight.outputs.ref really is literally ${{ github.sha }}, so that swap is a textual no-op; and apps/server/vite.config.ts declares dependsOn: ["@t3tools/web#build"], so deleting the explicit web build genuinely removes duplicated work rather than dropping it.

[rynfar]

Two pieces of every release run are pure waste: publish_cli builds the web client twice, and two startup jobs wait on version resolution they never read. This removes both, and fixes the two scheduling problems upstream found in the same audit.

Pylon's release workflow has diverged too far from upstream's to cherry-pick, so this is a manual port of pingdotgg/t3code#8250 (a3a8cbd60).

What changed

• publish_cli built the web client twice.@t3tools/web is a workspace dependency of t3, so vp run --filter t3 build already builds it. The explicit step repeated the work on the serial publish path. Verified locally: the command runs exactly two tasks (web, then server) and still produces dist/bin.mjs, dist/service-launcher.mjs, and dist/client/index.html.
• relay_public_config and build_wsl_node_pty now start alongside preflight. Both consume only the commit SHA, and Pylon's preflight.outputs.ref is literally ${{ github.sha }}, so the swap is exactly equivalent. They now share preflight's own check_changes condition. Desktop builds still hard-gate on needs.preflight.result == 'success' && needs.relay_public_config.result == 'success', so nothing builds off a failed preflight.
• Nightly cron moves to minute 7. GitHub delays scheduled runs most at the top of the hour; upstream measured a 13-minute median start delay across 56 sampled runs.
• Nightlies queue instead of cancelling. See below.

Why the concurrency policy flips

8dd0d6e06 set cancel-in-progress: ${{ github.event_name == 'schedule' }} after a Blacksmith capacity outage let 23 nightlies stack ~480 VM-hours deep waiting for runners that never arrived. That was the right fix at the time. 124630c3f then moved every workflow onto GitHub-hosted runners yesterday, and the concurrency block was never revisited — its comment still describes a failure mode that can no longer occur.

Cancelling is now the more dangerous half. publish_cli pushes to npm beforerelease creates the GitHub release, so a cancel in that window strands a published CLI version with no matching desktop build, and npm will not take that version number again. cancel-in-progress: false closes it, and queue: max keeps every pending run (100 FIFO slots per group) instead of the default newest-wins single slot, so the "losing a real release to a scheduling race" concern that motivated the run_id grouping is still covered — a queued stable tag waits rather than being dropped. Stable releases now serialize rather than run in parallel, which at Pylon's cadence is the safer trade.

The two settings are not separable: queue: max with cancel-in-progress: true is a workflow validation error.

Checks

• actionlint 1.7.12: 4 findings on pylon today, 5 on this branch. The one new finding is unexpected key "queue" for "concurrency" section — the linter's schema predates the feature, which GitHub shipped in May 2026. No Pylon workflow runs actionlint in CI, so it does not gate anything.
• The other 4 findings (run_started_at, three shellcheck SC2129) are unchanged from pylon.

One behavior change worth noting

relay_public_config no longer skips when preflight fails, so a failed preflight now costs one extra ~5-minute job that resolves production relay config and then goes unused. Upstream accepted the same trade.

Model: Claude Opus 5. Harness: Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.3 KiB	13.3 KiB	+60 B (+0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+9 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+51 B (+0.8%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.6 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	+1 B (+0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−8 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+9 B (+0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 3ba1857 · PR result: 8d17396 · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.0 KiB

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

[rynfar]

Adversarial review before merge turned up two real problems with taking upstream's concurrency block verbatim. Both fixed in 8d1739684.

Stable releases were losing per-run isolation. Upstream's group collapses every tag push and manual stable dispatch into one literal release-stable lane. Upstream had no concurrency block before #8250, so for them that was strictly more serialization from zero — but Pylon has keyed stable runs off run_id since 8dd0d6e06 precisely so they never interact. Combined with cancel-in-progress: false, adopting the shared lane means a P0 hotfix tag pushed while a release is in flight goes pending behind that run's 90-minute build matrix and 30-minute release upload. The group now keeps github.run_id for stable and the shared group only for nightlies, which preserves both properties:

group: release-${{ (github.event_name == 'schedule' || inputs.channel == 'nightly') && 'nightly' || github.run_id }}

check_changes had no timeout-minutes. It was the only job in the file relying on GitHub's 360-minute default. That was survivable while a fresh nightly cancelled a wedged predecessor; with queuing, a stuck checkout there would hold release-nightly across two cron slots. Now bounded at 5 minutes.

One finding left as-is, deliberately: relay_public_config and build_wsl_node_pty no longer skip when preflight fails, so a doomed run still spends up to 30 minutes on node-gyp rebuild. That is the cost of the parallelism and upstream accepted it. Its blast radius drops a lot with the two fixes above — stable runs no longer hold a shared lane at all, and the nightly case is bounded well inside the 3-hour cron gap. Verified production has protection_rules: [] and no deployment branch policy, so there is no approval gate or secret exposure, just wasted minutes.

Also confirmed clean under review: inputs.channel is legal in the concurrency context and resolves to the right group for every event type; preflight.outputs.ref really is literally ${{ github.sha }}, so that swap is a textual no-op; and apps/server/vite.config.ts declares dependsOn: ["@t3tools/web#build"], so deleting the explicit web build genuinely removes duplicated work rather than dropping it.

[rynfar]

Two pieces of every release run are pure waste: publish_cli builds the web client twice, and two startup jobs wait on version resolution they never read. This removes both, and fixes the two scheduling problems upstream found in the same audit.

Pylon's release workflow has diverged too far from upstream's to cherry-pick, so this is a manual port of pingdotgg/t3code#8250 (a3a8cbd60).

What changed

• publish_cli built the web client twice.@t3tools/web is a workspace dependency of t3, so vp run --filter t3 build already builds it. The explicit step repeated the work on the serial publish path. Verified locally: the command runs exactly two tasks (web, then server) and still produces dist/bin.mjs, dist/service-launcher.mjs, and dist/client/index.html.
• relay_public_config and build_wsl_node_pty now start alongside preflight. Both consume only the commit SHA, and Pylon's preflight.outputs.ref is literally ${{ github.sha }}, so the swap is exactly equivalent. They now share preflight's own check_changes condition. Desktop builds still hard-gate on needs.preflight.result == 'success' && needs.relay_public_config.result == 'success', so nothing builds off a failed preflight.
• Nightly cron moves to minute 7. GitHub delays scheduled runs most at the top of the hour; upstream measured a 13-minute median start delay across 56 sampled runs.
• Nightlies queue instead of cancelling. See below.

Why the concurrency policy flips

8dd0d6e06 set cancel-in-progress: ${{ github.event_name == 'schedule' }} after a Blacksmith capacity outage let 23 nightlies stack ~480 VM-hours deep waiting for runners that never arrived. That was the right fix at the time. 124630c3f then moved every workflow onto GitHub-hosted runners yesterday, and the concurrency block was never revisited — its comment still describes a failure mode that can no longer occur.

Cancelling is now the more dangerous half. publish_cli pushes to npm beforerelease creates the GitHub release, so a cancel in that window strands a published CLI version with no matching desktop build, and npm will not take that version number again. cancel-in-progress: false closes it, and queue: max keeps every pending run (100 FIFO slots per group) instead of the default newest-wins single slot, so the "losing a real release to a scheduling race" concern that motivated the run_id grouping is still covered — a queued stable tag waits rather than being dropped. Stable releases now serialize rather than run in parallel, which at Pylon's cadence is the safer trade.

The two settings are not separable: queue: max with cancel-in-progress: true is a workflow validation error.

Checks

• actionlint 1.7.12: 4 findings on pylon today, 5 on this branch. The one new finding is unexpected key "queue" for "concurrency" section — the linter's schema predates the feature, which GitHub shipped in May 2026. No Pylon workflow runs actionlint in CI, so it does not gate anything.
• The other 4 findings (run_started_at, three shellcheck SC2129) are unchanged from pylon.

One behavior change worth noting

relay_public_config no longer skips when preflight fails, so a failed preflight now costs one extra ~5-minute job that resolves production relay config and then goes unused. Upstream accepted the same trade.

Model: Claude Opus 5. Harness: Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.3 KiB	13.3 KiB	+60 B (+0.4%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+9 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+51 B (+0.8%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.6 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	+1 B (+0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−8 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+9 B (+0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 3ba1857 · PR result: 8d17396 · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.0 KiB

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

[rynfar]

Adversarial review before merge turned up two real problems with taking upstream's concurrency block verbatim. Both fixed in 8d1739684.

Stable releases were losing per-run isolation. Upstream's group collapses every tag push and manual stable dispatch into one literal release-stable lane. Upstream had no concurrency block before #8250, so for them that was strictly more serialization from zero — but Pylon has keyed stable runs off run_id since 8dd0d6e06 precisely so they never interact. Combined with cancel-in-progress: false, adopting the shared lane means a P0 hotfix tag pushed while a release is in flight goes pending behind that run's 90-minute build matrix and 30-minute release upload. The group now keeps github.run_id for stable and the shared group only for nightlies, which preserves both properties:

group: release-${{ (github.event_name == 'schedule' || inputs.channel == 'nightly') && 'nightly' || github.run_id }}

check_changes had no timeout-minutes. It was the only job in the file relying on GitHub's 360-minute default. That was survivable while a fresh nightly cancelled a wedged predecessor; with queuing, a stuck checkout there would hold release-nightly across two cron slots. Now bounded at 5 minutes.

One finding left as-is, deliberately: relay_public_config and build_wsl_node_pty no longer skip when preflight fails, so a doomed run still spends up to 30 minutes on node-gyp rebuild. That is the cost of the parallelism and upstream accepted it. Its blast radius drops a lot with the two fixes above — stable runs no longer hold a shared lane at all, and the nightly case is bounded well inside the 3-hour cron gap. Verified production has protection_rules: [] and no deployment branch policy, so there is no approval gate or secret exposure, just wasted minutes.

Also confirmed clean under review: inputs.channel is legal in the concurrency context and resolves to the right group for every event type; preflight.outputs.ref really is literally ${{ github.sha }}, so that swap is a textual no-op; and apps/server/vite.config.ts declares dependsOn: ["@t3tools/web#build"], so deleting the explicit web build genuinely removes duplicated work rather than dropping it.