What changed
GitHub made `cache-mode` generally available on September 10, 2026. Workflows and jobs can declare `read`, `write`, `write-only` or `none`, and GitHub's cache service enforces the resulting scoped cache token. Low-trust triggers such as `pull_request_target` default to read-only cache access, while trusted triggers such as `push` default to write. Explicit caller limits propagate into reusable workflows; a called workflow cannot request more cache capability than an explicit caller limit permits. GitHub also warns when a low-trust workflow explicitly restores write capability, because doing so reintroduces cache-poisoning risk.
Why it matters
CI caches can contain executable build artifacts or dependencies that later privileged jobs trust. That makes a writable shared cache a supply-chain boundary, not merely a performance feature. `cache-mode` lets teams express that boundary in the workflow permission model: untrusted jobs can be prevented from poisoning caches, cache-producing jobs can be prevented from restoring potentially hostile entries, and reusable workflows can be capped by their callers. This is especially useful in repositories that run automation on external pull requests or share workflow components across teams.
Cache access has four explicit capabilities
`read` permits restores but not saves, `write` permits both, `write-only` permits saves without restores, and `none` disables both. Job-level settings can narrow or override workflow-level settings.
Low-trust events get safer defaults
GitHub applies read-only access to low-trust triggers that resolve against the default branch, including `pull_request_target`, `issue_comment` and `workflow_run`. Those jobs can consume existing cache entries but cannot replace them unless a workflow explicitly opts back into write access.
Reusable workflows cannot silently escalate an explicit limit
An explicit cache-mode on a calling workflow or job constrains the called reusable workflow. If the callee asks for a capability outside that limit, GitHub rejects the run rather than quietly granting broader access.
Write-only is useful for one-way cache production
A job can now publish a cache without first restoring anything from the shared cache. That gives security-sensitive pipelines a way to separate cache creation from cache consumption instead of treating both as one permission.
Overrides remain deliberately dangerous
A workflow can explicitly grant write capability to a low-trust trigger, but GitHub warns that this defeats the secure default and can reopen cache-poisoning attacks. The control is therefore an enforcement primitive, not a guarantee that every declared policy is safe.