fix(utils): reject a project-.env agent directory override

[10kH]

Closes the pre-existing platform gap you documented in the #3273 review:

Bun loads cwd/.env into process.env before any gjc module runs, so a planted GJC_CODING_AGENT_DIR redirects getAgentDir() (dirs.ts:251), making the “trusted” agent .env repo-internal and recovering the full attack. Separate follow-up against the shared resolver.

Why it matters

The agent directory selects the agent's own .env, which is one of the file sources $credentialEnv consults. So this one variable is upstream of every trust fix: a repository ships a directory, points the agent at it, and its .env is then treated as trusted.

Measured on this source — repo/.env sets the agent dir, repo/.evil-agent/.env sets a provider base URL:

before: $credentialEnv("ANTHROPIC_BASE_URL") = "https://attacker.example"
after:  undefined

And the operator path, verified in the same shape:

GJC_CODING_AGENT_DIR from the shell, agent .env -> "https://gateway.internal"   (honoured)
GJC_CODING_AGENT_DIR from repo .env,  agent .env -> undefined                    (rejected)

Fix

dirs.ts cannot call $credentialEnv — env.ts imports dirs.ts. Rather than duplicate a parser, the .env parsing primitives (isValidEnvName, parseShellEnvFile, parseEnvFile) move to a leaf env-file module that both can import; env.ts re-exports them so its public surface is unchanged.

dirs.ts then applies the same conservative ambiguity rule resolveLiveCredentialEnvValue already uses (env.ts:167-174): an override whose value matches what the project .env sets is not honoured. An operator whose environment happens to carry the identical value loses the override — the same trade-off your review called out as correct for scenario D.

Tests

agent-dir-trust.test.ts spawns a probe with a controlled cwd (both the override and projectEnv resolve at module load) and a temp HOME so the other trusted file sources stay neutral: an inherited agent dir still supplies its .env, a planted one does not, and a planted one cannot redirect an inherited one.

Proof-first: reverting the check fails ignores an agent directory planted by the project .env.

Verification

bun run check in packages/utils (whole-package biome + tsc): exit 0. packages/utils/test: 216 pass / 0 fail. coding-agent discovery + browser suites (the heaviest getAgentDir consumers): 249 pass / 0 fail.

Scope

GJC_CONFIG_DIR has the same shape. It is deliberately untouched: #3267 is already approved against that same function, and binding its trust here would conflict with a head you have already verified. Happy to send it as a successor once #3267 lands.

[Yeachan-Heo]

Verdict: APPROVE — exact head e88771a26cd4bbc3215239973a81fdeba6641244

Closes a real, previously-documented gap (#3273 review): Bun loads cwd/.env before any module runs, so a planted GJC_CODING_AGENT_DIR could make a repo-shipped directory's .env a trusted credential source, upstream of every other trust fix in this batch.

Checks performed:

• Circular-dependency avoidance: dirs.ts imports the new leaf env-file.ts (not env.ts), and env.ts re-exports from env-file.ts for public-surface stability. env.ts still imports dirs.ts — no cycle introduced. Confirmed by reading both files' import graphs directly.
• Ambiguity-rule parity: trustedAgentDirOverride() in dirs.ts (reject when override value === project .env value) is functionally equivalent to resolveLiveCredentialEnvValue()'s three-condition rule in env.ts — the third condition (inheritedEnv check) is always satisfied whenever the first two hold, since filterCredentialInheritedEnv already excludes ambiguous project-matching entries from inheritedEnv by construction. No divergence in trust semantics between the two call sites.
• GJC_CONFIG_DIR exclusion: correctly untouched; diff confirms no changes to getConfigRootDir(), and the PR body explicitly defers it to #3267 (already approved against the same function) to avoid a conflicting head.
• Tests: hermetic — agent-dir-trust.test.ts neutralizes HOME via temp dir; GJC_CODING_AGENT_DIR is correctly left unneutralized since it's the variable under test, and the probed variable (GJC_TRUST_PROBE_VALUE) is test-invented so no real-environment collision risk. Three scenarios (operator-inherited honored, project-planted rejected, project cannot redirect an inherited override) all read as sound and match the stated proof-first claim.
• CI: all 22 checks pass on the exact head, no pending/failing.
• Novelty: no other open PR in this batch or the broader open env-trust set touches dirs.ts/env.ts/env-file.ts; not a duplicate.
• No automated reviewer comments present on this PR.

No merge action taken — post-#3281 dev CI 30253189244 is nonterminal and this batch is read-only review only.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]