[JENKINS-76297] withEnv with '+=' adds new path to jnlp container's PATH, not to current containers PATH

When I use withEnv() inside container() to add a new path to the PATH env variable, it's the default JNLP container's PATH variable that get's extended, not the one I selected via container().

 

container('jnlp'){ // switch to JNLP container

    sh('''

        echo original PATH in container \$POD_CONTAINER

        echo \$PATH

    ''')    

    withEnv([

        "PATH+=/myNewPath" // append /myNewPath to JNLP container's PATH

    ]) {

        sh('''

            echo new PATH in container \$POD_CONTAINER

            echo \$PATH

        ''')

    }

}


container('build'){ // switch to another container which is not JNLP

    sh('''

        echo original PATH in container \$POD_CONTAINER

        echo \$PATH

    ''')    

    withEnv([

        "PATH+=/myNewPath" // expected to append /myNewPath to current container's PATH

   // but actually appends /myNewPath to JNLP container's PATH



     ]) {

        sh('''

            echo new PATH in container \$POD_CONTAINER

            echo \$PATH

        ''')

    }

} 

 

results in

 

 

I was expecting that my new path be added to the current containers PATH since I switched to it using container() step.

 

I guess appending to the current container's PATH would require the withEnv() step to inspect those env variables in the current container first which maybe does not happen. However, apparently, the withEnv() step does inspect the env variables of the JNLP container or some process further upstream did inspect the env variables of the JNLP container upon start of node and passes them down to withEnv().

 

My team's current workaround for this is to manually inspect the relevant env variables in the current container and then pass them as a finite value to withEnv()

container('build'){

    String oldPath = sh(script: 'echo \$PATH', returnStdout: true).trim() // manually inspect PATH variable in current container

    String newPath = "/myNewPath:${oldPath}"      // and add new path



    withEnv([

"PATH=${newPath}" // don't use appending via +=

  // but directly set value via =

    ]) {

sh('''

    echo new PATH in container \$POD_CONTAINER

    echo \$PATH

''')

    }

}

Please confirm if my expectation on this is wrong or if this is a bug in the withEnv().

---
Originally reported by burkhard, imported from: withEnv with '+=' adds new path to jnlp container's PATH, not to current containers PATH

• status: Open
  
• priority: Minor
  
• component(s): workflow-basic-steps-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 1
  
• imported: 20251215-220547
  

Raw content of original issue

When I use withEnv() inside container() to add a new path to the PATH env variable, it's the default JNLP container's PATH variable that get's extended, not the one I selected via container().


 



container('jnlp'){ // switch to JNLP container

    sh('''

        echo original PATH in container \$POD_CONTAINER

        echo \$PATH

    ''')    

    withEnv([

        "PATH+=/myNewPath" // append /myNewPath to JNLP container's PATH

    ]) {

        sh('''

            echo new PATH in container \$POD_CONTAINER

            echo \$PATH

        ''')

    }

}


container('build'){ // switch to another container which is not JNLP

    sh('''

        echo original PATH in container \$POD_CONTAINER

        echo \$PATH

    ''')    

    withEnv([

        "PATH+=/myNewPath" // expected to append /myNewPath to current container's PATH

                           // but actually appends /myNewPath to JNLP container's PATH



     ]) {

        sh('''

            echo new PATH in container \$POD_CONTAINER

            echo \$PATH

        ''')

    }

} 



 


results in


 




 


I was expecting that my new path be added to the current containers PATH since I switched to it using container() step.


 


I guess appending to the current container's PATH would require the withEnv() step to inspect those env variables in the current container first which maybe does not happen. However, apparently, the withEnv() step does inspect the env variables of the JNLP container or some process further upstream did inspect the env variables of the JNLP container upon start of node and passes them down to withEnv().


 


My team's current workaround for this is to manually inspect the relevant env variables in the current container and then pass them as a finite value to withEnv()



container('build'){

    String oldPath = sh(script: 'echo \$PATH', returnStdout: true).trim() // manually inspect PATH variable in current container

    String newPath = "/myNewPath:${oldPath}"                              // and add new path



    withEnv([

        "PATH=${newPath}" // don't use appending via +=

                          // but directly set value via =

    ]) {

        sh('''

            echo new PATH in container \$POD_CONTAINER

            echo \$PATH

        ''')

    }

}



Please confirm if my expectation on this is wrong or if this is a bug in the withEnv().

• environment: Jenkins 2.528.1

1 attachment

- [image-2025-11-18-21-21-40-106.png](https://issues.jenkins.io/secure/attachment/65313/image-2025-11-18-21-21-40-106.png)
> 

Start with the withEnv() and container() entry points in the workflow-basic-steps-plugin, using the supplied jnlp/build container reproduction. Compare PATH behavior when PATH+=/myNewPath is used versus the provided explicit PATH workaround, and consider the issue done when the selected container's PATH is extended and the reproduction verifies it.

Vom Indexierungsmodell aus dem Issue-Text verfasst.