Stage-level environment variable missing in later Declarative Pipeline stages

Short answer

No. A variable defined in a stage-level environment block in a Jenkins Declarative Pipeline is scoped to that stage only. It is not automatically available to stages that follow it in the same run. Only the top-level (pipeline-level) environment block is inherited by every stage.

Confirmed behavior vs. likely explanation

The confirmed, well-established behavior is the scoping rule itself: stage-level environment applies to the steps inside that stage; pipeline-level environment applies everywhere. This has been stable across Jenkins LTS lines and Pipeline plugin versions, including the 2.400+ core / 2.12+ plugin ranges mentioned in the question.

The likely explanation for the apparent inconsistency you describe is one of three things:

• Top-level vs. stage-level confusion. A pipeline that defines the variable at the top level works everywhere; one that defines it in a stage does not. Comparing two different pipelines can look like version-dependent behavior.
• Imperative env.* mutation. Assigning env.MY_VAR = 'x' inside a script block writes to the global environment map for the run, which does persist to later stages on the same node. This is a different mechanism from declarative environment scoping and is a common source of "it worked before" surprises.
• Plugins masking the behavior. EnvInject and similar plugins inject variables globally at the build level. That can make a stage-scoped variable appear to propagate, when actually the plugin re-injected it everywhere.

What to do in this case

If later stages need the value, pick one of these:

1. Move the variable to the pipeline-level environment block if it is static for the whole run.
2. Compute it in a script step and assign env.MY_VAR = ..., accepting that this is imperative and can behave unexpectedly with parallel stages or agent changes.
3. If stages run on different agents, do not rely on env.* at all — pass the value via stash/unstash, an archived artifact, or re-compute it per stage. Environment mutations do not reliably cross node boundaries.

Verify it yourself

A minimal reproduction settles the question for your exact Jenkins and plugin versions:

pipeline {
  agent any
  stages {
    stage('one') {
      environment { FOO = 'bar' }
      steps { echo "stage one: ${env.FOO}" }
    }
    stage('two') {
      steps { echo "stage two: ${env.FOO}" } // prints null
    }
  }
}

Then move environment { FOO = 'bar' } to the top of the pipeline block and confirm both stages print bar. If you run distributed builds, add a different agent { label 'other' } to stage two and test whether any script-set env.* values survive the node switch — expect that they may not.

Caveats

Claims about specific plugin interactions (EnvInject, Config File Provider, credential bindings) vary by plugin version, so treat those as per-installation behavior to verify rather than universal rules. The core scoping rule itself, however, is not version-dependent.