Let nearest .env override parent .env in loadEnvFromHierarchy

[christso]

Summary

loadEnvFromHierarchy() currently merges .env files from the eval/test folder up to repo root, but parent values win because dotenv is called with override: false.

It would be more useful if the nearest .env overrode parent .env values while still merging missing keys.

Why this matters

For evals, it is common to keep shared defaults in the repo root .env, but set per-eval workspace or repo paths in a local .env near the eval YAML.

Right now, a closer .env can add new variables, but it cannot override an existing variable that was already loaded from a parent/root .env.

That makes per-eval configuration awkward and forces repeated shell exports for variables that should be naturally scoped to the eval folder.

Current behavior

If both of these exist:

Repo root .env:

MY_VAR=root
SHARED_ONLY=from_root

Subfolder .env (for example evals/foo/.env):

MY_VAR=local
LOCAL_ONLY=from_subfolder

And an eval is run from that subtree, both .env files are loaded, but MY_VAR remains root.

Expected behavior

AgentV should still merge .env files from the hierarchy, but the closest .env should take precedence.

Expected effective environment:

• MY_VAR=local
• SHARED_ONLY=from_root
• LOCAL_ONLY=from_subfolder

Repro steps

1. Create a repo root .env with:

   MY_VAR=root
   SHARED_ONLY=from_root

2. Create a nested eval folder .env with:

   MY_VAR=local
   LOCAL_ONLY=from_subfolder

3. Run an eval from the nested folder with --verbose.

4. Observe that AgentV logs both .env files as loaded, but the parent/root value still wins for MY_VAR.

Implementation note

In agentv 2.18.2, this behavior comes from loadEnvFromHierarchy().

Installed build reference:

• dist/chunk-ZCUOH72A.js
• around lines 304-329

This line appears to be the key behavior:

loadDotenv({ path: envFile, override: false });

Because files are loaded from higher scope to lower scope with override: false, nearer .env files cannot override values already set by parents.

Suggested fix

Either:

1. keep the current load order and use override: true for later/nearer .env files, or
2. reverse the load order so the nearest .env is loaded first and then preserve current semantics only for missing keys

The important behavior is:

• merge all discovered .env files
• let the nearest .env override parent values
• keep parent/root values for keys that are not set locally