Insomnia scripted environment variable writes under concurrent requests

Direct Answer

No. Insomnia does not provide execution isolation, write serialization, or atomic locks for environment variables updated by pre-request scripts. When multiple requests run concurrently against the same environment, they share a single environment store, and script-driven writes follow last-write-wins semantics. A scripted variable write is global to that environment and visible to every other request using it; there is no documented per-request isolation or transaction scope for environment state.

You cannot limit a scripted variable write to a single request execution without affecting other requests that share the same environment. To avoid interference, keep request-local state in ordinary JavaScript variables within the script, or use a separate environment for each concurrent execution rather than mutating a shared variable.

Which build determines persistence timing: desktop builds typically persist environment changes to local storage immediately, while Cloud and Teams builds may synchronize through a remote backend. However, exact timing is version-sensitive and may change across releases or sync backends.

Likely Explanation vs. Confirmed Behavior

Confirmed by Insomnia's scripting model: the environment store is shared across all requests in an environment. Without serialization, concurrent read-modify-write cycles on the same variable can produce stale reads or lost updates.

Likely explanation for observed overwrites: two pre-request scripts read the same variable, compute a new value independently, and write it back. Because there is no lock or atomic compare-and-swap, the second write silently overwrites the first. This is a natural consequence of a shared mutable store rather than a bug in any single request.

Steps for This Case

1. Replace shared environment variables with request-local JavaScript variables for values that only need to live for one execution.
2. If concurrent executions must coordinate through Insomnia's environment, create a distinct environment per execution path so writes do not collide.
3. Verify persistence behavior for your installed build: run a script that writes a variable, then test whether the value survives an immediate reload versus a full application restart.
4. Review the scripting documentation for your installed version to confirm whether any request-scoped variable API exists beyond the shared environment.

Diagnostic Needed

Which Insomnia build and version are you using (desktop, Cloud, or Teams)? This changes the recommendation because persistence and synchronization timing differ between local and remote backends, and older or newer releases may handle environment storage differently.