openclaw - 💡(How to fix) Fix Gateway refuses to start when SecretRef ids contain '#' — breaks the documented aws-secrets-resolver.sh contract

Symptom

Dashboard at http://127.0.0.1:18789/ shows disconnected (WebSocket close 1006). openclaw gateway run exits during startup with SECRETS_RELOADER_DEGRADED. Nothing binds on port 18789.

Error in ~/.openclaw/logs/stability/openclaw-stability-*-gateway.startup_failed.json + stderr:

[secrets] [SECRETS_RELOADER_DEGRADED]
Exec secret reference id must match
/^[A-Za-z0-9][A-Za-z0-9._:/-]{0,255}$/
and must not include "." or ".." path segments.
(ref: exec:awssm:gravity/shared/slack-gateway/credentials#bot_token)
Gateway failed to start: Error: Startup failed: required secrets are unavailable.

Root cause

There is an internal contract mismatch in OpenClaw 2026.5.7 (eeef486).

The bundled AWS Secrets Manager resolver script template documents — and parses — IDs in the form:

<aws-secret-id>#<json-key> e.g. gravity/shared/slack-gateway/credentials#bot_token

The resolver literally splits on the last #:

secret_id="${id%#*}"
json_key="${id##*#}"

But the SecretRef id field validator in 2026.5.7 enforces:

/^[A-Za-z0-9][A-Za-z0-9._:/-]{0,255}$/

That regex does not include #. So any config produced against the documented convention fails validation before the resolver is ever invoked. The validator and the bundled tool ship together and contradict each other.

Affected configs

Any field that takes an exec SecretRef pointing at an AWS Secrets Manager JSON-keyed secret. Most natural surface is Slack:

{
  "channels": {
    "slack": {
      "accounts": {
        "panita": {
          "botToken": { "source": "exec", "provider": "awssm", "id": "gravity/shared/slack-gateway/credentials#bot_token" }
        }
      }
    }
  }
}

…but the same shape applies to every SecretRef-supported field listed at https://docs.openclaw.ai/reference/secretref-credential-surface.

Reproduction

1. Have a working ~/.openclaw/openclaw.json with inline botToken/appToken strings.
2. Migrate them to SecretRef objects in the documented form: { source: "exec", provider: "awssm", id: "secret-name#json-key" }. (This is what running openclaw doctor --fix or the SecretRef wizard appears to produce given the resolver template's documented contract.)
3. Run openclaw gateway start (or restart the LaunchAgent). It exits with the validator error above; nothing binds; dashboard shows 1006.

Expected fix

Pick one — but please pick one:

• (a) Allow # in the SecretRef id regex. Matches the documented resolver contract; lowest-impact change.
• (b) Change the documented contract + bundled aws-secrets-resolver.sh template to use a separator already in the allowed character class (e.g. : or /); update any wizard/doctor flow that writes these IDs.

Either way, the wizard that migrates configs should never produce a SecretRef the validator will reject.

Workaround (for context)

Restore ~/.openclaw/openclaw.json from the auto-saved .pre-secretref-* backup, reverting credentials to inline strings. Gateway starts cleanly and the dashboard reconnects.

Diagnostic note

The user-visible symptom is a generic WebSocket 1006. The actual reason lives in ~/.openclaw/logs/stability/openclaw-stability-*-gateway.startup_failed.json. Suggest improving the dashboard error surface (or openclaw gateway status output) so users hit the real reason before chasing the WS error.

Environment

• OpenClaw 2026.5.7 (eeef486)
• macOS Darwin 24.6.0 (arm64)
• Node v22.22.0 (bundled toolchain)
• LaunchAgent mode