A dependency cache can save minutes on a build. It also carries files from one run to another, so deciding which jobs can write it is part of the pipeline's trust model.
GitHub's 10 September 2026 update introduces cache-mode at workflow and job level. The feature is generally available on github.com across all GitHub plans.
Choose the access the job needs
The four modes are read, which restores without saving; write, which restores and saves; write-only, which saves without restoring; and none, which disables cache access.
Job settings override workflow settings. A reusable workflow cannot receive more cache access than its caller grants.
GitHub warns that explicitly granting write access can override the read-only default for low-trust events such as pull_request_target. It adds a warning annotation in that situation.
Review who can influence the stored files
Start with jobs that process outside contributions or run scripts controlled by someone other than the release team. Identify what those scripts can place in a cache and which later jobs might restore it.
For example, a team might want a contributor's test job to read a dependency cache while reserving cache creation for a trusted branch build. The right choice depends on the workflow and the way its files are consumed.
Check the complete route through reusable workflows. A cache step inside another file can be easy to overlook when reviewing the main pipeline.
Keep the build reproducible without the cache
Our suggested check is to run the job with no restored cache in a test branch. It should still install the intended dependencies and produce the expected result.
A pipeline that succeeds only with yesterday's cached files may be hiding missing installation steps or undeclared dependencies. Fix that before relying on a new access policy.
Keep lock files and the normal dependency installation process in place. A faster job needs the same confidence in its inputs as a fresh build.
Measure the effect on ordinary work
Test a proposed setting on representative pull requests and branch builds. Check success, duration, cache hits and which jobs create new entries.
If a job slows down, establish whether it lost a useful restore or whether it now correctly avoids writing an unnecessary cache. Those are different changes and need different decisions.
Keep the final policy short enough for a maintainer to explain. Record why a job can write, and revisit it when its trigger or scripts change.
Cache-mode gives teams a more direct way to express trust in cached data. Use it alongside a review of the files and jobs involved, then verify that an uncached build still works.
Reporting checked on 13 October 2026.
