OpenClaw merged a security-focused configuration repair in PR #117128, closing a gap between openclaw config validate and the stricter checks that run during startup.
The issue was straightforward but important. A manually configured exec-based SecretRef provider could pass validation even when its command path would later be rejected because it was missing, symlinked, writable by others, or not owned by the current user. That meant an operator could save a configuration that looked valid, only to discover the problem during restart.
What Changed
The validator now shares the startup command-path trust check instead of approximating it. That means unsafe SecretRef exec command paths are caught at acceptance time, before the config is persisted as valid operational state.
The PR is careful about scope. The validator does not execute the provider command, and it does not loosen startup policy. It simply brings the earlier validation boundary into alignment with the path trust rules that startup already enforced.
The change also consolidates related config mutation paths so validation cannot drift by operation type. According to the PR, config set, config patch, and config unset now run through one mutation owner for preflight, validation, persistence, and apply hints. Patch deletions use the same operation constructor as unset, which matters because deleting a provider subfield should not bypass SecretRef preflight.
Why It Matters
SecretRef command providers sit on a sensitive edge: they are configured paths that can produce credentials. If the path is symlinked, writable by other users, or unexpectedly absent, OpenClaw should reject that before the system relies on it.
Earlier rejection also improves operator ergonomics. A validation command should be a meaningful gate, not a weaker approximation that allows a restart-time failure. This is especially true for headless or automated installations where config updates and restarts may be separated by time or handled by different workflows.
Operator Impact
For most users, the change should appear as clearer failure timing. A bad exec SecretRef command path fails during configuration validation instead of during the next startup.
The repaired checks cover path properties such as:
- Missing command targets
- Symlinked command paths
- Command files writable by others
- Command files not owned by the current user
- Patch and unset operations that modify provider metadata
Valid existing commands that already satisfy startup trust policy should keep working. The PR explicitly says startup policy is not tightened by this change; the earlier config gate now uses the same trust decision.
Verification Notes
The PR reports direct coverage for the validation gap and related mutation paths, including config patch deletion behavior. It also documents the motivating user report: a symlinked command passed validation and then failed on restart.
This is the kind of repair that does not add a flashy feature, but it strengthens a boundary users depend on. OpenClaw now gives operators a faster, more accurate answer when a SecretRef exec provider command is not safe enough to accept.