Help Us Improve GitHub Actions Cache Isolation 🔧

[samus-aran]

Actions Cache

TLDR;

• We’re exploring a new cache-mode setting for GitHub Actions Cache at the workflow and job level.
• The goal is to reduce cache poisoning risk while keeping today’s behavior as the default.
• Proposed values: write, read, and none.
• We’re looking for feedback on naming, usability, migration, and visibility.

---

Hi everyone 👋

We are exploring a change to GitHub Actions Cache and we want your opinion before we finalize the design. This post focuses on the first phase of work. Please share thoughts, concerns, and alternatives in the comments.

The problem

If you use GitHub Actions Cache today, every workflow that runs on your repository can write to the same shared cache namespace for a branch. That includes workflows triggered by pull requests, issue comments, scheduled jobs, and AI or agent driven workflows that may execute untrusted input.

Note on existing protections. Actions Cache already enforces some scoping rules today. In particular, a workflow run from a pull request branch cannot read or overwrite cache entries on a protected base branch such as main. See Restrictions for accessing a cache for the current behavior. The proposal in this document is about giving workflow authors an explicit, declarative control on top of those existing scoping rules, so a workflow can opt out of cache writes (or cache access entirely) regardless of trigger.

The cache credential (ACTIONS_RUNTIME_TOKEN) is handed to every workflow run automatically. It is issued independently of:

• the permissions: block on your workflow or job,
• the secrets you have or have not exposed,
• the runner you choose, and
• any other workflow hardening you have already done.

That means a workflow you consider untrusted can still place content into the cache (within the scoping rules linked above). A later workflow you consider trusted, such as your release pipeline, may then restore that content as part of its build. The workflow ends up consuming inputs it never produced and never reviewed.

The customer impact:

• Your release builds can be influenced by code paths you never intended to trust.
• Build attestations such as SLSA provenance or Sigstore signatures still pass, because the build ran where and when you said it would. They do not detect that the inputs were tampered with through the cache.
• You currently have no workflow level switch to say "this workflow is allowed to read cache but not write it" or "this workflow should not touch the cache at all."
  Independent security research by Adnan Khan has documented how these scoping rules can still be bypassed in practice — see CI/CD Pipeline Cache Poisoning and Compromising Angular via the Dev Infrastructure for concrete examples. This proposal gives workflow authors an explicit, declarative control on top of those existing scoping rules.

We want to close that gap, and we want to do it in a way that does not break the workflows you have today.

What we are proposing

A new key called cache-mode that you can set at the workflow level, the job level, or both. It accepts three values:

Value	Behavior
write	Restore and save are both allowed. This is the current behavior and remains the default.
read	Restore is allowed. Save is rejected by the cache service.
none	No cache access at all.

Key properties of the proposal:

• Default stays as write. Nothing changes for existing workflows unless you opt in.
• Job level overrides workflow level. You can set a safe default for the whole workflow and relax or tighten it on specific jobs.
• Enforcement happens in the cache service. When cache-mode is read or none, the runtime token issued for the job carries restricted cache claims. The cache service validates them. No action, script, or step can bypass the declared mode.
• Existing branch scoping is preserved. This proposal layers on top of the existing cache scoping rules; it does not loosen them.
• Runtime signals are exposed so workflow authors and action authors can adapt:
  • Expression context: job['cache-mode'] (use bracket syntax because the key contains a hyphen)
  • Environment variable: ACTIONS_CACHE_MODE with value read, write, or none

Setup actions such as actions/setup-node or actions/setup-python can read ACTIONS_CACHE_MODE during their post job step and skip the tar and compression work entirely when writes are not allowed, so you do not pay for I/O you cannot use and you do not see confusing authorization errors in your logs.

Example workflows

Scenario 1. Workflow level default of read for a pull request check

File: .github/workflows/pr-check.yml

name: PR Check
on: pull_request

# This whole workflow can restore from cache but cannot write to it.
cache-mode: read

jobs:
  pr-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm test

Scenario 2. A single job overrides the workflow default to none

File: .github/workflows/pr-check-isolated.yml

name: PR Check (isolated job)
on: pull_request

cache-mode: read

jobs:
  pr-check:
    runs-on: ubuntu-latest
    # This job runs untrusted input. Give it no cache access at all.
    cache-mode: none
    steps:
      - uses: actions/checkout@v6
      - run: ./scripts/run-untrusted.sh

Scenario 3. Trusted release job explicitly opts into write

File: .github/workflows/release.yml

name: Release
on:
  push:
    branches: [main]
  workflow_dispatch:

# Default the workflow to read only...
cache-mode: read

jobs:
  build:
    runs-on: ubuntu-latest
    # ...but allow the release build to populate the cache.
    cache-mode: write
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run build
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Scenario 4. Runtime detection for conditional cache saves

File: .github/workflows/conditional-save.yml

name: Build with conditional cache save
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - id: cache-restore
        uses: actions/cache/restore@v6
        with:
          path: ~/.cache/build
          key: build-${{ hashFiles('**/lockfile') }}

      - run: ./scripts/build.sh

      # Only attempt to save when this job is actually allowed to write.
      # Note: bracket syntax is required because the key contains a hyphen.
      - if: ${{ job['cache-mode'] == 'write' }}
        uses: actions/cache/save@v4
        with:
          path: ~/.cache/build
          key: build-${{ hashFiles('**/lockfile') }}

Scenario 5. Agentic Workflows that should never write cache

GitHub recommends running AI agents inside Agentic Workflows rather than wiring "naked" agents directly into ordinary workflows triggered by issue_comment or similar events. Agentic Workflows already provide isolation and policy controls for untrusted natural language input. cache-mode: none is a complementary defense in depth: even an Agentic Workflow that would not normally need cache access can declare it explicitly, so the cache surface is removed entirely from the agent's environment.

File: .github/workflows/agentic.yml

name: Agentic Workflow
on: workflow_dispatch

# Defense in depth: this workflow has no business touching shared cache.
cache-mode: none

jobs:
  agent:
    runs-on: ubuntu-latest
    permissions: {}
    steps:
      - uses: actions/checkout@v6
      - run: ./scripts/run-agent.sh

Questions we want your opinion on

1. Naming. Is cache-mode the clearest name, or is there a name that would communicate the intent better? What alternatives have you considered?
2. Values. Are read, write, and none the right set, or do you need finer granularity such as per key or per scope rules?
3. Action authors. If you maintain a setup or cache style action, is reading ACTIONS_CACHE_MODE in your post job step workable for you? What is missing, awkward, or duplicative with what you already do?
4. Visibility. How (if at all) would you want the effective cache-mode surfaced outside the workflow file, for example in run summaries, the API, or audit logs? What problem would that solve for your team, and where would extra surface area get in the way?
5. Migration. What does adoption look like in your repos today? Are there workflows where you would not adopt this even if it were available, and why? What tooling, defaults, or guidance (if any) would change that calculus?

Note

Phase 1 only ships the workflow level cache-mode key, which means any author can opt in today without admin involvement. We know that to make read a secure default across an org or enterprise, admins also need a policy control. Something like a per org default value plus an allow list of repos or workflows that may declare write. We are intentionally scoping that out of Phase 1 so we can get the workflow contract right first, but we want your input on what that policy surface should look like. See question 6 below.

If something here does not match how your team uses Actions Cache, we want to hear it. The goal of Phase 1 is to give you a switch you can use today without forcing changes on anyone who is happy with the current behavior.

Thanks for reading 🙏

[AdnaneKhan]

This is a great start!

Some feedback:

• Please allow repository or organization administrators to set repository level default cache modes and expose this setting via an API. If the workflow does not configure a setting, then the workflow uses this repository level value. This makes it easier to cut down on risk on non-caching workflows being able to poison caches because someone back-doored an upstream.
• The options should be: read, write (ONLY write, does not have a restore hit), read-write, and none.

If a workflow has a setting like the one in the example then a nightly build that uses cache write (common and probably desired) could end up poisoning a workflow such as the below.

   runs-on: ubuntu-latest
    # ...but allow the release build to populate the cache.
    cache-mode: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run build
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

To encourage true SLSA L3 compliance the guidance for publication should be to not use caching or use it in write mode. Even better? The NPM CLI should create a warning when it is publishing to NPM in a workflow with cache consumption & the workflow had a cache hit prior.

• The cache mode should be included in Sigstore transparency logs (so part of the JWT) so downstream users can easily verify the cache exposure risk of packages published to registries with provenance.

[AdnaneKhan]

@ericsciple certainly!

The use case I envision for a write-only token is a repository that performs releases from the main (or other default) branch along with strict pull request approval requirements and deployment environment controls. This workflow could set a "golden cache" entry that nightly workflows, pull requests, etc. have cache hits from.

Write-only cache permissions won't be perfect for every use case; but this approach (when deployed properly) would allow teams to have similar integrity assurance for their main branch caches as they do for release artifacts.

Additionally; I hope GitHub considers a more aggressive approach to cache security for public repositories by defaulting to no caching after a period of time. Perhaps after 6 months any workflows without cache permissions set would default to no cache access. Otherwise the problem never really goes away because LLMs generate workflows without caching, they work fine, and these risks continue.

[ericsciple]

@AdnaneKhan I'm wondering if CI on main would typically read/write the cache instead. Updating the cache on main CI would produce a better cache hit for PRs, rather than waiting for a release to update the cache.

[slorber]

Agree with Adnane, we need a way to be secure by default. Most OSS organizations are not aware of the risk of shared caches, and only discover these issues too late. See for example a TanStack maintainer, whose org was compromised yesterday: https://x.com/AlemTuzlak/status/2054125747271283081

---

Before even implementing these new measures, maybe a good start could also be to actually document and recommend to disable caching in publishing workflows?

https://github.com/actions/setup-node

    # Used to specify a package manager for caching in the default directory. Supported values: npm, yarn, pnpm.
    # Package manager should be pre-installed
    # Default: ''
    cache: ''

    # Controls automatic caching for npm. By default, caching for npm is enabled if either the devEngines.packageManager field or the top-level packageManager field in package.json specifies npm and no explicit cache input is provided.
    # To disable automatic caching for npm, set package-manager-cache to false.
    # default: true
    package-manager-cache: true

This doc is not super clear to me (in particular, what cache: '' default means?), but as far as I understand, npm caching is always enabled by default if cache: '' (=== "no explicit cache input provided"?).

---

That action has an npm Trusted Publishing section with an example workflow.
A good first step could be to explicitly disable caching in these documentation examples.

• https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#publishing-to-npm-with-trusted-publisher-oidc
• Trusted Publisher documentation actions/setup-node#1445 (comment)

Here it's for Node, but I'm sure documentation for other ecosystems doesn't disable that cache either.

Documentation is great, but of course, measures to be secure by default are always better.

[thusoy]

@ericsciple if the main workflow is granted read-write, you wouldn't be able to tell if the build was clean anymore, as it might have pulled in malicious artifacts from the cache. If builds on main run with write-only permissions you can guarantee that you don't have persistence through cache artifacts (as demonstrated by https://github.com/adnaneKhan/cacheract), and other branches can be read-only and you'd know they only pull clean artifacts from the trusted build on main.

[ericsciple]

@thusoy in that case would the release workflow read from cache? I'm thinking no, but interested to understand more.

[pinfloyd]

This looks like the right direction.

One framing that may help: cache access is not only a performance feature. It is an execution authority surface. If a workflow can write to a shared cache, it can influence future executions that may run in a more trusted context. That means cache-mode is effectively part of the authority granted to the workflow before execution starts.
From that angle, I think read, write, and none are useful, but I would strongly consider separating “restore” and “save” semantics explicitly. A workflow that can save but not restore is not the same risk profile as one that can restore and save. I also agree with exposing the effective cache mode outside the workflow file. For provenance, audit, and downstream verification, it would be useful to know whether a published artifact was built after consuming cache, writing cache, or with cache fully disabled.

So my main suggestion is:

make the effective cache authority visible before execution and record it after execution. That would make cache-mode not just a workflow option, but a pre-execution admission signal for whether this run should be allowed to interact with shared cache at all.

[jsoref]

This is off-topic, but please note that your examples are pinned to checkout@v4 just like actions/starter-workflows: https://github.com/search?q=repo%3Aactions%2Fstarter-workflows+checkout%40v&type=code -- it's a great example of github poisoning everyone's cache by pinning garbage.

The actions team could do the world a service by fixing the starter-workflows repository to be remotely current. Then fewer people would pay money to run dependabot to update to remotely current versions of things like actions/checkout. And similarly, Agents would be less inclined to suggest using actions/checkout@v4 (which they regularly do).

[jsoref]

The idea of a none is welcome. I'd rather cache or caching than cache-mode if only to avoid having to use ['cache-mode'] which is such a PITA.

cache: readable | writable | none

Not using read / write helps avoid confusion with permissions fields as this isn't a permissions field.

Personally, I've removed all use of cache from my action a long time ago because it's too dangerous and the speedup it gets wasn't worth the risk it introduced. (For bigger systems, the problem is more interesting.)

In general, I don't think I like the cache model at all. Unless I can access the contents of the cache to inspect it later, it's useless to me. And the core problem w/ the cache is that people can flush it and race it and things. My approach has been to use persistent stores instead because those give me the properties I care about. -- I can achieve more of that today by using immutable releases and just making a releases out of any artifact I want to reuse.

• If you have time to work on cache, please provide a way to download the cache Add a way to download github actions caches cli/cli#9125 (preferably from the web ui, not something that requires gh).

[hardikkaurani]

This is a really valuable improvement direction, especially for supply-chain security and reproducible CI/CD pipelines.

One additional improvement that could help significantly is adding cache provenance visibility. Right now, workflows can restore caches without clearly showing:
• which workflow originally created the cache
• which branch populated it
• whether the cache came from a trusted or untrusted context

Having that metadata exposed directly in workflow logs or the Actions UI would make debugging and trust decisions much easier.

I also strongly agree with the concern around cache poisoning risks in release or publishing workflows. In many projects, caches are restored before publishing artifacts or packages, which can become risky if upstream dependencies or cache writers are compromised.

GitHub’s current cache documentation already mentions branch-scoped behavior, but more granular trust controls would be extremely useful:
https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

Some ideas that could improve this further:
• allow restoring caches only from protected branches
• separate cache trust policies for fork PRs
• workflow-level cache isolation
• organization-wide cache policy defaults
• warnings when cache restore + package publishing happen in the same workflow

Another useful enhancement could be exposing cache provenance through the API, similar to artifact metadata, which would help larger organizations audit CI behavior more effectively.

From a SLSA and software supply-chain perspective, this direction makes a lot of sense:
https://slsa.dev/

Overall, this looks like a strong step toward safer and more predictable GitHub Actions caching behavior.

[hardikkaurani]

This is a really valuable improvement direction, especially from a supply-chain security and CI integrity perspective.

One thing that could improve this proposal even further is adding cache provenance visibility directly inside the Actions UI and API. Right now, when a workflow restores a cache, there is very little visibility into:
• which workflow originally created the cache
• which branch or trigger populated it
• whether the cache came from a trusted or untrusted execution context
• when the cache was last modified

Exposing that metadata would make debugging and trust decisions significantly easier for maintainers and security teams.

I also strongly agree with the concern around cache poisoning risks in publishing and release workflows. Many projects restore dependency caches before publishing artifacts or packages, and that can become dangerous if less-trusted workflows are able to influence shared cache state.

The proposed direction of separating cache authority from general workflow permissions makes a lot of sense. In practice, cache access behaves more like an execution trust boundary than just a performance optimization feature.

Some additional ideas that could strengthen this further:
• allow restoring caches only from protected branches
• organization-wide default cache policies
• separate cache trust behavior for fork PR workflows
• cache provenance visibility in workflow summaries
• audit log support for cache writes/restores
• warnings when package publishing occurs after restoring shared caches

It may also be useful to expose cache provenance information through the API, similar to artifacts metadata, so larger organizations can audit CI behavior programmatically.

Relevant references:
https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
https://slsa.dev/

Overall, this feels like a strong step toward safer and more predictable GitHub Actions caching behavior without breaking existing workflows.

[wrslatz]

A couple quick points

• maybe cache-permission or cache-access would be clearer than cache-mode, though not by much
• being able to restrict workflows further to accessing specific cache keys, both read and write, would add an extra layer of security support when needed

[vilkinsons]

Feels like this should be... prioritized (even at the risk of short-term disruption to workflows). Glad to see this on the docket.

[SeanCassiere]

Couple of questions on my end:

1. By "reject", does this mean that an exception will be thrown? or would it silently error out.

2. What happens if cache is being done as part of another vendor's workflow?
   a. For example, your org/repo has a single workflow named "scaffolding" that does tooling setup like environment, dependency installation, and most importantly caching work (like dependencies for speedier installs).
   b. As you can imagine this wouldn't be that uncommon if your have multiple isolated workflow that need the same prep-work on the runner before the individual workflows need to do their thing.

[jsoref]

I'm fairly confident it won't kill a workflow. Whether it will silently ignore the cache request or noisily ignore the cache request is unclear from the description. Personally, I'd probably want to be able to see the dropped requests but not have them appear as annotations by default. They're likely to be almost never remotely interesting to anyone. So if people are curious, they should have to opt in (e.g. w/ ACTIONS_STEP_DEBUG).

cache mode as suggested above is on a per workflow file basis. So if you're actually using multiple workflows, each would have its own setting.

The problem w/ the design proposed here is that you're going to have to maintain two diverging copies of your workflows, one for testing where you want caching, and one for releasing where you don't (because you want security for your releases). And I guarantee that most will not do a good job of managing this.

[SeanCassiere]

And I guarantee that most will not do a good job of managing this.

Definitely agree on that last point there.

I'm not sure about the happy medium here, but I just want to make sure that whatever comes out, wouldn't just make any existing "setup" workflows outright useless anymore.

Copy-pasting the same config across workflows has its own problems involved. Drift and trusting that a copy was done correctly are the two immediate ones that come to mind. Also, a single "setup" style workflow allows you to restrict at the hash level across the consumer-workflows plus restricting edit of "setup" using CODEOWNERS.

Again, nothing perfects, but definitely safer than copy-paste.

[joshamaju]

If any workflow can set cache-mode: write, then how does that solve the problem. Won't a malicious user just use that?

[jsoref]

write is effectively the legacy (compatible) behavior.

The goal would be to let new workflows be designed to use the new none feature to protect them from other careless workflows in the repository or reckless actions.

[AdnaneKhan]

Yup!! And before anyone argues about breaking changes let's not forget that GitHub broke people for a backend upgrade as part of the Cache v1 deprecation with ~1-2 months notice for some of the latest tags on older major versions.

[jsoref]

@samus-aran I'd like the attestations system to be changed to record any workflow that reads a cache entry as "poisoned" that would be a useful attestation. I bet that's doable.

[fungilation]

less talk, more action. This should be fixed yesterday.

https://x.com/garyfung/status/2054030851768467853

[anarazel]

FWIW, I would like to have the option to decrease the isolation of caches between a set of branches. In postgres we have a number of stable branches (we support 5 years of older major versions) that have caches that are crucial for performance (decreasing time of a step from ~20min down to 5s). The caches are identical between most of the stable branches. Yet the cache isolation rules mean that we end up wasting a lot of space storing the same thing over and over.

[armorer-labs]

One useful way to frame this is that cache access is a pre-execution capability, not just a build-speed setting. That matters more as repos start running agentic workflows, because the workflow may be reacting to issue text, PR text, tool output, or generated patches that the maintainer has not reviewed yet.

A few practical asks from that angle:

• expose the effective cache mode in the run metadata/API, after defaults and org/repo policy have been resolved
• separate restore and save capability explicitly; read-write, read-only, write-only, and none are easier to reason about than a single overloaded write mode
• include cache restore/save decisions in provenance or attestations for release/publish workflows, so downstream systems can tell whether the artifact consumed mutable cache state
• let org/repo admins set a default for agent-triggered or untrusted-input workflows, instead of relying on every workflow author to remember the safer setting
• make cache misses caused by policy visible without turning every intentionally disabled cache call into noisy annotations

For agent workflows specifically, the failure mode I worry about is not only cache poisoning from an outside PR. It is an autonomous run repeatedly executing generated code and carrying forward state that later looks like ordinary CI acceleration. A resolved cache-mode receipt would make that boundary much easier to audit after the fact.

Disclosure: I work on Armorer Labs.

[gregose]

FYI, we have shipped read-only defaults for a majority of triggers that run on the default branch. Read more at https://github.blog/changelog/2026-06-26-read-only-actions-cache-for-untrusted-triggers/. Customizing cache permissions is still coming, but we wanted to prioritize getting these secure defaults out the door first.

[fredleger]

There are so many breaking changes in GitHub lately ... One thing work a day and break in the morning.
This is clearly showing a lack of consideration for end users that lost their time debugging before finding the right blog post ....

IMHO GitHub should follow a better depreciation/warnings/changes workflow...

I leave this link here just to emphasize where end users are: https://mitchellh.com/writing/ghostty-leaving-github
and https://mrshu.github.io/github-statuses/

They focus more on availability but this is a related topic...
GitHub listen to your end users ... AI course is one thing ... breacking foundation is another ...

My 2 cents

[gtjoseph]

We only use caches for passing build products between jobs in a single workflow but now all of those workflows fail because they're triggered by pull_request_target. So now we're forced to jump through hoops to continue to use caches because someone decided to solve a security problem we don't even have.

Maybe a better approach would have been to not let trusted workflows use caches created by untrusted ones instead of preventing untrusted ones from creating caches only they will use.

Every day it's something else. ☹️

[jsoref]

Ok, at the very least you aren't following best practices in that you're using ${{ ... }} in run: statements -- at least in https://github.com/asterisk/asterisk-ci-actions/blob/main/.github/workflows/AsteriskPRMerge.yml -- that's just asking for trouble.

[jasongin]

@gtjoseph I understand your frustration, and I'm sorry this caused trouble for you. In this case we considered the benefit of closing a major security vulnerability was high enough to justify the impact to a very small number of workflows. This change generally has minimal or no impact to workflows that are using the cache correctly, that is as a performance optimization to avoid repeatedly downloading or re-generating files that are used across multiple workflow runs.

We only use caches for passing build products between jobs in a single workflow

That is not what the Actions cache is designed for. From Artifacts versus dependency caching:

• Use caching when you want to reuse files that don't change often between jobs or workflow runs, such as build dependencies from a package management system.
• Use artifacts when you want to save files produced by a job to view after a workflow run has ended, such as built binaries or build logs.

While that second bullet doesn't specifically mention "passing build products between jobs" (though I think it should), that is covered in the docs about artifacts. See Passing data between jobs in a workflow. (If you adopted cache-as-handoff back when upload/download-artifact@v3 was slow, v4 had major performance improvements, so it's worth re-benchmarking now.)

if I'm reading the changelog entry correctly, pull_request also loses read-write access when coming from forked repos.

No, unlike pull_request_target, a pull_request workflow runs with the PR branch as its context and therefore has cache write access only to the PR branch scope. So pull_request workflows were already blocked from writing to the default branch cache scope. See Cache access for low-trust workflow triggers:

The pull_request event is not affected...

[gtjoseph]

I've now converted our workflows to use artifacts but the reason we used caches instead of artifacts in the first place is that you can't easily re-run failed jobs that need artifacts from the original run. The failed job would need the id of the original run and, more seriously, a github token with appropriate permissions. So if a workflow has 1 build job and 20 test jobs and one of those test jobs fails, we can't just re-run the failed job.

I take this back! Apparently rerunning a single job in a workflow run doesn't count as a different "workflow run". Learn something new every day.

As for pull_request, until GitHub allows workflows triggered by pull_request events for PRs from forked repos, we're stuck. See #44322 Every workaround for that just plain sucks. For the sake of argument however, define "default branch cache". If we have a repo with master as the default branch and Alice submits a PR from her fork and branch master-my-change targeting the upstream master branch, is that allowed for pull_request?

[jasongin]

I get the feedback about variables not flowing to fork PR workflows. It's unfortunate that hasn't been prioritized, but discussion for that belongs in the linked thread, not here.

If we have a repo with master as the default branch and Alice submits a PR from her fork and branch master-my-change targeting the upstream master branch, is that allowed for pull_request?

Yes, that PR workflow will be allowed to write to the cache scoped to the PR branch. That means only workflow runs on the same PR branch (likely triggered by PR iterations) would be able to read those cache entries. Workflow runs on the default branch (CI builds) or other branches (release builds, other PRs) would not see cache entries scoped to that PR branch. This is how the cache has always worked for pull_request workflows.

Cache scoping is maybe not explained very well in the docs, though there is some mention of it at Restrictions for accessing a cache.

• A workflow run gets R/W access to the cache scope for the current branch.
• A workflow run also gets R/O access to the default branch cache scope, if the current branch is not the default branch. Cache read operations first check the current branch scope and fallback to the default branch scope.
• pull_request_target was problematic because those workflow runs use the default branch context instead of the PR branch. That meant (until this fix) they were able to write to the default branch cache scope and potentially poison the cache used by later CI or release builds.

[gtjoseph]

OK, thanks for the explanation.