feat(ci): download macOS preview DMGs without signing in

[rynfar]

Preview DMGs upload as Actions artifacts, and GitHub requires a signed-in account to download those. That breaks fetching a build onto a headless box. For a public repo the login gate adds no real protection, since any GitHub account can already download them.

The workflow now publishes each DMG as an asset on a rolling desktop-preview prerelease. Release assets download anonymously from a stable URL, so curl from a headless machine works, and the PR comment links to it.

How it stays safe and tidy:

• The build job keeps a read-only token and still runs PR code. A new publish job holds the write token; it only downloads the built artifact and talks to the GitHub API, and never checks out PR code.
• One rolling prerelease holds all preview DMGs. Publishing uploads an asset rather than creating a release, so release watchers get no notification.
• Each PR keeps one DMG. A new build replaces the old one, and the -pr.N. filename marker stops one PR's build from touching another's asset.
• A cleanup job deletes the PR's DMG and updates the comment when the PR closes or the label comes off, replacing the old 7-day artifact expiry.

Build restrictions are unchanged: same-repo PRs with the preview:mac label only, unsigned build, no Apple secrets.

Pylon adaptation

The two new jobs run on ubuntu-latest instead of upstream's blacksmith-8vcpu-ubuntu-2404, matching the GitHub-hosted move in 124630c3f. The macos-26 build runner is unchanged. Nothing else needed adapting — cherry-picked clean otherwise.

Pylon-specific checks

• No auto-updater interaction. Pylon publishes desktop releases and the updater feed to pylon-code/pylon-releases (per the PYLON_DESKTOP_UPDATE_REPOSITORY variable). The preview release lands on pylon-code/pylon, which has zero releases, so the nightly channel's allowPrerelease: true never sees it. Publishing to the releases repo instead would have been the dangerous option.
• No release-workflow collision.release.yml only matches v*.*.* tags; desktop-preview does not match.
• --target "$DEFAULT_BRANCH" resolves correctly — the repo default branch is pylon.
• The -pr.N. marker exists. Pylon's version step already produces ${base_version}-pr.${PR_NUMBER}.${GITHUB_RUN_NUMBER}, which the anti-clobber guard depends on.
• actionlint 1.7.12: clean on pylon and clean on this branch.

Two things to decide

1. The preview:mac label does not exist on this repo. Every run of this workflow to date has been skipped for that reason, so the feature is currently inert — before and after this change. It needs the label created before it does anything. I did not create it; say the word and I will.
2. pylon-code/pylon currently shows no releases at all. After the first preview build, its releases page and homepage sidebar would advertise an unsigned preview DMG as the repo's only release, while real builds continue to live in pylon-code/pylon-releases. That is cosmetic, but it is the one judgment call here.

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	+12 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+7 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+5 B (+0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.5 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−2 B (−0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+2 B (+0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 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: 9d11232 · 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 found four ways this could leave a wrong final state behind a green check. All fixed in 9d112329e. Every one is inherited from upstream rather than introduced by the Pylon adaptation, and every one traces to the same root cause: treating a failed API call as an answer.

The root cause.preview_eligible() was [[ "$(gh pr view ...)" == "OPEN true" ]]. Under set -euo pipefail, a command substitution that fails inside a condition does not trip errexit — it just yields an empty string. Confirmed locally: a failing gh produces "treated as ineligible" and the script still exits 0. So a transient 502 is indistinguishable from "the PR closed", and the two jobs then fall in opposite directions:

• publish silently no-ops after a ~25-minute macOS build, logging a message that is actively false; or, on the post-upload re-check, deletes the asset it just uploaded while the PR is open and labeled — leaving the existing comment pointing at a 404 with no event left to fix it.
• cleanup falls the other way: empty string is not "OPEN true", so it proceeds to delete a live download during an unlabel→relabel race.

Both now go through a preview_state helper that retries, distinguishes "no answer" from "not eligible", and refuses to act on a guess. It is duplicated in both jobs on purpose — neither may check out the repo, so there is no file to source.

Cleanup could not honor its own promise. It wrote removed=truebefore inspecting the release, could not tell a missing release from a broken API (gh release view >/dev/null 2>&1 collapses 404 and 502), and swallowed every delete error as "already removed by a concurrent run". A 502 there left a public DMG downloadable forever while the comment claimed it was gone — the exact one-way door AGENTS.md calls a bug. It now distinguishes 404 from failure, tracks whether deletes actually succeeded, fails loudly if any did not, and only claims removal once it is true.

Publish deleted before uploading. The header comment reasons carefully that a cleanup must never be cancelled mid-delete — but publish deletes too, and unlike cleanup it sits in the build concurrency group, where synchronize evaluates cancel-in-progress: true. A push landing between the delete and the upload leaves a 404 in the comment for the length of the next build. Asset names carry GITHUB_RUN_NUMBER, so uploading first and pruning after closes it with no behavior change.

Unlabel-then-close could strand a DMG permanently. GitHub cancels a pending run when a newer one joins its group. Both events share the cleanup group, so a queued unlabel cleanup gets cancelled by the close event — and the close branch's if required preview:mac, which is now gone. Nothing would ever delete that asset. The closed branch no longer requires the label; the job is idempotent and keyed by -pr.N., so an unrelated close finds nothing and stops.

Filename hardening. The DMG name comes out of the build, which runs PR code, and becomes a release asset name, a public URL, and Markdown in a bot-authored comment. A name like x-pr.42.7)](https://evil.example)(.dmg satisfies the old substring guard and escapes the link. It is now pinned to ^[A-Za-z0-9][A-Za-z0-9._-]*\.dmg$.

Verification. Both run: bodies were extracted and executed against a stubbed gh: 7 cleanup cases (deletes succeed / relabeled / PR API down / no release / release API down / asset already gone / delete 502) and 7 publish cases (happy path / closed during build / API down / markdown-escape name / wrong PR marker / no DMG / prune selectivity). The prune deletes only the stale pr.42.6 — never its own pr.42.7 upload, never PR 99's asset. actionlint reports 0 findings including shellcheck.

Confirmed clean and left alone: the -pr.N. trailing-dot reasoning genuinely holds (-pr.12. matches neither -pr.1. nor -pr.123.); the privilege boundary is sound (pull_request, not pull_request_target; build keeps contents: read; all attacker-controlled values reach github-script via env:, never ${{ }} inside run:); size:* label churn cannot trigger this workflow at all, because GITHUB_TOKEN-authored label events do not start runs; and the auto-updater cannot see the rolling prerelease, since it uses provider: "generic" and real releases live in pylon-code/pylon-releases.

Still blocking real use: the preview:mac label does not exist on this repo, so the build has never once executed here. That also makes archive: false on the artifact upload an untested assumption — if it is wrong, pattern: "*.dmg" matches nothing and the run dies loudly at "No DMG found", which is fail-safe but means the first labeled PR is the test. Worth driving one PR through label → push → unlabel → relabel → close before trusting this.

[rynfar]

Preview DMGs upload as Actions artifacts, and GitHub requires a signed-in account to download those. That breaks fetching a build onto a headless box. For a public repo the login gate adds no real protection, since any GitHub account can already download them.

The workflow now publishes each DMG as an asset on a rolling desktop-preview prerelease. Release assets download anonymously from a stable URL, so curl from a headless machine works, and the PR comment links to it.

How it stays safe and tidy:

• The build job keeps a read-only token and still runs PR code. A new publish job holds the write token; it only downloads the built artifact and talks to the GitHub API, and never checks out PR code.
• One rolling prerelease holds all preview DMGs. Publishing uploads an asset rather than creating a release, so release watchers get no notification.
• Each PR keeps one DMG. A new build replaces the old one, and the -pr.N. filename marker stops one PR's build from touching another's asset.
• A cleanup job deletes the PR's DMG and updates the comment when the PR closes or the label comes off, replacing the old 7-day artifact expiry.

Build restrictions are unchanged: same-repo PRs with the preview:mac label only, unsigned build, no Apple secrets.

Pylon adaptation

The two new jobs run on ubuntu-latest instead of upstream's blacksmith-8vcpu-ubuntu-2404, matching the GitHub-hosted move in 124630c3f. The macos-26 build runner is unchanged. Nothing else needed adapting — cherry-picked clean otherwise.

Pylon-specific checks

• No auto-updater interaction. Pylon publishes desktop releases and the updater feed to pylon-code/pylon-releases (per the PYLON_DESKTOP_UPDATE_REPOSITORY variable). The preview release lands on pylon-code/pylon, which has zero releases, so the nightly channel's allowPrerelease: true never sees it. Publishing to the releases repo instead would have been the dangerous option.
• No release-workflow collision.release.yml only matches v*.*.* tags; desktop-preview does not match.
• --target "$DEFAULT_BRANCH" resolves correctly — the repo default branch is pylon.
• The -pr.N. marker exists. Pylon's version step already produces ${base_version}-pr.${PR_NUMBER}.${GITHUB_RUN_NUMBER}, which the anti-clobber guard depends on.
• actionlint 1.7.12: clean on pylon and clean on this branch.

Two things to decide

1. The preview:mac label does not exist on this repo. Every run of this workflow to date has been skipped for that reason, so the feature is currently inert — before and after this change. It needs the label created before it does anything. I did not create it; say the word and I will.
2. pylon-code/pylon currently shows no releases at all. After the first preview build, its releases page and homepage sidebar would advertise an unsigned preview DMG as the repo's only release, while real builds continue to live in pylon-code/pylon-releases. That is cosmetic, but it is the one judgment call here.

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	+12 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+7 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+5 B (+0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.5 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−2 B (−0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+2 B (+0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 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: 9d11232 · 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 found four ways this could leave a wrong final state behind a green check. All fixed in 9d112329e. Every one is inherited from upstream rather than introduced by the Pylon adaptation, and every one traces to the same root cause: treating a failed API call as an answer.

The root cause.preview_eligible() was [[ "$(gh pr view ...)" == "OPEN true" ]]. Under set -euo pipefail, a command substitution that fails inside a condition does not trip errexit — it just yields an empty string. Confirmed locally: a failing gh produces "treated as ineligible" and the script still exits 0. So a transient 502 is indistinguishable from "the PR closed", and the two jobs then fall in opposite directions:

• publish silently no-ops after a ~25-minute macOS build, logging a message that is actively false; or, on the post-upload re-check, deletes the asset it just uploaded while the PR is open and labeled — leaving the existing comment pointing at a 404 with no event left to fix it.
• cleanup falls the other way: empty string is not "OPEN true", so it proceeds to delete a live download during an unlabel→relabel race.

Both now go through a preview_state helper that retries, distinguishes "no answer" from "not eligible", and refuses to act on a guess. It is duplicated in both jobs on purpose — neither may check out the repo, so there is no file to source.

Cleanup could not honor its own promise. It wrote removed=truebefore inspecting the release, could not tell a missing release from a broken API (gh release view >/dev/null 2>&1 collapses 404 and 502), and swallowed every delete error as "already removed by a concurrent run". A 502 there left a public DMG downloadable forever while the comment claimed it was gone — the exact one-way door AGENTS.md calls a bug. It now distinguishes 404 from failure, tracks whether deletes actually succeeded, fails loudly if any did not, and only claims removal once it is true.

Publish deleted before uploading. The header comment reasons carefully that a cleanup must never be cancelled mid-delete — but publish deletes too, and unlike cleanup it sits in the build concurrency group, where synchronize evaluates cancel-in-progress: true. A push landing between the delete and the upload leaves a 404 in the comment for the length of the next build. Asset names carry GITHUB_RUN_NUMBER, so uploading first and pruning after closes it with no behavior change.

Unlabel-then-close could strand a DMG permanently. GitHub cancels a pending run when a newer one joins its group. Both events share the cleanup group, so a queued unlabel cleanup gets cancelled by the close event — and the close branch's if required preview:mac, which is now gone. Nothing would ever delete that asset. The closed branch no longer requires the label; the job is idempotent and keyed by -pr.N., so an unrelated close finds nothing and stops.

Filename hardening. The DMG name comes out of the build, which runs PR code, and becomes a release asset name, a public URL, and Markdown in a bot-authored comment. A name like x-pr.42.7)](https://evil.example)(.dmg satisfies the old substring guard and escapes the link. It is now pinned to ^[A-Za-z0-9][A-Za-z0-9._-]*\.dmg$.

Verification. Both run: bodies were extracted and executed against a stubbed gh: 7 cleanup cases (deletes succeed / relabeled / PR API down / no release / release API down / asset already gone / delete 502) and 7 publish cases (happy path / closed during build / API down / markdown-escape name / wrong PR marker / no DMG / prune selectivity). The prune deletes only the stale pr.42.6 — never its own pr.42.7 upload, never PR 99's asset. actionlint reports 0 findings including shellcheck.

Confirmed clean and left alone: the -pr.N. trailing-dot reasoning genuinely holds (-pr.12. matches neither -pr.1. nor -pr.123.); the privilege boundary is sound (pull_request, not pull_request_target; build keeps contents: read; all attacker-controlled values reach github-script via env:, never ${{ }} inside run:); size:* label churn cannot trigger this workflow at all, because GITHUB_TOKEN-authored label events do not start runs; and the auto-updater cannot see the rolling prerelease, since it uses provider: "generic" and real releases live in pylon-code/pylon-releases.

Still blocking real use: the preview:mac label does not exist on this repo, so the build has never once executed here. That also makes archive: false on the artifact upload an untested assumption — if it is wrong, pattern: "*.dmg" matches nothing and the run dies loudly at "No DMG found", which is fail-safe but means the first labeled PR is the test. Worth driving one PR through label → push → unlabel → relabel → close before trusting this.

[rynfar]

Preview DMGs upload as Actions artifacts, and GitHub requires a signed-in account to download those. That breaks fetching a build onto a headless box. For a public repo the login gate adds no real protection, since any GitHub account can already download them.

The workflow now publishes each DMG as an asset on a rolling desktop-preview prerelease. Release assets download anonymously from a stable URL, so curl from a headless machine works, and the PR comment links to it.

How it stays safe and tidy:

• The build job keeps a read-only token and still runs PR code. A new publish job holds the write token; it only downloads the built artifact and talks to the GitHub API, and never checks out PR code.
• One rolling prerelease holds all preview DMGs. Publishing uploads an asset rather than creating a release, so release watchers get no notification.
• Each PR keeps one DMG. A new build replaces the old one, and the -pr.N. filename marker stops one PR's build from touching another's asset.
• A cleanup job deletes the PR's DMG and updates the comment when the PR closes or the label comes off, replacing the old 7-day artifact expiry.

Build restrictions are unchanged: same-repo PRs with the preview:mac label only, unsigned build, no Apple secrets.

Pylon adaptation

The two new jobs run on ubuntu-latest instead of upstream's blacksmith-8vcpu-ubuntu-2404, matching the GitHub-hosted move in 124630c3f. The macos-26 build runner is unchanged. Nothing else needed adapting — cherry-picked clean otherwise.

Pylon-specific checks

• No auto-updater interaction. Pylon publishes desktop releases and the updater feed to pylon-code/pylon-releases (per the PYLON_DESKTOP_UPDATE_REPOSITORY variable). The preview release lands on pylon-code/pylon, which has zero releases, so the nightly channel's allowPrerelease: true never sees it. Publishing to the releases repo instead would have been the dangerous option.
• No release-workflow collision.release.yml only matches v*.*.* tags; desktop-preview does not match.
• --target "$DEFAULT_BRANCH" resolves correctly — the repo default branch is pylon.
• The -pr.N. marker exists. Pylon's version step already produces ${base_version}-pr.${PR_NUMBER}.${GITHUB_RUN_NUMBER}, which the anti-clobber guard depends on.
• actionlint 1.7.12: clean on pylon and clean on this branch.

Two things to decide

1. The preview:mac label does not exist on this repo. Every run of this workflow to date has been skipped for that reason, so the feature is currently inert — before and after this change. It needs the label created before it does anything. I did not create it; say the word and I will.
2. pylon-code/pylon currently shows no releases at all. After the first preview build, its releases page and homepage sidebar would advertise an unsigned preview DMG as the repo's only release, while real builds continue to live in pylon-code/pylon-releases. That is cosmetic, but it is the one judgment call here.

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	+12 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+7 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+5 B (+0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.5 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−2 B (−0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+2 B (+0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 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: 9d11232 · 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 found four ways this could leave a wrong final state behind a green check. All fixed in 9d112329e. Every one is inherited from upstream rather than introduced by the Pylon adaptation, and every one traces to the same root cause: treating a failed API call as an answer.

The root cause.preview_eligible() was [[ "$(gh pr view ...)" == "OPEN true" ]]. Under set -euo pipefail, a command substitution that fails inside a condition does not trip errexit — it just yields an empty string. Confirmed locally: a failing gh produces "treated as ineligible" and the script still exits 0. So a transient 502 is indistinguishable from "the PR closed", and the two jobs then fall in opposite directions:

• publish silently no-ops after a ~25-minute macOS build, logging a message that is actively false; or, on the post-upload re-check, deletes the asset it just uploaded while the PR is open and labeled — leaving the existing comment pointing at a 404 with no event left to fix it.
• cleanup falls the other way: empty string is not "OPEN true", so it proceeds to delete a live download during an unlabel→relabel race.

Both now go through a preview_state helper that retries, distinguishes "no answer" from "not eligible", and refuses to act on a guess. It is duplicated in both jobs on purpose — neither may check out the repo, so there is no file to source.

Cleanup could not honor its own promise. It wrote removed=truebefore inspecting the release, could not tell a missing release from a broken API (gh release view >/dev/null 2>&1 collapses 404 and 502), and swallowed every delete error as "already removed by a concurrent run". A 502 there left a public DMG downloadable forever while the comment claimed it was gone — the exact one-way door AGENTS.md calls a bug. It now distinguishes 404 from failure, tracks whether deletes actually succeeded, fails loudly if any did not, and only claims removal once it is true.

Publish deleted before uploading. The header comment reasons carefully that a cleanup must never be cancelled mid-delete — but publish deletes too, and unlike cleanup it sits in the build concurrency group, where synchronize evaluates cancel-in-progress: true. A push landing between the delete and the upload leaves a 404 in the comment for the length of the next build. Asset names carry GITHUB_RUN_NUMBER, so uploading first and pruning after closes it with no behavior change.

Unlabel-then-close could strand a DMG permanently. GitHub cancels a pending run when a newer one joins its group. Both events share the cleanup group, so a queued unlabel cleanup gets cancelled by the close event — and the close branch's if required preview:mac, which is now gone. Nothing would ever delete that asset. The closed branch no longer requires the label; the job is idempotent and keyed by -pr.N., so an unrelated close finds nothing and stops.

Filename hardening. The DMG name comes out of the build, which runs PR code, and becomes a release asset name, a public URL, and Markdown in a bot-authored comment. A name like x-pr.42.7)](https://evil.example)(.dmg satisfies the old substring guard and escapes the link. It is now pinned to ^[A-Za-z0-9][A-Za-z0-9._-]*\.dmg$.

Verification. Both run: bodies were extracted and executed against a stubbed gh: 7 cleanup cases (deletes succeed / relabeled / PR API down / no release / release API down / asset already gone / delete 502) and 7 publish cases (happy path / closed during build / API down / markdown-escape name / wrong PR marker / no DMG / prune selectivity). The prune deletes only the stale pr.42.6 — never its own pr.42.7 upload, never PR 99's asset. actionlint reports 0 findings including shellcheck.

Confirmed clean and left alone: the -pr.N. trailing-dot reasoning genuinely holds (-pr.12. matches neither -pr.1. nor -pr.123.); the privilege boundary is sound (pull_request, not pull_request_target; build keeps contents: read; all attacker-controlled values reach github-script via env:, never ${{ }} inside run:); size:* label churn cannot trigger this workflow at all, because GITHUB_TOKEN-authored label events do not start runs; and the auto-updater cannot see the rolling prerelease, since it uses provider: "generic" and real releases live in pylon-code/pylon-releases.

Still blocking real use: the preview:mac label does not exist on this repo, so the build has never once executed here. That also makes archive: false on the artifact upload an untested assumption — if it is wrong, pattern: "*.dmg" matches nothing and the run dies loudly at "No DMG found", which is fail-safe but means the first labeled PR is the test. Worth driving one PR through label → push → unlabel → relabel → close before trusting this.

[rynfar]

Preview DMGs upload as Actions artifacts, and GitHub requires a signed-in account to download those. That breaks fetching a build onto a headless box. For a public repo the login gate adds no real protection, since any GitHub account can already download them.

The workflow now publishes each DMG as an asset on a rolling desktop-preview prerelease. Release assets download anonymously from a stable URL, so curl from a headless machine works, and the PR comment links to it.

How it stays safe and tidy:

• The build job keeps a read-only token and still runs PR code. A new publish job holds the write token; it only downloads the built artifact and talks to the GitHub API, and never checks out PR code.
• One rolling prerelease holds all preview DMGs. Publishing uploads an asset rather than creating a release, so release watchers get no notification.
• Each PR keeps one DMG. A new build replaces the old one, and the -pr.N. filename marker stops one PR's build from touching another's asset.
• A cleanup job deletes the PR's DMG and updates the comment when the PR closes or the label comes off, replacing the old 7-day artifact expiry.

Build restrictions are unchanged: same-repo PRs with the preview:mac label only, unsigned build, no Apple secrets.

Pylon adaptation

The two new jobs run on ubuntu-latest instead of upstream's blacksmith-8vcpu-ubuntu-2404, matching the GitHub-hosted move in 124630c3f. The macos-26 build runner is unchanged. Nothing else needed adapting — cherry-picked clean otherwise.

Pylon-specific checks

• No auto-updater interaction. Pylon publishes desktop releases and the updater feed to pylon-code/pylon-releases (per the PYLON_DESKTOP_UPDATE_REPOSITORY variable). The preview release lands on pylon-code/pylon, which has zero releases, so the nightly channel's allowPrerelease: true never sees it. Publishing to the releases repo instead would have been the dangerous option.
• No release-workflow collision.release.yml only matches v*.*.* tags; desktop-preview does not match.
• --target "$DEFAULT_BRANCH" resolves correctly — the repo default branch is pylon.
• The -pr.N. marker exists. Pylon's version step already produces ${base_version}-pr.${PR_NUMBER}.${GITHUB_RUN_NUMBER}, which the anti-clobber guard depends on.
• actionlint 1.7.12: clean on pylon and clean on this branch.

Two things to decide

1. The preview:mac label does not exist on this repo. Every run of this workflow to date has been skipped for that reason, so the feature is currently inert — before and after this change. It needs the label created before it does anything. I did not create it; say the word and I will.
2. pylon-code/pylon currently shows no releases at all. After the first preview build, its releases page and homepage sidebar would advertise an unsigned preview DMG as the repo's only release, while real builds continue to live in pylon-code/pylon-releases. That is cosmetic, but it is the one judgment call here.

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	+12 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+7 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+5 B (+0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.5 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−2 B (−0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+2 B (+0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 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: 9d11232 · 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 found four ways this could leave a wrong final state behind a green check. All fixed in 9d112329e. Every one is inherited from upstream rather than introduced by the Pylon adaptation, and every one traces to the same root cause: treating a failed API call as an answer.

The root cause.preview_eligible() was [[ "$(gh pr view ...)" == "OPEN true" ]]. Under set -euo pipefail, a command substitution that fails inside a condition does not trip errexit — it just yields an empty string. Confirmed locally: a failing gh produces "treated as ineligible" and the script still exits 0. So a transient 502 is indistinguishable from "the PR closed", and the two jobs then fall in opposite directions:

• publish silently no-ops after a ~25-minute macOS build, logging a message that is actively false; or, on the post-upload re-check, deletes the asset it just uploaded while the PR is open and labeled — leaving the existing comment pointing at a 404 with no event left to fix it.
• cleanup falls the other way: empty string is not "OPEN true", so it proceeds to delete a live download during an unlabel→relabel race.

Both now go through a preview_state helper that retries, distinguishes "no answer" from "not eligible", and refuses to act on a guess. It is duplicated in both jobs on purpose — neither may check out the repo, so there is no file to source.

Cleanup could not honor its own promise. It wrote removed=truebefore inspecting the release, could not tell a missing release from a broken API (gh release view >/dev/null 2>&1 collapses 404 and 502), and swallowed every delete error as "already removed by a concurrent run". A 502 there left a public DMG downloadable forever while the comment claimed it was gone — the exact one-way door AGENTS.md calls a bug. It now distinguishes 404 from failure, tracks whether deletes actually succeeded, fails loudly if any did not, and only claims removal once it is true.

Publish deleted before uploading. The header comment reasons carefully that a cleanup must never be cancelled mid-delete — but publish deletes too, and unlike cleanup it sits in the build concurrency group, where synchronize evaluates cancel-in-progress: true. A push landing between the delete and the upload leaves a 404 in the comment for the length of the next build. Asset names carry GITHUB_RUN_NUMBER, so uploading first and pruning after closes it with no behavior change.

Unlabel-then-close could strand a DMG permanently. GitHub cancels a pending run when a newer one joins its group. Both events share the cleanup group, so a queued unlabel cleanup gets cancelled by the close event — and the close branch's if required preview:mac, which is now gone. Nothing would ever delete that asset. The closed branch no longer requires the label; the job is idempotent and keyed by -pr.N., so an unrelated close finds nothing and stops.

Filename hardening. The DMG name comes out of the build, which runs PR code, and becomes a release asset name, a public URL, and Markdown in a bot-authored comment. A name like x-pr.42.7)](https://evil.example)(.dmg satisfies the old substring guard and escapes the link. It is now pinned to ^[A-Za-z0-9][A-Za-z0-9._-]*\.dmg$.

Verification. Both run: bodies were extracted and executed against a stubbed gh: 7 cleanup cases (deletes succeed / relabeled / PR API down / no release / release API down / asset already gone / delete 502) and 7 publish cases (happy path / closed during build / API down / markdown-escape name / wrong PR marker / no DMG / prune selectivity). The prune deletes only the stale pr.42.6 — never its own pr.42.7 upload, never PR 99's asset. actionlint reports 0 findings including shellcheck.

Confirmed clean and left alone: the -pr.N. trailing-dot reasoning genuinely holds (-pr.12. matches neither -pr.1. nor -pr.123.); the privilege boundary is sound (pull_request, not pull_request_target; build keeps contents: read; all attacker-controlled values reach github-script via env:, never ${{ }} inside run:); size:* label churn cannot trigger this workflow at all, because GITHUB_TOKEN-authored label events do not start runs; and the auto-updater cannot see the rolling prerelease, since it uses provider: "generic" and real releases live in pylon-code/pylon-releases.

Still blocking real use: the preview:mac label does not exist on this repo, so the build has never once executed here. That also makes archive: false on the artifact upload an untested assumption — if it is wrong, pattern: "*.dmg" matches nothing and the run dies loudly at "No DMG found", which is fail-safe but means the first labeled PR is the test. Worth driving one PR through label → push → unlabel → relabel → close before trusting this.

[rynfar]

Preview DMGs upload as Actions artifacts, and GitHub requires a signed-in account to download those. That breaks fetching a build onto a headless box. For a public repo the login gate adds no real protection, since any GitHub account can already download them.

The workflow now publishes each DMG as an asset on a rolling desktop-preview prerelease. Release assets download anonymously from a stable URL, so curl from a headless machine works, and the PR comment links to it.

How it stays safe and tidy:

• The build job keeps a read-only token and still runs PR code. A new publish job holds the write token; it only downloads the built artifact and talks to the GitHub API, and never checks out PR code.
• One rolling prerelease holds all preview DMGs. Publishing uploads an asset rather than creating a release, so release watchers get no notification.
• Each PR keeps one DMG. A new build replaces the old one, and the -pr.N. filename marker stops one PR's build from touching another's asset.
• A cleanup job deletes the PR's DMG and updates the comment when the PR closes or the label comes off, replacing the old 7-day artifact expiry.

Build restrictions are unchanged: same-repo PRs with the preview:mac label only, unsigned build, no Apple secrets.

Pylon adaptation

The two new jobs run on ubuntu-latest instead of upstream's blacksmith-8vcpu-ubuntu-2404, matching the GitHub-hosted move in 124630c3f. The macos-26 build runner is unchanged. Nothing else needed adapting — cherry-picked clean otherwise.

Pylon-specific checks

• No auto-updater interaction. Pylon publishes desktop releases and the updater feed to pylon-code/pylon-releases (per the PYLON_DESKTOP_UPDATE_REPOSITORY variable). The preview release lands on pylon-code/pylon, which has zero releases, so the nightly channel's allowPrerelease: true never sees it. Publishing to the releases repo instead would have been the dangerous option.
• No release-workflow collision.release.yml only matches v*.*.* tags; desktop-preview does not match.
• --target "$DEFAULT_BRANCH" resolves correctly — the repo default branch is pylon.
• The -pr.N. marker exists. Pylon's version step already produces ${base_version}-pr.${PR_NUMBER}.${GITHUB_RUN_NUMBER}, which the anti-clobber guard depends on.
• actionlint 1.7.12: clean on pylon and clean on this branch.

Two things to decide

1. The preview:mac label does not exist on this repo. Every run of this workflow to date has been skipped for that reason, so the feature is currently inert — before and after this change. It needs the label created before it does anything. I did not create it; say the word and I will.
2. pylon-code/pylon currently shows no releases at all. After the first preview build, its releases page and homepage sidebar would advertise an unsigned preview DMG as the repo's only release, while real builds continue to live in pylon-code/pylon-releases. That is cosmetic, but it is the one judgment call here.

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	+12 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+7 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+5 B (+0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.5 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−2 B (−0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+2 B (+0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 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: 9d11232 · 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 found four ways this could leave a wrong final state behind a green check. All fixed in 9d112329e. Every one is inherited from upstream rather than introduced by the Pylon adaptation, and every one traces to the same root cause: treating a failed API call as an answer.

The root cause.preview_eligible() was [[ "$(gh pr view ...)" == "OPEN true" ]]. Under set -euo pipefail, a command substitution that fails inside a condition does not trip errexit — it just yields an empty string. Confirmed locally: a failing gh produces "treated as ineligible" and the script still exits 0. So a transient 502 is indistinguishable from "the PR closed", and the two jobs then fall in opposite directions:

• publish silently no-ops after a ~25-minute macOS build, logging a message that is actively false; or, on the post-upload re-check, deletes the asset it just uploaded while the PR is open and labeled — leaving the existing comment pointing at a 404 with no event left to fix it.
• cleanup falls the other way: empty string is not "OPEN true", so it proceeds to delete a live download during an unlabel→relabel race.

Both now go through a preview_state helper that retries, distinguishes "no answer" from "not eligible", and refuses to act on a guess. It is duplicated in both jobs on purpose — neither may check out the repo, so there is no file to source.

Cleanup could not honor its own promise. It wrote removed=truebefore inspecting the release, could not tell a missing release from a broken API (gh release view >/dev/null 2>&1 collapses 404 and 502), and swallowed every delete error as "already removed by a concurrent run". A 502 there left a public DMG downloadable forever while the comment claimed it was gone — the exact one-way door AGENTS.md calls a bug. It now distinguishes 404 from failure, tracks whether deletes actually succeeded, fails loudly if any did not, and only claims removal once it is true.

Publish deleted before uploading. The header comment reasons carefully that a cleanup must never be cancelled mid-delete — but publish deletes too, and unlike cleanup it sits in the build concurrency group, where synchronize evaluates cancel-in-progress: true. A push landing between the delete and the upload leaves a 404 in the comment for the length of the next build. Asset names carry GITHUB_RUN_NUMBER, so uploading first and pruning after closes it with no behavior change.

Unlabel-then-close could strand a DMG permanently. GitHub cancels a pending run when a newer one joins its group. Both events share the cleanup group, so a queued unlabel cleanup gets cancelled by the close event — and the close branch's if required preview:mac, which is now gone. Nothing would ever delete that asset. The closed branch no longer requires the label; the job is idempotent and keyed by -pr.N., so an unrelated close finds nothing and stops.

Filename hardening. The DMG name comes out of the build, which runs PR code, and becomes a release asset name, a public URL, and Markdown in a bot-authored comment. A name like x-pr.42.7)](https://evil.example)(.dmg satisfies the old substring guard and escapes the link. It is now pinned to ^[A-Za-z0-9][A-Za-z0-9._-]*\.dmg$.

Verification. Both run: bodies were extracted and executed against a stubbed gh: 7 cleanup cases (deletes succeed / relabeled / PR API down / no release / release API down / asset already gone / delete 502) and 7 publish cases (happy path / closed during build / API down / markdown-escape name / wrong PR marker / no DMG / prune selectivity). The prune deletes only the stale pr.42.6 — never its own pr.42.7 upload, never PR 99's asset. actionlint reports 0 findings including shellcheck.

Confirmed clean and left alone: the -pr.N. trailing-dot reasoning genuinely holds (-pr.12. matches neither -pr.1. nor -pr.123.); the privilege boundary is sound (pull_request, not pull_request_target; build keeps contents: read; all attacker-controlled values reach github-script via env:, never ${{ }} inside run:); size:* label churn cannot trigger this workflow at all, because GITHUB_TOKEN-authored label events do not start runs; and the auto-updater cannot see the rolling prerelease, since it uses provider: "generic" and real releases live in pylon-code/pylon-releases.

Still blocking real use: the preview:mac label does not exist on this repo, so the build has never once executed here. That also makes archive: false on the artifact upload an untested assumption — if it is wrong, pattern: "*.dmg" matches nothing and the run dies loudly at "No DMG found", which is fail-safe but means the first labeled PR is the test. Worth driving one PR through label → push → unlabel → relabel → close before trusting this.

[rynfar]

Preview DMGs upload as Actions artifacts, and GitHub requires a signed-in account to download those. That breaks fetching a build onto a headless box. For a public repo the login gate adds no real protection, since any GitHub account can already download them.

The workflow now publishes each DMG as an asset on a rolling desktop-preview prerelease. Release assets download anonymously from a stable URL, so curl from a headless machine works, and the PR comment links to it.

How it stays safe and tidy:

• The build job keeps a read-only token and still runs PR code. A new publish job holds the write token; it only downloads the built artifact and talks to the GitHub API, and never checks out PR code.
• One rolling prerelease holds all preview DMGs. Publishing uploads an asset rather than creating a release, so release watchers get no notification.
• Each PR keeps one DMG. A new build replaces the old one, and the -pr.N. filename marker stops one PR's build from touching another's asset.
• A cleanup job deletes the PR's DMG and updates the comment when the PR closes or the label comes off, replacing the old 7-day artifact expiry.

Build restrictions are unchanged: same-repo PRs with the preview:mac label only, unsigned build, no Apple secrets.

Pylon adaptation

The two new jobs run on ubuntu-latest instead of upstream's blacksmith-8vcpu-ubuntu-2404, matching the GitHub-hosted move in 124630c3f. The macos-26 build runner is unchanged. Nothing else needed adapting — cherry-picked clean otherwise.

Pylon-specific checks

• No auto-updater interaction. Pylon publishes desktop releases and the updater feed to pylon-code/pylon-releases (per the PYLON_DESKTOP_UPDATE_REPOSITORY variable). The preview release lands on pylon-code/pylon, which has zero releases, so the nightly channel's allowPrerelease: true never sees it. Publishing to the releases repo instead would have been the dangerous option.
• No release-workflow collision.release.yml only matches v*.*.* tags; desktop-preview does not match.
• --target "$DEFAULT_BRANCH" resolves correctly — the repo default branch is pylon.
• The -pr.N. marker exists. Pylon's version step already produces ${base_version}-pr.${PR_NUMBER}.${GITHUB_RUN_NUMBER}, which the anti-clobber guard depends on.
• actionlint 1.7.12: clean on pylon and clean on this branch.

Two things to decide

1. The preview:mac label does not exist on this repo. Every run of this workflow to date has been skipped for that reason, so the feature is currently inert — before and after this change. It needs the label created before it does anything. I did not create it; say the word and I will.
2. pylon-code/pylon currently shows no releases at all. After the first preview build, its releases page and homepage sidebar would advertise an unsigned preview DMG as the repo's only release, while real builds continue to live in pylon-code/pylon-releases. That is cosmetic, but it is the one judgment call here.

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	+12 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+7 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+5 B (+0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.5 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−2 B (−0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+2 B (+0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 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: 9d11232 · 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 found four ways this could leave a wrong final state behind a green check. All fixed in 9d112329e. Every one is inherited from upstream rather than introduced by the Pylon adaptation, and every one traces to the same root cause: treating a failed API call as an answer.

The root cause.preview_eligible() was [[ "$(gh pr view ...)" == "OPEN true" ]]. Under set -euo pipefail, a command substitution that fails inside a condition does not trip errexit — it just yields an empty string. Confirmed locally: a failing gh produces "treated as ineligible" and the script still exits 0. So a transient 502 is indistinguishable from "the PR closed", and the two jobs then fall in opposite directions:

• publish silently no-ops after a ~25-minute macOS build, logging a message that is actively false; or, on the post-upload re-check, deletes the asset it just uploaded while the PR is open and labeled — leaving the existing comment pointing at a 404 with no event left to fix it.
• cleanup falls the other way: empty string is not "OPEN true", so it proceeds to delete a live download during an unlabel→relabel race.

Both now go through a preview_state helper that retries, distinguishes "no answer" from "not eligible", and refuses to act on a guess. It is duplicated in both jobs on purpose — neither may check out the repo, so there is no file to source.

Cleanup could not honor its own promise. It wrote removed=truebefore inspecting the release, could not tell a missing release from a broken API (gh release view >/dev/null 2>&1 collapses 404 and 502), and swallowed every delete error as "already removed by a concurrent run". A 502 there left a public DMG downloadable forever while the comment claimed it was gone — the exact one-way door AGENTS.md calls a bug. It now distinguishes 404 from failure, tracks whether deletes actually succeeded, fails loudly if any did not, and only claims removal once it is true.

Publish deleted before uploading. The header comment reasons carefully that a cleanup must never be cancelled mid-delete — but publish deletes too, and unlike cleanup it sits in the build concurrency group, where synchronize evaluates cancel-in-progress: true. A push landing between the delete and the upload leaves a 404 in the comment for the length of the next build. Asset names carry GITHUB_RUN_NUMBER, so uploading first and pruning after closes it with no behavior change.

Unlabel-then-close could strand a DMG permanently. GitHub cancels a pending run when a newer one joins its group. Both events share the cleanup group, so a queued unlabel cleanup gets cancelled by the close event — and the close branch's if required preview:mac, which is now gone. Nothing would ever delete that asset. The closed branch no longer requires the label; the job is idempotent and keyed by -pr.N., so an unrelated close finds nothing and stops.

Filename hardening. The DMG name comes out of the build, which runs PR code, and becomes a release asset name, a public URL, and Markdown in a bot-authored comment. A name like x-pr.42.7)](https://evil.example)(.dmg satisfies the old substring guard and escapes the link. It is now pinned to ^[A-Za-z0-9][A-Za-z0-9._-]*\.dmg$.

Verification. Both run: bodies were extracted and executed against a stubbed gh: 7 cleanup cases (deletes succeed / relabeled / PR API down / no release / release API down / asset already gone / delete 502) and 7 publish cases (happy path / closed during build / API down / markdown-escape name / wrong PR marker / no DMG / prune selectivity). The prune deletes only the stale pr.42.6 — never its own pr.42.7 upload, never PR 99's asset. actionlint reports 0 findings including shellcheck.

Confirmed clean and left alone: the -pr.N. trailing-dot reasoning genuinely holds (-pr.12. matches neither -pr.1. nor -pr.123.); the privilege boundary is sound (pull_request, not pull_request_target; build keeps contents: read; all attacker-controlled values reach github-script via env:, never ${{ }} inside run:); size:* label churn cannot trigger this workflow at all, because GITHUB_TOKEN-authored label events do not start runs; and the auto-updater cannot see the rolling prerelease, since it uses provider: "generic" and real releases live in pylon-code/pylon-releases.

Still blocking real use: the preview:mac label does not exist on this repo, so the build has never once executed here. That also makes archive: false on the artifact upload an untested assumption — if it is wrong, pattern: "*.dmg" matches nothing and the run dies loudly at "No DMG found", which is fail-safe but means the first labeled PR is the test. Worth driving one PR through label → push → unlabel → relabel → close before trusting this.

[rynfar]

Preview DMGs upload as Actions artifacts, and GitHub requires a signed-in account to download those. That breaks fetching a build onto a headless box. For a public repo the login gate adds no real protection, since any GitHub account can already download them.

The workflow now publishes each DMG as an asset on a rolling desktop-preview prerelease. Release assets download anonymously from a stable URL, so curl from a headless machine works, and the PR comment links to it.

How it stays safe and tidy:

• The build job keeps a read-only token and still runs PR code. A new publish job holds the write token; it only downloads the built artifact and talks to the GitHub API, and never checks out PR code.
• One rolling prerelease holds all preview DMGs. Publishing uploads an asset rather than creating a release, so release watchers get no notification.
• Each PR keeps one DMG. A new build replaces the old one, and the -pr.N. filename marker stops one PR's build from touching another's asset.
• A cleanup job deletes the PR's DMG and updates the comment when the PR closes or the label comes off, replacing the old 7-day artifact expiry.

Build restrictions are unchanged: same-repo PRs with the preview:mac label only, unsigned build, no Apple secrets.

Pylon adaptation

The two new jobs run on ubuntu-latest instead of upstream's blacksmith-8vcpu-ubuntu-2404, matching the GitHub-hosted move in 124630c3f. The macos-26 build runner is unchanged. Nothing else needed adapting — cherry-picked clean otherwise.

Pylon-specific checks

• No auto-updater interaction. Pylon publishes desktop releases and the updater feed to pylon-code/pylon-releases (per the PYLON_DESKTOP_UPDATE_REPOSITORY variable). The preview release lands on pylon-code/pylon, which has zero releases, so the nightly channel's allowPrerelease: true never sees it. Publishing to the releases repo instead would have been the dangerous option.
• No release-workflow collision.release.yml only matches v*.*.* tags; desktop-preview does not match.
• --target "$DEFAULT_BRANCH" resolves correctly — the repo default branch is pylon.
• The -pr.N. marker exists. Pylon's version step already produces ${base_version}-pr.${PR_NUMBER}.${GITHUB_RUN_NUMBER}, which the anti-clobber guard depends on.
• actionlint 1.7.12: clean on pylon and clean on this branch.

Two things to decide

1. The preview:mac label does not exist on this repo. Every run of this workflow to date has been skipped for that reason, so the feature is currently inert — before and after this change. It needs the label created before it does anything. I did not create it; say the word and I will.
2. pylon-code/pylon currently shows no releases at all. After the first preview build, its releases page and homepage sidebar would advertise an unsigned preview DMG as the repo's only release, while real builds continue to live in pylon-code/pylon-releases. That is cosmetic, but it is the one judgment call here.

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	+12 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+7 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+5 B (+0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.5 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−2 B (−0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+2 B (+0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 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: 9d11232 · 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 found four ways this could leave a wrong final state behind a green check. All fixed in 9d112329e. Every one is inherited from upstream rather than introduced by the Pylon adaptation, and every one traces to the same root cause: treating a failed API call as an answer.

The root cause.preview_eligible() was [[ "$(gh pr view ...)" == "OPEN true" ]]. Under set -euo pipefail, a command substitution that fails inside a condition does not trip errexit — it just yields an empty string. Confirmed locally: a failing gh produces "treated as ineligible" and the script still exits 0. So a transient 502 is indistinguishable from "the PR closed", and the two jobs then fall in opposite directions:

• publish silently no-ops after a ~25-minute macOS build, logging a message that is actively false; or, on the post-upload re-check, deletes the asset it just uploaded while the PR is open and labeled — leaving the existing comment pointing at a 404 with no event left to fix it.
• cleanup falls the other way: empty string is not "OPEN true", so it proceeds to delete a live download during an unlabel→relabel race.

Both now go through a preview_state helper that retries, distinguishes "no answer" from "not eligible", and refuses to act on a guess. It is duplicated in both jobs on purpose — neither may check out the repo, so there is no file to source.

Cleanup could not honor its own promise. It wrote removed=truebefore inspecting the release, could not tell a missing release from a broken API (gh release view >/dev/null 2>&1 collapses 404 and 502), and swallowed every delete error as "already removed by a concurrent run". A 502 there left a public DMG downloadable forever while the comment claimed it was gone — the exact one-way door AGENTS.md calls a bug. It now distinguishes 404 from failure, tracks whether deletes actually succeeded, fails loudly if any did not, and only claims removal once it is true.

Publish deleted before uploading. The header comment reasons carefully that a cleanup must never be cancelled mid-delete — but publish deletes too, and unlike cleanup it sits in the build concurrency group, where synchronize evaluates cancel-in-progress: true. A push landing between the delete and the upload leaves a 404 in the comment for the length of the next build. Asset names carry GITHUB_RUN_NUMBER, so uploading first and pruning after closes it with no behavior change.

Unlabel-then-close could strand a DMG permanently. GitHub cancels a pending run when a newer one joins its group. Both events share the cleanup group, so a queued unlabel cleanup gets cancelled by the close event — and the close branch's if required preview:mac, which is now gone. Nothing would ever delete that asset. The closed branch no longer requires the label; the job is idempotent and keyed by -pr.N., so an unrelated close finds nothing and stops.

Filename hardening. The DMG name comes out of the build, which runs PR code, and becomes a release asset name, a public URL, and Markdown in a bot-authored comment. A name like x-pr.42.7)](https://evil.example)(.dmg satisfies the old substring guard and escapes the link. It is now pinned to ^[A-Za-z0-9][A-Za-z0-9._-]*\.dmg$.

Verification. Both run: bodies were extracted and executed against a stubbed gh: 7 cleanup cases (deletes succeed / relabeled / PR API down / no release / release API down / asset already gone / delete 502) and 7 publish cases (happy path / closed during build / API down / markdown-escape name / wrong PR marker / no DMG / prune selectivity). The prune deletes only the stale pr.42.6 — never its own pr.42.7 upload, never PR 99's asset. actionlint reports 0 findings including shellcheck.

Confirmed clean and left alone: the -pr.N. trailing-dot reasoning genuinely holds (-pr.12. matches neither -pr.1. nor -pr.123.); the privilege boundary is sound (pull_request, not pull_request_target; build keeps contents: read; all attacker-controlled values reach github-script via env:, never ${{ }} inside run:); size:* label churn cannot trigger this workflow at all, because GITHUB_TOKEN-authored label events do not start runs; and the auto-updater cannot see the rolling prerelease, since it uses provider: "generic" and real releases live in pylon-code/pylon-releases.

Still blocking real use: the preview:mac label does not exist on this repo, so the build has never once executed here. That also makes archive: false on the artifact upload an untested assumption — if it is wrong, pattern: "*.dmg" matches nothing and the run dies loudly at "No DMG found", which is fail-safe but means the first labeled PR is the test. Worth driving one PR through label → push → unlabel → relabel → close before trusting this.

[rynfar]

Preview DMGs upload as Actions artifacts, and GitHub requires a signed-in account to download those. That breaks fetching a build onto a headless box. For a public repo the login gate adds no real protection, since any GitHub account can already download them.

The workflow now publishes each DMG as an asset on a rolling desktop-preview prerelease. Release assets download anonymously from a stable URL, so curl from a headless machine works, and the PR comment links to it.

How it stays safe and tidy:

• The build job keeps a read-only token and still runs PR code. A new publish job holds the write token; it only downloads the built artifact and talks to the GitHub API, and never checks out PR code.
• One rolling prerelease holds all preview DMGs. Publishing uploads an asset rather than creating a release, so release watchers get no notification.
• Each PR keeps one DMG. A new build replaces the old one, and the -pr.N. filename marker stops one PR's build from touching another's asset.
• A cleanup job deletes the PR's DMG and updates the comment when the PR closes or the label comes off, replacing the old 7-day artifact expiry.

Build restrictions are unchanged: same-repo PRs with the preview:mac label only, unsigned build, no Apple secrets.

Pylon adaptation

The two new jobs run on ubuntu-latest instead of upstream's blacksmith-8vcpu-ubuntu-2404, matching the GitHub-hosted move in 124630c3f. The macos-26 build runner is unchanged. Nothing else needed adapting — cherry-picked clean otherwise.

Pylon-specific checks

• No auto-updater interaction. Pylon publishes desktop releases and the updater feed to pylon-code/pylon-releases (per the PYLON_DESKTOP_UPDATE_REPOSITORY variable). The preview release lands on pylon-code/pylon, which has zero releases, so the nightly channel's allowPrerelease: true never sees it. Publishing to the releases repo instead would have been the dangerous option.
• No release-workflow collision.release.yml only matches v*.*.* tags; desktop-preview does not match.
• --target "$DEFAULT_BRANCH" resolves correctly — the repo default branch is pylon.
• The -pr.N. marker exists. Pylon's version step already produces ${base_version}-pr.${PR_NUMBER}.${GITHUB_RUN_NUMBER}, which the anti-clobber guard depends on.
• actionlint 1.7.12: clean on pylon and clean on this branch.

Two things to decide

1. The preview:mac label does not exist on this repo. Every run of this workflow to date has been skipped for that reason, so the feature is currently inert — before and after this change. It needs the label created before it does anything. I did not create it; say the word and I will.
2. pylon-code/pylon currently shows no releases at all. After the first preview build, its releases page and homepage sidebar would advertise an unsigned preview DMG as the repo's only release, while real builds continue to live in pylon-code/pylon-releases. That is cosmetic, but it is the one judgment call here.

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	+12 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+7 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+5 B (+0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.5 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−2 B (−0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+2 B (+0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−4 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: 9d11232 · 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 found four ways this could leave a wrong final state behind a green check. All fixed in 9d112329e. Every one is inherited from upstream rather than introduced by the Pylon adaptation, and every one traces to the same root cause: treating a failed API call as an answer.

The root cause.preview_eligible() was [[ "$(gh pr view ...)" == "OPEN true" ]]. Under set -euo pipefail, a command substitution that fails inside a condition does not trip errexit — it just yields an empty string. Confirmed locally: a failing gh produces "treated as ineligible" and the script still exits 0. So a transient 502 is indistinguishable from "the PR closed", and the two jobs then fall in opposite directions:

• publish silently no-ops after a ~25-minute macOS build, logging a message that is actively false; or, on the post-upload re-check, deletes the asset it just uploaded while the PR is open and labeled — leaving the existing comment pointing at a 404 with no event left to fix it.
• cleanup falls the other way: empty string is not "OPEN true", so it proceeds to delete a live download during an unlabel→relabel race.

Both now go through a preview_state helper that retries, distinguishes "no answer" from "not eligible", and refuses to act on a guess. It is duplicated in both jobs on purpose — neither may check out the repo, so there is no file to source.

Cleanup could not honor its own promise. It wrote removed=truebefore inspecting the release, could not tell a missing release from a broken API (gh release view >/dev/null 2>&1 collapses 404 and 502), and swallowed every delete error as "already removed by a concurrent run". A 502 there left a public DMG downloadable forever while the comment claimed it was gone — the exact one-way door AGENTS.md calls a bug. It now distinguishes 404 from failure, tracks whether deletes actually succeeded, fails loudly if any did not, and only claims removal once it is true.

Publish deleted before uploading. The header comment reasons carefully that a cleanup must never be cancelled mid-delete — but publish deletes too, and unlike cleanup it sits in the build concurrency group, where synchronize evaluates cancel-in-progress: true. A push landing between the delete and the upload leaves a 404 in the comment for the length of the next build. Asset names carry GITHUB_RUN_NUMBER, so uploading first and pruning after closes it with no behavior change.

Unlabel-then-close could strand a DMG permanently. GitHub cancels a pending run when a newer one joins its group. Both events share the cleanup group, so a queued unlabel cleanup gets cancelled by the close event — and the close branch's if required preview:mac, which is now gone. Nothing would ever delete that asset. The closed branch no longer requires the label; the job is idempotent and keyed by -pr.N., so an unrelated close finds nothing and stops.

Filename hardening. The DMG name comes out of the build, which runs PR code, and becomes a release asset name, a public URL, and Markdown in a bot-authored comment. A name like x-pr.42.7)](https://evil.example)(.dmg satisfies the old substring guard and escapes the link. It is now pinned to ^[A-Za-z0-9][A-Za-z0-9._-]*\.dmg$.

Verification. Both run: bodies were extracted and executed against a stubbed gh: 7 cleanup cases (deletes succeed / relabeled / PR API down / no release / release API down / asset already gone / delete 502) and 7 publish cases (happy path / closed during build / API down / markdown-escape name / wrong PR marker / no DMG / prune selectivity). The prune deletes only the stale pr.42.6 — never its own pr.42.7 upload, never PR 99's asset. actionlint reports 0 findings including shellcheck.

Confirmed clean and left alone: the -pr.N. trailing-dot reasoning genuinely holds (-pr.12. matches neither -pr.1. nor -pr.123.); the privilege boundary is sound (pull_request, not pull_request_target; build keeps contents: read; all attacker-controlled values reach github-script via env:, never ${{ }} inside run:); size:* label churn cannot trigger this workflow at all, because GITHUB_TOKEN-authored label events do not start runs; and the auto-updater cannot see the rolling prerelease, since it uses provider: "generic" and real releases live in pylon-code/pylon-releases.

Still blocking real use: the preview:mac label does not exist on this repo, so the build has never once executed here. That also makes archive: false on the artifact upload an untested assumption — if it is wrong, pattern: "*.dmg" matches nothing and the run dies loudly at "No DMG found", which is fail-safe but means the first labeled PR is the test. Worth driving one PR through label → push → unlabel → relabel → close before trusting this.