## TL;DR

A test that sets an environment variable and never unsets it poisons every test that runs after it on the same worker. The failing test's code is innocent, so reading it finds nothing. Dump the worker's environment before and after each earlier test to find the setter, then make the setter clean up after itself.

## The query

```text
the agent couldn't find the leaked env var because it only looked at the failing test, not the whole worker process
```

## Steps

### 1. Confirm the failing test reads an env var

Search the failing test (and the code it calls) for environment reads: the variable name, its expected value, and what goes wrong when the value is different.

Expected: the exact variable name and the value the test expects vs the value it actually sees.

### 2. Dump the worker environment between tests

Run the earlier tests one at a time, dumping the full environment before and after each. Diff the dumps. The test after which the variable appears (or changes value) is the setter.

Expected: one test identified whose execution changes the variable. That is the leak.

### 3. Make the setter clean up

Change the setter to restore the variable after itself: save the old value, set the new one, and restore in teardown (a fixture with teardown, or try/finally semantics). Never leave process-global state behind.

Expected: the environment diff after the setter runs is empty. The variable is untouched.

### 4. Re-run the whole worker's test list

Run the full set of tests that share the worker, in order, with no special setup in the victim.

Expected: the victim passes, and no other test on the worker shows the polluted value.

## Use this when

- A test fails with a value that looks like someone else's configuration
- The failing test's code sets nothing itself but reads from the environment
- The failure depends on which tests ran before it on the same worker
- The agent read the failing test top to bottom and found nothing wrong

## Not for this skill when

- The variable is set by CI config, the shell, or a dotenv file loaded before the run (then it is intentional configuration, not a leak)
- The test fails in isolation too (then the bad value comes from its own setup)
- The pollution is in the database or filesystem rather than the environment (different leak, different hunt)
- The runner forks a fresh process per test (then env can't leak between tests by design)

## Variant phrasings

### test passes alone but sees the wrong config value in the suite

Classic env leak signature. The value is right in isolation because no setter ran before it.

### two tests need different values of the same variable

Whoever runs second inherits whoever ran first's value. Each test must save and restore.

### the agent added the variable to the failing test's setup

That masks the leak for the victim but leaves every other test exposed, and it hardcodes a value the test shouldn't own.

## Why it happens

The agent's investigation is anchored on the failing test: it reads that test's code, its fixtures, its setup. Environment variables are process-global, so the setter can be anywhere upstream, in a test that passed and whose logs show nothing wrong. The agent never widens the aperture to the whole worker process because nothing in the failure points there. It also tends to "fix" the victim by pinning the variable in the victim's setup, which hides the leak instead of removing it.

## Edge cases

- The setter is a conftest fixture, not a test: module- or session-scoped fixtures run outside any single test. Audit fixtures with the same dump-and-diff approach.
- The variable is set by a library on import: importing a module as a side effect can set process state. Check import-time side effects of modules the earlier tests pull in.
- The leak only happens when the setter test fails: its cleanup is skipped on failure. Make the restore unconditional.
- Parallel workers each have their own environment: the leak only affects tests sharing a worker. If sharding changes, the victim list changes, which makes the failure look random.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LuQw8j9M6DrdtwcF7sBbsA