Infra: block auth env vars from workspace dotenv#57767
Conversation
Greptile SummaryThis PR hardens the workspace
Confidence Score: 5/5Safe to merge — targeted blocklist addition with complete regression coverage and no observable side-effects on the trusted global path. All changes are additive (entries to an existing Set), the logic path is straightforward, tests cover both the new block assertions and the allowed-state-dir path, and no P1/P0 issues were found. No files require special attention.
|
| Filename | Overview |
|---|---|
| src/infra/dotenv.ts | Six credential/auth keys added to BLOCKED_WORKSPACE_DOTENV_KEYS set, alphabetically ordered and consistent with existing entries. |
| src/infra/dotenv.test.ts | Two new regression tests added covering both the block (CWD path) and allow (state-dir path) scenarios for the six new keys. |
Reviews (1): Last reviewed commit: "Infra: block auth env vars from workspac..." | Re-trigger Greptile
b960be1 to
8407378
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8407378e42
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
🔒 Aisle Security AnalysisWe found 1 potential security issue(s) in this PR:
1. 🟡 Untrusted workspace .env can inject many provider API tokens not covered by dotenv blocklist
Description
Impact:
Vulnerable code (workspace dotenv filtering is incomplete): return (
shouldBlockRuntimeDotEnvKey(upper) ||
BLOCKED_WORKSPACE_DOTENV_KEYS.has(upper) ||
BLOCKED_WORKSPACE_DOTENV_PREFIXES.some((prefix) => upper.startsWith(prefix)) ||
BLOCKED_WORKSPACE_DOTENV_SUFFIXES.some((suffix) => upper.endsWith(suffix))
);RecommendationExtend the workspace Suggested approach:
Example: // dotenv.ts
import { listKnownSecretEnvVarNames } from "../secrets/provider-env-vars.js";
const BLOCKED_WORKSPACE_DOTENV_KEYS = new Set([
...existingBlockedKeys,
...listKnownSecretEnvVarNames().map((k) => k.toUpperCase()),
]);Also add tests that assert representative non-OpenAI/Anthropic secret env vars (e.g., Analyzed PR: #57767 at commit Last updated on: 2026-03-30T15:43:58Z Latest run failed. Keeping previous successful results. Trace ID: Last updated on: 2026-03-30T16:22:26Z |
|
Follow-up pushed on top of the rebased branch. The workspace dotenv filter now also blocks |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 300fcf0474
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
Addressed the remaining review feedback on workspace dotenv credential injection. The latest commit blocks the OPENCLAW_LIVE_* provider auth vars from repo-controlled .env files as well, while keeping the trusted state-dir .env behavior unchanged. Local validation: pnpm test -- src/infra/dotenv.test.ts and pnpm check. |
|
Addressed the remaining review feedback on workspace dotenv credential injection. The latest commit blocks the provider auth vars from repo-controlled files as well, while keeping the trusted state-dir behavior unchanged. Local validation:
[test-parallel] start unit workers=6 filters=1 RUN v4.1.2 /home/ubuntu/Projects/openclaw/openclaw/.worktrees/fix/fix-132 Test Files 1 passed (1) [test-parallel] done unit code=0 elapsed=4.6s
OK apps/macos/Sources/OpenClaw/HostEnvSecurityPolicy.generated.swift
Found 0 warnings and 0 errors.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ca20f0c0c0
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| ]); | ||
|
|
||
| const BLOCKED_WORKSPACE_DOTENV_SUFFIXES = ["_BASE_URL"]; | ||
| const BLOCKED_WORKSPACE_DOTENV_PREFIXES = ["ANTHROPIC_API_KEY_", "OPENAI_API_KEY_"]; |
There was a problem hiding this comment.
Block Google API key vars from workspace dotenv
The new workspace dotenv hardening still allows Google credentials to be injected from a repo-controlled .env: BLOCKED_WORKSPACE_DOTENV_PREFIXES only covers Anthropic/OpenAI, and the blocked key set also omits GEMINI_API_KEY, GEMINI_API_KEYS, and GOOGLE_API_KEY. Those variables are consumed by runtime key collection (collectProviderApiKeys in src/agents/live-auth-keys.ts) and then used for execution (collectProviderApiKeysForExecution in src/agents/api-key-rotation.ts and src/media-understanding/runner.entries.ts), so untrusted workspaces can still supply Google provider auth despite this commit’s credential-blocking intent.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ca20f0c0c0
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| ]); | ||
|
|
||
| const BLOCKED_WORKSPACE_DOTENV_SUFFIXES = ["_BASE_URL"]; | ||
| const BLOCKED_WORKSPACE_DOTENV_PREFIXES = ["ANTHROPIC_API_KEY_", "OPENAI_API_KEY_"]; |
There was a problem hiding this comment.
Block Google API key vars from workspace dotenv
The new workspace dotenv hardening still allows Google credentials to be injected from a repo-controlled .env: BLOCKED_WORKSPACE_DOTENV_PREFIXES only covers Anthropic/OpenAI, and the blocked key set also omits GEMINI_API_KEY, GEMINI_API_KEYS, and GOOGLE_API_KEY. Those variables are consumed by runtime key collection (collectProviderApiKeys in src/agents/live-auth-keys.ts) and then used for execution (collectProviderApiKeysForExecution in src/agents/api-key-rotation.ts and src/media-understanding/runner.entries.ts), so untrusted workspaces can still supply Google provider auth despite this commit’s credential-blocking intent.
Useful? React with 👍 / 👎.
* Infra: block auth env vars from workspace dotenv * Infra: block workspace dotenv auth key variants * Infra: block workspace dotenv live auth keys
* Infra: block auth env vars from workspace dotenv * Infra: block workspace dotenv auth key variants * Infra: block workspace dotenv live auth keys
* Infra: block auth env vars from workspace dotenv * Infra: block workspace dotenv auth key variants * Infra: block workspace dotenv live auth keys
* Infra: block auth env vars from workspace dotenv * Infra: block workspace dotenv auth key variants * Infra: block workspace dotenv live auth keys
* Infra: block auth env vars from workspace dotenv * Infra: block workspace dotenv auth key variants * Infra: block workspace dotenv live auth keys
* Infra: block auth env vars from workspace dotenv * Infra: block workspace dotenv auth key variants * Infra: block workspace dotenv live auth keys
Summary
.envfiles.envsupport for the same keysChanges
.envvalues and allowed state-dir.envvaluesValidation
pnpm test -- src/infra/dotenv.test.tspnpm checkclaude -p "/review"and verified the follow-up env var names it suggested are not present in the repoNotes
.envcompatibility unexpectedly.