Question
Environment variable behavior after Collection Runner completion in Postman 10.12
Rin Dey
0 reputation · 03 Jan 2026, 17:56 UTC
22.5K views
Loading…
0 reputation · 03 Jan 2026, 17:56 UTC
Determine whether Postman offers a built‑in way to automatically revert environment variables to their original values after a Collection Runner run completes, so that successive runs start with a clean state without manual intervention.
The version 10.12 changelog highlights the Collection Runner cache cleanup that fixed the memory leak, but it does not mention any change to environment variable handling. Official docs state that variable modifications are retained intentionally to enable state sharing across runs, leaving teams that require isolation to implement their own reset scripts. This raises uncertainty about whether a configuration option or future update will provide automatic rollback.
34775 reputation · 04 Jan 2026, 01:04 UTC
Postman 10.12 does not provide a built‑in option to automatically revert environment variables to their original values after a Collection Runner finishes. Variable changes made with pm.environment.set() (or the UI “Set as environment variable” option) are retained intentionally.
postmanpm.iterationData or pm.variables) and are cleared after each iteration and after the runner completes.The Collection Runner updates the in‑memory environment object while executing requests and writes those changes back to the persisted environment store when the run ends, unless the variable lives in a temporary iteration scope.
\n// Pre‑request of the first request\\npm.environment.set('backup_testVar', pm.environment.get('testVar'));\\n\\n// Test script of the last request (or After Run)\\npm.environment.set('testVar', pm.environment.get('backup_testVar'));\\npm.environment.unset('backup_testVar');\\npm.environment.unset('myVar');Are you driving the Collection Runner with a CSV or JSON data file? If yes, you already get per‑iteration isolation; if not, you’ll need one of the reset patterns above.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 04 Jan 2026, 02:10 UTC
One option not yet mentioned: if the values only need to live for the duration of a single run, consider collection variables instead of environment variables. In Postman (including 10.12), collection variables set via pm.collectionVariables.set() are scoped to the collection rather than the shared environment, so they don't leak into other collections that use the same environment — though note they still persist after the run unless unset.
For truly run-local state, pm.variables.set() writes to the local scope, which is discarded when the run completes. That's often the cleanest answer to the isolation question: keep the environment for stable config (base URLs, credentials) and push anything the run mutates into local or data-file scope.
Worth verifying in your version: run a two-request collection that sets a value with pm.variables.set() in request one and reads it in request two, then confirm the variable is absent from the environment afterward. If your CI pipeline uses Newman, the same scoping rules apply, so this pattern ports directly without extra reset scripts.