Test suite reads the developer's real ~/.agentmemory/.env — 14 tests fail on any machine with an install

[sbynode-ux]

What happens

On a machine that has a real ~/.agentmemory/.env (i.e. anyone actually running agentmemory), npm test fails 14 tests across 6 files:

test/auto-compress.test.ts        (2)  AGENTMEMORY_AUTO_COMPRESS=true in the user's .env
test/claude-bridge-path.test.ts   (1)  CLAUDE_MEMORY_BRIDGE=true
test/context-slots.test.ts        (1)  AGENTMEMORY_SLOTS=true
test/embedding-dimensions.test.ts (2)  OPENAI_EMBEDDING_MODEL / _DIMENSIONS
test/embedding-provider.test.ts   (4)  OPENAI_API_KEY present
test/fetch-timeout.test.ts        (4)  OPENAI_TIMEOUT_MS

Same tree, same commit, isolated HOME:

$ HOME=/tmp/empty npx vitest run --exclude test/integration.test.ts
Test Files  143 passed | 1 skipped (144)
     Tests  1599 passed | 1 skipped (1600)

Why it matters

The tests assert defaults ("defaults to 1536 for text-embedding-3-small", "falls back to the 60 000 ms default"), but getMergedEnv() merges ~/.agentmemory/.env underneath process.env, so those defaults are whatever the developer's install happens to use. Two consequences:

1. Contributors on a real install see red on a clean checkout and have to work out that their own config caused it.
2. A change that genuinely breaks a default can pass on a machine whose .env happens to set it — the suite is silent in exactly the direction that matters.

Node 22.23.2, agentmemory main @ 0.9.28.

Possible fixes

• have the config loader skip the user env file when process.env.VITEST / NODE_ENV === "test" is set, or
• give loadEnvFile() an explicit path/disable seam and point it at a fixture in vitest.config.ts (env: { AGENTMEMORY_ENV_FILE: "" }), or
• at minimum, document HOME=$(mktemp -d) npm test in CONTRIBUTING.

Happy to send a PR for whichever shape you prefer.