Block unsafe Node runtime env overrides [AI]

[pgondhi987]

Summary

• Blocks Node runtime-control environment variables in the shared host environment policy.
• Regenerates the macOS host environment policy artifact from the shared JSON policy.
• Adds regression coverage for explicit overrides, inherited environment filtering, workspace .env, CLI dotenv loading, and skill env overrides.
• Updates user-facing docs that describe filtered startup environment keys.

Linked context

No public auto-closing issue reference in this PR body.

Real behavior proof (required for external PRs)

• Behavior addressed: Node runtime-control environment keys are now rejected by the same sanitizer paths that already reject comparable startup and loader controls.
• Real environment tested: Local OpenClaw worktree on Linux with Node 24.15.0; proof exercised the node-host system.run sanitizer boundary.
• Exact steps or command run after this patch: ./node_modules/.bin/tsx --eval '<script importing sanitizeEnv from src/node-host/invoke.ts and passing NODE_REDIRECT_WARNINGS, NODE_REPL_EXTERNAL_MODULE, NODE_REPL_HISTORY, NODE_V8_COVERAGE overrides>'
• Evidence after fix:

{
  "proof": "node-host system.run sanitizeEnv override filtering",
  "safeValue": "kept",
  "blockedSurvivors": []
}

• Observed result after fix: The safe proof key survived, while NODE_REDIRECT_WARNINGS, NODE_REPL_EXTERNAL_MODULE, NODE_REPL_HISTORY, and NODE_V8_COVERAGE were all removed by the OpenClaw node-host sanitizer path.
• What was not tested: A full live gateway with an attached external node was not run locally.
• Proof limitations or environment constraints: This is local runtime proof against the node-host sanitizer function used by system.run, plus focused tests for sibling sanitizer consumers.
• Before evidence: Existing policy and tests did not cover these Node runtime-control keys.

Tests and validation

Commands run:

node scripts/run-vitest.mjs src/infra/host-env-security.test.ts src/infra/host-env-security.reported-baseline.test.ts src/infra/host-env-security.policy-parity.test.ts src/infra/dotenv.test.ts src/agents/skills.test.ts
git diff --check
pnpm docs:check-mdx
./node_modules/.bin/oxfmt --check --threads=1 src/agents/skills.test.ts src/infra/dotenv.test.ts src/infra/host-env-security-policy.json src/infra/host-env-security.reported-baseline.json src/infra/host-env-security.reported-baseline.test.ts src/infra/host-env-security.test.ts
pnpm format:docs:check
.agents/skills/autoreview/scripts/autoreview --mode branch --base origin/main
/home/ubuntu/openclaw-tracking/skill-based-auto-pr-creation/scripts/auto-pr.sh issue 698 --run-stage ghsa_dry_run

Regression coverage added or updated:

• Host environment policy baseline coverage for the additional keys.
• Explicit inherited and override sanitizer assertions.
• Workspace and CLI dotenv filtering assertions.
• Skill env override filtering assertions.
• macOS generated policy parity coverage through the existing parity test.

Risk checklist

Did user-visible behavior change? (Yes/No)

Yes. These environment variables are now filtered where dangerous runtime-control env keys are already filtered.

Did config, environment, or migration behavior change? (Yes/No)

Yes. Environment override and dotenv handling rejects additional Node runtime-control names.

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

Yes. This changes host child-process environment sanitization.

What is the highest-risk area?

Blocking a legitimate local workflow that intentionally relied on these Node variables through OpenClaw-managed child process env surfaces.

How is that risk mitigated?

The change is limited to the existing dangerous environment policy boundary, keeps trusted global operator dotenv behavior unchanged, documents the new filtered names, and adds focused regression coverage across affected sanitizer consumers.

Current review state

What is the next action?

Wait for CI and fresh automation review on the latest commit.

What is still waiting on author, maintainer, CI, or external proof?

CI is pending. Maintainer review is still needed for the compatibility impact of blocking these Node runtime-control variables.

Which bot or reviewer comments were addressed?

Autoreview requested blocking same-class Node path redirection env variables; this PR now also blocks NODE_REDIRECT_WARNINGS and NODE_REPL_HISTORY with matching docs/tests. ClawSweeper requested real behavior proof; this body now includes node-host sanitizer proof output.

AI-assisted: yes.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed May 27, 2026, 10:37 AM ET / 14:37 UTC.

Summary
Adds four Node runtime-control environment variable names to the shared host environment denylist, regenerated macOS policy artifact, user-facing docs, and focused regression coverage.

PR surface: Source +8, Tests +87, Docs 0, Generated +8. Total +103 across 10 files.

Reproducibility: yes. Current main lacks the four Node runtime-control names in the shared policy while sanitizer paths derive blocked inherited and override behavior from that policy, and Node 24.15.0 help confirms the names alter runtime behavior.

Review metrics: 1 noteworthy metric.

• Blocked env policy surface: 4 added, 0 changed, 0 removed. Adding blocked env names changes runtime compatibility for existing users who pass these Node variables through OpenClaw-managed env surfaces.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Have a maintainer explicitly accept the compatibility impact of filtering these four env keys before merge.

Risk before merge

• Merging intentionally blocks NODE_REDIRECT_WARNINGS, NODE_REPL_EXTERNAL_MODULE, NODE_REPL_HISTORY, and NODE_V8_COVERAGE across OpenClaw-managed environment surfaces; existing users relying on those variables through system.run, workspace dotenv, CLI dotenv, skills, or stdio MCP env need maintainer-accepted compatibility breakage.

Maintainer options:

1. Accept stricter Node env filtering (recommended)
   A maintainer can explicitly accept that these four Node runtime-control variables stop passing through OpenClaw-managed env surfaces because the security boundary is worth the compatibility cost.
2. Narrow any legitimate exception
   If maintainers decide a variable such as REPL history or V8 coverage should remain supported, adjust the shared policy and docs before merge rather than blocking it everywhere.
3. Pause until workflow evidence appears
   If there is credible evidence of common legitimate workflows depending on these variables, pause this PR and decide the env policy in a focused maintainer thread.

Next step before merge
Protected maintainer labeling and intentional compatibility-sensitive env filtering require human approval; no narrow repair defect was found.

Security
Cleared: No supply-chain or security-regression concern found; the patch tightens an existing host child-process environment boundary without touching dependencies, workflows, lockfiles, or secret handling.

Review details

Best possible solution:

Land only after a maintainer accepts the stricter Node env policy and CI is green; otherwise narrow the policy scope or document an explicit supported exception path.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main lacks the four Node runtime-control names in the shared policy while sanitizer paths derive blocked inherited and override behavior from that policy, and Node 24.15.0 help confirms the names alter runtime behavior.

Is this the best way to solve the issue?

Yes if maintainers want these keys blocked. The PR uses the shared JSON policy so node-host, dotenv, skill env overrides, docs, and generated macOS policy stay aligned; the unresolved part is compatibility acceptance, not a code repair.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against b8cf83aeb3b5.

Label changes

Label changes:

• add proof: sufficient: Contributor real behavior proof is sufficient. The PR body now includes copied after-fix live output from a local Node 24 OpenClaw runtime eval of node-host sanitizeEnv; it proves the sanitizer boundary, while full gateway/macOS live paths remain untested.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body now includes copied after-fix live output from a local Node 24 OpenClaw runtime eval of node-host sanitizeEnv; it proves the sanitizer boundary, while full gateway/macOS live paths remain untested.
• remove rating: 🧂 unranked krab: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.
• remove status: 📣 needs proof: Current PR status label is status: 👀 ready for maintainer look.

Label justifications:

• P2: This is a normal-priority security hardening PR with focused scope but real compatibility impact.
• merge-risk: 🚨 compatibility: The diff intentionally makes existing env/dotenv/skill/MCP configurations that relied on four Node variables stop passing those values through.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body now includes copied after-fix live output from a local Node 24 OpenClaw runtime eval of node-host sanitizeEnv; it proves the sanitizer boundary, while full gateway/macOS live paths remain untested.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body now includes copied after-fix live output from a local Node 24 OpenClaw runtime eval of node-host sanitizeEnv; it proves the sanitizer boundary, while full gateway/macOS live paths remain untested.

Evidence reviewed

PR surface:

Source +8, Tests +87, Docs 0, Generated +8. Total +103 across 10 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	2	9	1	+8
Tests	4	111	24	+87
Docs	3	3	3	0
Config	0	0	0	0
Generated	1	8	0	+8
Other	0	0	0	0
Total	10	131	28	+103

What I checked:

• Repository policy applied: Root and scoped AGENTS guidance was read; the root policy treats config/default/env filtering and fail-closed changes as compatibility-sensitive merge risk even with green CI. (AGENTS.md:16, b8cf83aeb3b5)
• Current main policy gap: Current main blocks NODE_OPTIONS and NODE_PATH in the shared policy, but not NODE_REDIRECT_WARNINGS, NODE_REPL_EXTERNAL_MODULE, NODE_REPL_HISTORY, or NODE_V8_COVERAGE. (src/infra/host-env-security-policy.json:2, b8cf83aeb3b5)
• PR policy change: The PR adds NODE_REDIRECT_WARNINGS, NODE_REPL_EXTERNAL_MODULE, NODE_REPL_HISTORY, and NODE_V8_COVERAGE to blockedEverywhereKeys. (src/infra/host-env-security-policy.json:5, 254872e11bfb)
• Runtime sanitizer path: The host sanitizer derives dangerous inherited and override filtering from the shared policy, so adding those policy keys affects node-host system.run, inherited env, and override filtering without extra runtime code changes. (src/infra/host-env-security.ts:203, b8cf83aeb3b5)
• Dependency contract check: Node 24.15.0 help documents these variables as controlling warning redirection, external REPL module loading, REPL history, and V8 coverage output.
• Regression coverage: The PR adds assertions that the new names are dangerous host env vars and are filtered from workspace dotenv and skill env override paths. (src/infra/host-env-security.test.ts:194, 254872e11bfb)

Likely related people:

• steipete: Current blame and shortlog history show Peter Steinberger recently carried the shared host-env policy and related sanitizer files in commit fd648ed. (role: recent area contributor; confidence: medium; commits: fd648edfa95c; files: src/infra/host-env-security-policy.json, src/infra/host-env-security.ts, src/infra/dotenv.ts)
• joshavant: Josh Avant introduced the host env override hardening across gateway, node, and macOS surfaces that this PR extends. (role: introduced behavior; confidence: high; commits: 7abfff756d6c; files: src/infra/host-env-security.ts, src/node-host/invoke-system-run.ts, apps/macos/Sources/OpenClaw/HostEnvSanitizer.swift)
• Agustin Rivera: Agustin Rivera split and aligned inherited host exec env filtering, which is directly affected by adding blockedEverywhereKeys. (role: adjacent owner; confidence: high; commits: fa82193c7273; files: src/infra/host-env-security-policy.js, src/infra/host-env-security-policy.json, src/infra/host-env-security.ts)
• pgondhi987: Pavan Kumar Gondhi previously expanded the same host env security denylist and baseline coverage in merged history, beyond authoring this PR. (role: prior area contributor; confidence: medium; commits: 2d126fc62343; files: src/infra/host-env-security-policy.json, src/infra/host-env-security.test.ts, src/infra/host-env-security.reported-baseline.json)
• Vincent Koc: Vincent Koc restored the dotenv trust boundary that this PR now extends for workspace and CLI dotenv filtering. (role: adjacent owner; confidence: medium; commits: 11590eb6ce38; files: src/infra/dotenv.ts)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[clawsweeper]

ClawSweeper PR egg

✨ Hatched: 🥚 common Brave Shellbean

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

• Merged PRs are hatchable.
• Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
• Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 🥚 common.
Trait: polishes edge cases.
Image traits: location workflow harbor; accessory miniature diff map; palette sunrise gold and clean white; mood celebratory; pose waving from a small platform; shell soft speckled shell; lighting calm overcast light; background little resolved-comment flags.
Share on X: post this hatch
Copy: My PR egg hatched a 🥚 common Brave Shellbean in ClawSweeper.

What is this egg doing here?

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.

[pgondhi987]

@clawsweeper re-review

Updated the PR body with real behavior proof and the latest sanitizer scope.

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26517561724
• Updated: 2026-05-27T14:37:51.547Z