Withdrawn: unnecessary scheduled Bun cache change

[luvs01]

Summary

Withdrawn after rechecking the checkout reference and the CodeQL query. The initial diagnosis of alerts #243/#244 was incorrect for this fork; this patch should not be merged.

• In the scanned commit 6da2774369aa32552e318e333902499683d053bc, changes.nightly emits an empty checkout_ref for every event except schedule. The pinned actions/checkout interprets an empty ref as the workflow event's ref/SHA.
• On schedule, the job resolves only repos/${GITHUB_REPOSITORY}/commits/dev and validates the returned SHA. The fork's actual default branch is dev, so this is not an external PR head or a lower-trust dispatch input.
• workflow_dispatch exposes only the lane choice; it does not accept a checkout revision. A pull request's job outputs are not reused by a scheduled or dispatched run.
• Disabling setup-bun's cache does not revoke the job's Actions runtime cache access. It therefore would not remedy execution of genuinely untrusted code in a cache-write-capable job.

Alerts #243/#244 are false positives for the examined data flow. No workflow, security configuration, or CI gate change is needed.

Verification

• Traced both flagged jobs to changes.outputs.checkout_ref and the complete producer at ci.yml lines 531–548.
• Confirmed the fork's default branch is dev through the repository API.
• Checked empty-ref handling in the exact pinned checkout input helper.
• Read CodeQL's CachePoisoningViaPoisonableStep.ql and UntrustedCheckoutQuery.qll: the finding concerns executing untrusted code with runtime cache access, not the presence of a particular cache-saving action.
• The earlier 141 passing workflow tests validated workflow structure; they did not establish the original security diagnosis or that this patch closes either alert.

Checklist

• Scope and data flow rechecked.
• Earlier diagnosis and fix claim corrected.
• Proposed workflow change withdrawn rather than used to silence findings.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Repository: luvs01/opencodex/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: cbbb57e6-67f6-481d-bddf-7c7d3e655aaf

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[luvs01]

Residual note for security review: this change closes the only Actions-cache writer on the affected jobs (setup-bun's executable cache). The broader invariant is that any ci.yml job honouring needs.changes.outputs.checkout_ref must never write to the Actions cache on schedule, because the checked-out ref differs from the run's own ref while the cache scope stays the default branch's. A future actions/cache step or another caching action added to those jobs would reopen the same chain — worth a tests/ci-workflows/ assertion if reviewers want it enforced rather than documented.

[github-actions]

✅ Deterministic PR hygiene checks passed.

[luvs01]

Correction to my earlier diagnosis and residual-risk comment: the flagged checkout does not consume an untrusted revision in this fork. On workflow_dispatch, checkout_ref is empty and the pinned checkout uses the event ref/SHA. On schedule, the producer resolves the repository's hard-coded dev head; dev is this fork's default branch. There is no PR-head, artifact, or dispatch-input revision flowing into those checkouts.

Also, no-cache only disables setup-bun's cache use; it does not revoke the Actions runtime cache access available to executed code. My earlier statement that this change closes the cache-poisoning chain was incorrect.

I am withdrawing this PR and dismissing #243/#244 as false positives with the data-flow rationale. The earlier local workflow-test pass was not evidence that either security alert was fixed. No workflow or CI gate change is required.