Jenkins documents a feature where pipeline parameters can be read via environment variables, primary as a method of avoiding shell injection.

However, when running a pipeline for the first time with a new parameter, this automatic environment variable is not created until the second run of the pipeline. It seems like the process of initialising these environment variables happens before the pipeline parameters block is processed. This behaviour is highly unintuitive and makes it difficult to use pipeline parameters safely as environment variables.

This is a recurring problem for me and my org, because we always define the pipeline parameters in the Jenkinsfile, and often add new parameters to existing pipelines. The workaround I employ (when I remember) is to manually trigger a run after pushing a change to add a new parameter before quickly cancelling it just after it starts.

To reproduce this issue, it's as simple as running the example in the documentation linked above in a new pipeline

pipeline {
  agent any
  parameters {
    string(name: 'STATEMENT', defaultValue: 'hello; ls /', description: 'What should I say?')
  }
  stages {
    stage('Example') {
      steps {
        /* CORRECT */
        sh('echo ${STATEMENT}')
      }
    }
  }
} 

The first run of this pipeline will print nothing, but the second run will print the expected statement.