Runner 2.333.0 rejects vars context in composite actions that 2.332.0 accepted

[charlesjiang-greengate]

Description

After the GitHub Actions runner was updated from 2.332.0 to 2.333.0, composite actions that reference the vars context (e.g. ${{ vars.AWS_REGION }}) now fail at parse time with:

Unrecognized named-value: 'vars'. Located at position 18 within expression: inputs.region || vars.AWS_REGION || 'ap-southeast-2'

This is a regression. The same composite action with the same vars references worked on runner 2.332.0 and fails on 2.333.0.

Reproduction

Composite action (action.yml):

inputs:
  region:
    description: 'AWS region'
    required: false

runs:
  using: composite
  steps:
    - run: echo "$REGION"
      env:
        REGION: ${{ inputs.region || vars.AWS_REGION || 'ap-southeast-2' }}

Calling workflow:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: my-org/my-action/.github/actions/my-composite@main
        with:
          region: ap-southeast-2

Expected behaviour

The composite action should resolve vars.AWS_REGION at runtime (as it did on 2.332.0), or at minimum silently fall through to the hardcoded default when the context is unavailable.

Actual behaviour

The runner rejects the template at parse time before any step executes:

##[error] Unrecognized named-value: 'vars'. Located at position 18 within expression: inputs.region || vars.AWS_REGION || 'ap-southeast-2'

Evidence

Two CI runs on the same repository, same workflow, same composite action. The composite action was not modified between runs. The only difference is the runner version:

• Runner 2.332.0: Deploy job succeeds
• Runner 2.333.0: Deploy job fails with the error above

Environment

• Runner 2.332.0: works
• Runner 2.333.0: fails
• OS: ubuntu-24.04 (Image: 20260323.65.1)

[ericsciple]

Apologies, vars was never intentionally supported.

#4147 which shipped with v2.331.0 accidentally removed validation that would have produced an error for vars, when the associated feature flag sent down from the server was true.

#4279 which shipped with v2.333.0 fixed ☝️

[ericsciple]

It looks like the associated server feature flag was enabled on 2026-01-22

So vars would have accidentally not produced an error between 2026-01-22 and the v2.333.0 release

[ericsciple]

Note, we also filter vars sent down to the runner, based on what's referenced directly in the job's YAML definition.

So any vars reference from the composite action would have resolved empty, unless the same var was also referenced directly from the job's YAML definition.

v2.333.0 correctly produces an error now.

[charlesjiang-greengate]

Thanks for the quick and thorough explanation, @ericsciple. The timeline and details about the server-side filtering are especially helpful — good to know the vars references in our composite actions were resolving empty all along.

We'll update our composite actions to remove the vars fallback and rely on input defaults instead. Straightforward fix on our end.

Appreciate the fast turnaround on this.