Greptile Summary

This PR addresses a real security issue (#38757) where resolveConfigEnvVars() was resolving ${ENV_VAR} placeholders to their plaintext values before ensureOpenClawModelsJson() ran, causing API keys to be written in plaintext to agents/*/agent/models.json. The fix adds a reverse-lookup step in normalizeProviders() that detects when an apiKey value matches a known provider env var's current value and replaces it with the env var name.

Key changes:

• src/agents/models-config.providers.ts: New ENV_VAR_NAME_RE regex and a reverse-lookup block in normalizeProviders() that checks process.env[envVarName] === currentApiKey and substitutes the env var name back in.
• Two new test cases: one unit test for normalizeProviders() and one E2E test for ensureOpenClawModelsJson().

Security gap identified:

The reverse-lookup calls resolveEnvApiKeyVarName(), which returns the env var name from the first env var that is currently set in the environment. For providers with multiple env vars in a priority chain (anthropic → ANTHROPIC_OAUTH_TOKEN ?? ANTHROPIC_API_KEY; github-copilot → COPILOT_GITHUB_TOKEN ?? GH_TOKEN ?? GITHUB_TOKEN; and others), if the user's config was resolved from a lower-priority env var but a higher-priority one is also set, the strict equality check fails, and the plaintext secret is still written to models.json.

Example: User has both ANTHROPIC_OAUTH_TOKEN and ANTHROPIC_API_KEY set in environment, but their config explicitly referenced ${ANTHROPIC_API_KEY}. The reverse-lookup will return "ANTHROPIC_OAUTH_TOKEN" as the canonical env var, but process.env["ANTHROPIC_OAUTH_TOKEN"] contains a different value than the resolved currentApiKey (which is the value of ANTHROPIC_API_KEY), so the equality check fails and the plaintext secret persists.

The fix works correctly for the majority of providers that map to a single env var (e.g. openai, google, groq, mistral, etc.), which covers most users.

Confidence Score: 2/5

• The fix solves the core plaintext leak issue for most providers (those with single env vars), but has a documented security gap for multi-env-var providers when both high and low priority env vars are set.
• The fix works correctly for the majority of providers (openai, google, groq, mistral, etc.) which map to a single canonical env var. However, for ~9 providers with multiple env vars in a priority chain (anthropic, github-copilot, chutes, zai, opencode, qwen-portal, minimax-portal, kimi-coding, huggingface), the reverse-lookup silently fails if a user has multiple env vars set and their config references a lower-priority one. This causes a plaintext API key to persist to models.json, partially defeating the security fix. A score of 2/5 reflects that the fix addresses the primary issue but leaves a meaningful security gap that should be addressed before merging.
• src/agents/models-config.providers.ts — specifically the reverse-lookup block at lines 533-537. The logic needs to check all candidate env vars for each provider, not just the first currently-set one.

_{Last reviewed commit: fecf2b2}

Landed via maintainer flow.

What I did:

• Rebased onto latest main via temp branch land-pr-38889.
• Resolved one test-file merge conflict against current main by keeping both the existing header-normalization coverage and the new env-var reverse-lookup coverage.
• Added changelog entry crediting @gambletan and fix: prevent API key plaintext leak into models.json state file #38889.
• Ran full gate before commit:
  • pnpm lint
  • pnpm build
  • pnpm test
• Committed with Conventional Commit + co-author trailer.

SHAs:

• Original PR head: fecf2b273331ecde9851c87a617ef126787d7e35
• Landed on main: 17ab46aedd689ae73541f07365422b717e9e1d74

Thanks @gambletan for the contribution.