IntelliJ IDEA HTTP client ${env.VAR} placeholder limits for credential-light testing

Short answer

Yes — since IntelliJ IDEA 2023.3, ${env.VAR} substitution applies consistently across URLs, query parameters, headers, request bodies, and the OAuth2 authentication dialog fields. Resolution draws from both run-configuration environment variables and system environment variables, with the run configuration taking precedence when the request is executed through one. The placeholder itself is the only thing persisted in the .http file, so shared files stay credential-free by design.

Scope of substitution

Placeholders resolve anywhere a string value is accepted in a request: the request line, headers, body, and the auth configuration (including OAuth2 token fields). Tokens fetched at runtime through the OAuth2 flow are held in memory for the IDE session only, which matches the re-provisioning behavior you've observed — restarting the IDE means re-authenticating. (The refresh token, if used, is kept in the IDE's encrypted credential store; access tokens are not.)

Environment sources and precedence

When you run a request via a Run Configuration (or the "Execute with" gutter dropdown), that configuration's environment variables are passed to the HTTP Client and override same-named system variables. Without a run configuration, only system environment variables are used. Two practical caveats:

• Variable names are case-sensitive on Linux/macOS but not on Windows — keep casing consistent across a mixed-OS team.
• There is no default-value syntax (${env.VAR:-fallback} does not work). A missing variable resolves to an empty string, which can produce silently malformed requests.

Where resolved values can leak

The .http file is safe: placeholders are never rewritten with resolved values. The risks are elsewhere:

• Run tool window: request output shows resolved headers/bodies. Treat console output as sensitive when real credentials are in play.
• idea.log: if HTTP Client request logging is enabled (Settings → Tools → HTTP Client), resolved values can land in the log. Disable it for credential-light workflows.
• Run configuration files: environment variables defined in a run configuration are stored in .idea/runConfigurations/*.xml or workspace.xml. Keep real secrets out of committed files — use dummy values in shared configs and real ones only in local, uncommitted system env vars.

Recommended credential-light setup

1. Author .http files with ${env.ACCESS_TOKEN}-style placeholders everywhere a secret would appear.
2. Commit a shared run configuration with dummy values (e.g., ACCESS_TOKEN=dummy) so integration tests run against a mock or sandbox endpoint.
3. Developers override with real values via system environment variables, never by editing the committed run configuration.
4. Disable HTTP Client request logging before using non-dummy credentials.

Quick verification

Create a scratch request using ${env.TEST_VAR} in the URL, a header, and the body. Run it once with a run configuration defining TEST_VAR=from-run-config and once without; the Run window shows which source wins. Then reopen the .http file to confirm placeholders are intact, and grep idea.log for the resolved value to confirm your logging setting. Behavior described reflects 2023.3+; verify against your exact IDE version, as placeholder handling has evolved across releases.