Harden update environment path resolution

Summary

• Problem: Workspace dotenv loading allowed a Windows local app-data root variable to enter process env, and update path setup could use a supplied env object to locate portable Git.
• Why it matters: The update flow later runs Git commands, so the executable search path must not be derived from workspace-controlled values.
• What changed: Workspace dotenv now blocks the Windows local app-data key, and portable Git path discovery reads the process-local value only.
• What did NOT change (scope boundary): No updater command sequence, package manager behavior, CI, release, or workflow files changed.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related Fix Cloud Code Assist API errors (429/400) #544
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: Workspace .env filtering did not block the Windows local app-data key, and portable Git discovery trusted an explicit env object before process.env.
• Missing detection / guardrail: Existing tests covered other workspace-controlled host roots, but not the Windows local app-data root used by the update path.
• Contributing context (if known): The update env helper prepends existing portable Git directories on Windows before update commands run.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/infra/dotenv.test.ts, src/infra/update-global.test.ts
• Scenario the test should lock in: Workspace dotenv cannot set the Windows local app-data key, and portable Git prepends are resolved only from the trusted process-local value.
• Why this is the smallest reliable guardrail: The bug is in env filtering and update env construction, so unit tests directly cover both branches without running a full update.
• Existing test that already covers this (if any): Existing workspace dotenv blocklist tests covered nearby host-root variables but not this key.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Windows update path setup no longer derives portable Git directories from a workspace-provided local app-data value.

Diagram (if applicable)

Before:
[workspace .env] -> [local app-data env] -> [portable Git PATH prepend]

After:
[workspace .env] -> [blocked key]
[process env] -> [portable Git PATH prepend]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (Yes)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: The command resolution surface is narrowed by preventing workspace dotenv values from selecting the portable Git root used during updates.

Repro + Verification

Environment

• OS: Linux 6.8.0-110-generic x86_64
• Runtime/container: Node v22.14.0, pnpm 10.33.2
• Model/provider:
• Integration/channel (if any): N/A
• Relevant config (redacted): N/A

Steps

1. Create a workspace .env containing a Windows local app-data key that points at an attacker-controlled portable Git tree.
2. Trigger update env construction for the Windows update flow.
3. Run the targeted infra unit tests.

Expected

• Workspace dotenv drops the local app-data key.
• Portable Git path prepends are derived from the trusted process-local value, not an injected env object.
• Targeted tests pass.

Actual

• The key is blocked from workspace dotenv.
• The update env helper ignores injected local app-data values when resolving portable Git paths.
• src/infra/dotenv.test.ts and src/infra/update-global.test.ts passed under the infra Vitest config.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Targeted validation:

pnpm exec vitest run --config test/vitest/vitest.infra.config.ts --reporter=verbose src/infra/dotenv.test.ts src/infra/update-global.test.ts
Test Files  2 passed (2)
Tests  52 passed (52)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: Workspace dotenv blocking for the Windows local app-data key; portable Git path resolution ignores injected env values and honors the trusted process-local value.
• Edge cases checked: Mixed-case and uppercase dotenv keys; no process-local value present; both injected and trusted portable Git directories existing.
• What you did not verify: A full Windows openclaw update run.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: A user expected workspace .env to supply this Windows host-root variable for update behavior.
  • Mitigation: Workspace .env is untrusted for host-root controls; trusted shell or global config remains the source for process-local update environment values.