Choosing Between Environment‑Variable Placeholders and Secret Storage API for Credential Isolation in VSCode Integration Tests

Answer

Use the VSCode Secret Storage API (`vscode.secrets`) for integration-test credentials. Environment variables are inherited by child processes and can be inspected by other processes or the CI runner, so they do not reliably isolate test secrets. Secret Storage is per-extension, API-only, and persists across VSCode restarts; however, the API does not clear secrets automatically. Your harness must call `vscode.secrets.delete` in teardown. For CI, use VSCode 1.70 or later; versions before 1.70 are flagged as potentially inconsistent for headless secret storage and should be verified with `code --version` before use.

Confirmed behavior

• `vscode.secrets.store` writes a secret scoped to the extension; `vscode.secrets.get` returns it only through the API.
• Secret Storage values are not environment variables and are not visible to unrelated processes through the shell.
• Secrets survive a VSCode reload until explicitly deleted.

Assumptions and uncertainty

Assumes tests run in the VSCode extension host with the `vscode` module available, and CI can run `code --version`. The API existed before 1.70, but stable headless behavior on Linux/macOS is treated as unverified below 1.70; mark that version check as required before merging.

Steps for this case

1. In test setup, store the credential under a fixed test key:

   await vscode.secrets.store('integration-test-cred', testSecret);

2. Assert the secret is readable through the API and absent from the process environment:

   assert.strictEqual(await vscode.secrets.get('integration-test-cred'), testSecret); assert.strictEqual(process.env['integration-test-cred'], undefined);

3. In test teardown, delete the key even if the test fails:

   await vscode.secrets.delete('integration-test-cred');

4. Run the suite twice with a VSCode restart between runs and confirm teardown removes the secret; never print or log the secret value.

Verification

Run `code --version` in CI and require at least 1.70. If the output is lower, do not rely on Secret Storage for CI until headless behavior is confirmed; pin the image to 1.70+ or rerun the compatibility test.

Missing diagnostic detail that can change the recommendation: what does `code --version` print on the CI image, and is VSCode launched headless? If below 1.70 or headless on Linux/macOS, pin to 1.70+ and retest before adopting Secret Storage in CI.