Summary

allowInsecurePath: true does two things at runtime, but the docs only describe one:

1. Documented: bypass the Windows ACL verification fail-closed check.
2. Undocumented: bypass the Linux uid-equality check (stat.uid !== process.getuid()).

Without (2), Linux users with any system-package-managed binary as a SecretRef exec command — e.g. /usr/bin/op (1Password), /usr/bin/sops, /opt/homebrew/bin/<bin> — get this error on first credential resolution:

secrets.providers.<name>.command must be owned by the current user (uid=<n>): /usr/bin/op

…and have no obvious way to fix it without reading the dist source.

Source-level evidence

dist/resolve-a2RZM0d2.js assertSecurePath() (lines 99–135 in 2026.5.4 / 325df3e):

async function assertSecurePath(params) {
  // ... symlink + trustedDirs checks ...
  if (params.allowInsecurePath) return effectivePath;   // <-- short-circuits everything below

  const perms = await inspectPathPermissions(effectivePath);
  // ... worldWritable / groupWritable / readableByOthers checks ...
  if (process.platform === "win32" && perms.source === "unknown")
    throw new Error(`${params.label} ACL verification unavailable on Windows for ${effectivePath}. Set allowInsecurePath=true for this provider to bypass this check when the path is trusted.`);

  if (process.platform !== "win32" && typeof process.getuid === "function" && stat.uid != null) {
    const uid = process.getuid();
    if (stat.uid !== uid)
      throw new Error(`${params.label} must be owned by the current user (uid=${uid}): ${effectivePath}`);
  }
  return effectivePath;
}

So allowInsecurePath: true skips ALL of:

• world/group writable check
• world/group readable check
• Windows ACL check
• Linux uid-equality check ← the relevant one for system-package binaries

What docs say today

docs/gateway/secrets.md (under both File-provider and Exec-provider Accordion blocks):

Windows fail-closed note: if ACL verification is unavailable for a path, resolution fails. For trusted paths only, set allowInsecurePath: true on that provider to bypass path security checks.

docs/cli/secrets.md mentions it analogously. docs/gateway/configuration-reference.md describes the schema field but no behavior. Neither file mentions the Linux uid-check or the system-package-binary use case.

Reproduction (Linux, fresh setup)

# 1Password CLI installed via apt → owned by root:root
$ ls -l /usr/bin/op
-rwxr-xr-x 1 root root … /usr/bin/op

# Configure an exec provider WITHOUT allowInsecurePath
$ jq '.secrets.providers.onepassword_test = {
  "source": "exec",
  "command": "/usr/bin/op",
  "args": ["read", "op://Vault/Item/credential"],
  "passEnv": ["HOME","OP_SERVICE_ACCOUNT_TOKEN"]
}' ~/.openclaw/openclaw.json | sponge ~/.openclaw/openclaw.json

# Trigger resolution
$ openclaw secrets reload
Error: secrets.providers.onepassword_test.command must be owned by the current user (uid=1000): /usr/bin/op

Add "allowInsecurePath": true and resolution succeeds.

Why this matters

System-package binaries are the safest, not the most insecure, place to put a SecretRef exec command:

• Owned by root (immutable by unprivileged processes).
• Lives on a non-world-writable system path (/usr/bin, /opt/homebrew/bin, etc.).
• Gets security updates from the package manager.

The current naming (allowInsecurePath) suggests the user is trading away security to make it work, when they're actually doing the most secure thing. Combined with the missing docs, new Linux users hit this on their first 1Password setup and assume the option is a hack.

Suggested fix

Option A (preferred): docs-only.

Add to docs/gateway/secrets.md Exec-provider Accordion:

- `allowInsecurePath: true` also bypasses the Linux uid-equality check that requires `command` to be owned by the running user. Use this for system-package binaries managed by your OS package manager (e.g. `/usr/bin/op`, `/opt/homebrew/bin/sops`), which are intentionally root-owned and live on non-world-writable system paths. The check enforces "command must be locked down to the current user"; on Linux that fights system-package binary patterns. Do not use `allowInsecurePath` for paths in `/tmp`, user `~/Downloads`, or other unmanaged locations.

Mirror the same note in the File-provider Accordion since assertSecurePath is shared.

Option B (more invasive): split the option.

Replace the single allowInsecurePath boolean with finer-grained controls:

• allowSystemPath: true — bypass Linux uid check ONLY, keeping permission checks active. Documented as the right knob for system-package binaries.
• allowInsecurePath: true — bypass everything (current behavior). Documented as last-resort, e.g. for Windows ACL-unverifiable paths.

Provides the right semantics for users without forcing them to broadcast "this is insecure" when it isn't. But Option A is sufficient for now.

Environment

• OpenClaw 2026.5.4 (325df3e)
• Linux x64, Node v22.22.2
• 1Password CLI 2.x installed via official apt repo

Related

• #43389 (closed): macOS SIP-protected /usr/bin/* exec providers — same code path, different platform-specific symptom. Cross-link as evidence the cross-platform behavior of allowInsecurePath deserves first-class documentation.
• The same allowInsecurePath block in the dist short-circuits the Windows ACL check and the Linux uid check, so any docs change should cover both platforms together.