Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix doctor: false-positive 'passEnv ref HOME blocked' warning for exec SecretRef providers [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#78216•Fetched 2026-05-07 03:39:33
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
2
Author
esqandilesqandil
Participants
clawsweeper[bot]clawsweeper[bot]esqandilesqandil
Timeline (top)
commented ×1cross-referenced ×1

openclaw doctor emits a false-positive warning for every exec-source SecretRef provider that includes HOME in passEnv:

◇  Config SecretRef ──────────────────────────────────────────────────────╮
│                                                                         │
│  Exec SecretRef passEnv ref "HOME" blocked by host-env security policy  │
│                                                                         │
├─────────────────────────────────────────────────────────────────────────╯

Repeated once per exec-SecretRef provider (e.g., 6× for a config with 6 onepassword exec providers). The runtime correctly resolves the secrets — this is a doctor-only false positive.

Root Cause

Root cause (from reading dist/)

Fix Action

Workaround

Ignore the warning. Runtime resolution works correctly.

PR fix notes

PR #78252: fix(doctor): use isDangerousHostInheritedEnvVarName for exec SecretRef passEnv validation

Description (problem / solution / changelog)

Fixes #78216

Problem

openclaw doctor emits a false-positive warning for every exec SecretRef provider that includes HOME in passEnv:

Exec SecretRef passEnv ref "HOME" blocked by host-env security policy

passEnv entries use inheritance semantics — the exec subprocess inherits the current value of the key from the host environment. This is distinct from override semantics (injecting an arbitrary value via Environment=KEY=VAL in the service unit). The security policy already captures this distinction: HOME is in blockedOverrideOnlyKeys but also in allowedInheritedOverrideOnlyKeys, which means isDangerousHostInheritedEnvVarName("HOME") correctly returns false.

The bug: collectExecSecretRefPassEnvServiceEnvVars was calling isDangerousHostEnvOverrideVarName (override semantics) for a passEnv check (inheritance semantics), causing the false positive.

Fix

Replace the check at daemon-install-helpers.ts:215 with isDangerousHostInheritedEnvVarName, which encodes the correct allowedInheritedOverrideOnlyKeys exclusions. Keys like HOME, SSH_AUTH_SOCK, GRADLE_USER_HOME, ZDOTDIR are no longer false-positively blocked.

Pre-implement audits

  • A (existing helper): isDangerousHostInheritedEnvVarName already exists — reusing it. ✓
  • B (shared-caller check): isDangerousHostInheritedEnvVarName is called in 2 files; I'm adding a third call site to daemon-install-helpers.ts, not mutating its contract. ✓
  • C (rival PR scan): No open PR targeting #78216 or this function. ✓

Test

Added: "includes HOME in passEnv for exec SecretRef without a doctor warning"

Changed files

  • src/commands/daemon-install-helpers.test.ts (modified, +37/-0)
  • src/commands/daemon-install-helpers.ts (modified, +2/-1)

Code Example

◇  Config SecretRef ──────────────────────────────────────────────────────╮
│                                                                         │
│  Exec SecretRef passEnv ref "HOME" blocked by host-env security policy  │
│                                                                         │
├─────────────────────────────────────────────────────────────────────────╯

---

// passEnv check: only test for actually-dangerous-to-inherit keys
const blocked = passEnv.filter(key => isDangerousHostEnvVarName(key));
//                                    ^^ override-blocklist OR'd in here is the bug
RAW_BUFFERClick to expand / collapse

Summary

openclaw doctor emits a false-positive warning for every exec-source SecretRef provider that includes HOME in passEnv:

◇  Config SecretRef ──────────────────────────────────────────────────────╮
│                                                                         │
│  Exec SecretRef passEnv ref "HOME" blocked by host-env security policy  │
│                                                                         │
├─────────────────────────────────────────────────────────────────────────╯

Repeated once per exec-SecretRef provider (e.g., 6× for a config with 6 onepassword exec providers). The runtime correctly resolves the secrets — this is a doctor-only false positive.

Environment

  • OpenClaw 2026.5.4 (commit 325df3e)
  • Linux (Ubuntu 24.04, headless)
  • Secret providers: source: "exec" with command: "/usr/bin/op"
  • Config passEnv: ["HOME", "OP_SERVICE_ACCOUNT_TOKEN"] (HOME is required so op can find ~/.config/op/)

Root cause (from reading dist/)

host-env-security-CUEsxn1u.js includes HOME in both blockedOverrideOnlyKeys and blockedOverrideKeys lists.

auth-install-policy-Bj_AzX3x.js:156 then conflates "blocked override" (which is correct — you can't Environment=HOME=/foo in the unit) with "blocked passEnv inheritance" (which is wrong — passEnv allows the child to inherit the parent's value, no override).

The doctor check should call isDangerousHostEnvVarName(key) (override semantics) only, not isDangerousHostEnvVarName(key) || isDangerousHostEnvOverrideVarName(key), when validating passEnv entries.

Reproduction

  1. Configure any secrets.providers.<name> with source: "exec" and passEnv: ["HOME"]
  2. Run openclaw doctor --non-interactive
  3. Observe the warning per provider

Expected behavior

HOME in passEnv for an exec SecretRef should be allowed without warning. Inheritance is the documented way for op and similar tools to resolve their own user-config files.

Suggested fix

In auth-install-policy-Bj_AzX3x.js:156 (or the equivalent function), separate the two checks:

// passEnv check: only test for actually-dangerous-to-inherit keys
const blocked = passEnv.filter(key => isDangerousHostEnvVarName(key));
//                                    ^^ override-blocklist OR'd in here is the bug

HOME, XDG_*, PATH should be allowed in passEnv even though they're forbidden as Environment= overrides.

Workaround

Ignore the warning. Runtime resolution works correctly.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

HOME in passEnv for an exec SecretRef should be allowed without warning. Inheritance is the documented way for op and similar tools to resolve their own user-config files.

#API middleware#SSR setup#ISR setup#authentication setup#request error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix doctor: false-positive 'passEnv ref HOME blocked' warning for exec SecretRef providers [1 pull requests, 1 comments, 2 participants]