OpenClaw Secrets Resolution Gets Quieter and More Honest

A tight series of four secret-handling fixes merged on August 21–22. None of them is dramatic alone; together they mark a shift in how OpenClaw treats secret references — toward failing loudly instead of silently, preserving where a value came from, and refusing to persist obviously broken input.

Fail closed on unresolvable references

The most consequential change is behavioral: when a configured secret reference cannot be resolved — a missing file, an absent environment variable, a dangling store entry — resolution now fails closed rather than proceeding with whatever partial state it had (PR #127669). For operators this trades a silent misconfiguration for a hard startup or reload error naming the reference that could not resolve.

The practical consequences:

• Deployments with incomplete secret setups will refuse to start or reload where they previously limped along with some channels or providers silently degraded.
• That is the desired trade for anything touching provider authentication: an assistant that starts without its real API key tends to discover it mid-conversation, in front of users.
• Plan the upgrade accordingly: inventory your env:/file/store secret references before updating, because latent gaps that used to be tolerated will now surface as explicit errors.

Provenance survives the gateway

PR #127685 fixes provenance tracking for values authored via environment-variable shorthand. When configuration was read through the gateway’s auth paths, the record of how a value was authored (direct literal vs. ${ENV_VAR} shorthand vs. file reference) could be lost, which made diagnostics ambiguous — operators debugging auth failures could not reliably tell whether they were looking at the value they wrote or a transformed copy of it. Provenance scope is kept deliberately narrow (carried through auth reads rather than broadcast), so the fix improves debuggability without widening exposure of secret values themselves.

The UI stops you saving empty protected secrets

PR #127740 adds local validation to the Control UI’s secrets page: attempting to save an empty value for a protected secret field is now blocked client-side before it ever reaches the Gateway. Previously such a save could propagate an empty placeholder into gateway state and produce confusing downstream resolution failures — precisely the class of broken state the fail-closed change above now refuses to tolerate. The two fixes meet in the middle: one refuses bad values at the UI boundary, the other refuses them at resolution time.

Unused speech secrets stop blocking startup

Not every fix tightens; PR #127687 loosens one over-tight path. Voice/Talk configurations referencing speech provider secrets that were not actually needed by enabled plugins could block gateway startup. Selected speech secrets are now isolated so unused ones neither fail closed nor wedge boot. This is the correct counterweight: strictness should apply to secrets that are genuinely in play, not to dormant leftovers from experiments. Legacy-config migration shapes were covered with tests, and plugin manifest docs were updated in the same PR.

What operators should do

1. Before upgrading, run your own secret inventory: list every configured reference across channels, providers, and plugins, and resolve each manually once. Anything that fails will now block startup instead of degrading quietly.
2. Stage the rollout if you have many environments — let a canary gateway absorb the new fail-closed errors first and turn them into config fixes.
3. Use provenance-aware debugging after the upgrade when tracing auth issues; the authoring form of each value is now reliable evidence.
4. Clean up dormant speech-provider secrets if voice features are disabled; they no longer hurt, but removing dead references keeps fail-closed errors meaningful.

Interpretation note: behavior summaries follow the merged diffs and their tests; upgrade-risk judgments are ours. No published advisory accompanies these changes.