github action: cache step warns on issue_comment runs (read-only cache access) — use actions/cache/restore?

Summary

The github action's composite caches the installed CLI with actions/cache (save + restore):

# github/action.yml
- name: Cache opencode
  id: cache
  uses: actions/cache@v4
  with:
    path: ~/.opencode/bin
    key: opencode-${{ runner.os }}-${{ runner.arch }}-${{ steps.version.outputs.version }}

Two of its supported triggers, issue_comment and pull_request_review_comment, are treated by GitHub as
low-trust, so runs triggered by them get read-only cache access (a cache-poisoning defense). On those runs the
cache step's save is denied and logs a warning, and the cache was never populated across our runs, so each
comment-triggered run re-downloads the CLI.

Evidence

A real run — anomalyco/opencode/github@latest, ubuntu-latest, trigger issue_comment, CLI v1.18.31:

# setup
Cache mode: read

# run step
Cache not found for input keys: opencode-Linux-X64-v1.18.31

# post-run
##[warning]Cache reservation failed: cache write denied: token has no writable scopes
Failed to save: Unable to reserve cache with key opencode-Linux-X64-v1.18.31, another job may be creating this cache.

The failure is expected for a read-only run: GitHub's dependency-caching reference says "the save fails but the step and
the job do not. The workflow continues, and the failure is reported as a warning in the workflow log."

The docs also promise a skip, not a failed save

The same page's cache-mode section describes a mode-blocked save as skipped:

When a cache operation is skipped because of the mode, the action logs an informational message and the step and run
continue without failing. … a skipped save is simply not performed.

and says the mode is enforced through ACTIONS_CACHE_MODE, which the docs state the actions/cache action and the
@actions/cache toolkit honor. With the currently pinned actions/cache@v4 the save is attempted and errors instead.

Could the cache step be updated so the read-only case is skipped cleanly rather than warning? The docs' own
recommendation for low-trust workflows is a restore-only operation — "switch to a restore-only cache operation such as
actions/cache/restore … to make the intended cache usage clear and avoid the warning in the workflow run logs" — which
would also be a fine fix for the comment path.

Not a permissions problem

The same page lists the only triggers that may create or overwrite caches (push, workflow_dispatch,
repository_dispatch, delete, registry_package, page_build, schedule) and states that runs from any other event
resolving to the default branch — "such as pull_request_target, issue_comment, and workflow_run" — are read-only.
So the job token's actions scope is irrelevant; the documented opt-out is a write-capable cache-mode, which the docs
warn "reintroduces the risk of cache-poisoning".

Reproduction

1. Install the app on a repo and add the documented workflow (issue_comment + pull_request_review_comment,
   permissions: id-token: write).
2. Comment /oc hi on any issue.
3. The run succeeds but logs the warning above, and the CLI is re-downloaded on each run.

Related

#40101 ("Update github/actions/cache to v6") is closed, but github/action.yml on the current default branch still pins
actions/cache@v4, so the runner also warns that it targets Node 20 (forced onto Node 24) on every run.