OpenClaw Onboarding Was Writing Gateway Credentials in Plain Text: The August 21 Fixes and What to Re-Check

On August 21, four related fixes landed on the OpenClaw main branch within a few hours of each other. Read together, they describe a consistent gap in how openclaw onboard and openclaw setup handled gateway credentials: an operator who explicitly asked for reference-based secret storage could still end up with a literal password or token sitting in openclaw.json, and a failed health check during non-interactive onboarding could echo registered secret values into terminal logs and CI output.

None of this is packaged yet. These changes are merged source, not a release — the current npm beta tag still points at 2026.8.1-beta.2 from August 15, which predates all of them. That makes today’s operator action different from a normal upgrade decision: you are auditing what your existing install already wrote to disk, not waiting for a package.

What actually changed

Reference mode wrote some gateway credentials as literals

--secret-input-mode ref promises that newly supplied credentials are not persisted as plaintext. According to PR #126928, that promise held for provider credentials and generated local tokens but not for three specific paths:

• noninteractive local --gateway-password, through both openclaw onboard and openclaw setup;
• noninteractive remote --remote-token and --remote-password;
• interactive QuickStart when an explicit local gateway password was already seeded.

In each case onboarding exited successfully and then openclaw secrets audit --check --json immediately flagged the same install with PLAINTEXT_FOUND. The fix requires those inputs to match dedicated environment variables (OPENCLAW_GATEWAY_PASSWORD, OPENCLAW_GATEWAY_TOKEN) and persists a canonical environment reference instead of the literal string. Mismatched or missing environment values now fail before any config write or reset runs. No new flags, schema, or migration involved.

The generated gateway token ignored ref mode entirely

An earlier fix in the same series, commit df2cc8f, closed a quieter variant: --secret-input-mode ref was silently ignored for gateway.auth.token. Setup minted the token itself and wrote it into openclaw.json as a plaintext string, so a fresh install warned about its own plaintext secret on first Doctor run. Worse, the remediation the warning suggested (openclaw secrets configure) cannot migrate a self-generated value, because it validates a reference by resolving one that already exists — there was no supported path out.

Reference mode now provisions the token properly: an ambient OPENCLAW_GATEWAY_TOKEN becomes an environment reference (so later rotations stay authoritative), and anything else goes into the shared SQLite secret store as a write-only entry, with config holding only a store pointer. An existing store entry wins over a freshly generated one, so reruns never rotate a token already paired with clients. The store write happens before the config write, so a crash cannot leave a config pointing at a value that was never stored.

Failure output could echo registered secrets

PR #127071 fixed a third exposure surface: when noninteractive onboarding failed a gateway health check, probe errors, daemon diagnostics, or recovery details embedded in that output could include registered secret values. The failure-output owner now redacts the complete payload before rendering JSON or human-readable diagnostics, while classification still uses the original values so recovery guidance stays accurate. The PR’s evidence includes a trufflehog scan over the exact patch returning zero findings.

Remote mode now rejects local-only credentials

A fourth change, commit b6c5d84, is misconfiguration hygiene rather than exposure repair: local gateway credentials passed while targeting a remote gateway are rejected instead of being accepted and then failing later in confusing ways.

Why these belong together

Individually, each fix looks narrow. Together they show the onboarding tooling had drifted out of sync with the SecretRef contract the rest of the product enforces: audits flagged installs that onboarding itself had just created, and one remediation path was structurally impossible for self-generated tokens. If you scripted headless provisioning recently, the most likely residue is a handful of PLAINTEXT_FOUND findings you may have written off as audit noise — they were real.

Interpretation, clearly labeled: the pattern suggests the plaintext guarantee was tested per-flag rather than across the full matrix of auth modes and input styles. The maintainers’ own evidence sections support this reading; every fix ships with before/after proofs against isolated temporary state.

What to do on existing installs

These fixes prevent recurrence on future runs once you are running patched source. They do not clean up anything already written. For installs provisioned before August 21:

1. Run the audit. openclaw secrets audit --check --json and treat every PLAINTEXT_FOUND under gateway.auth.* as actionable, not cosmetic.
2. Rotate, don’t just migrate. Any gateway password or token that sat in openclaw.json should be treated as exposed to everything that can read that file: backups, dotfile sync, editors’ history, CI logs. Move it to a SecretRef-backed store and replace the value.
3. Re-run onboarding paths in a scratch profile after you adopt patched source, and confirm the audit comes back clean for the same flag combinations you use in production.
4. Check failure logs too. If a noninteractive onboarding run failed since you adopted SecretRefs, grep its captured output for the credential values themselves before archiving those logs.
5. Pin versions in automation. Until this lands in a tagged release, scripts that install from main get the fixes immediately; anything pinned to a beta does not.

Status and caveats

All four changes are merged to main between roughly 00:47 and 07:43 UTC on August 21, per their commit and merge records. None appears in 2026.8.1-beta.2 or any stable package. There is no advisory, CVE, or maintainer statement of active exploitation connected to these merges — this is proactive hardening of default behavior, and we label it as such rather than inflating it. The strongest reason to act is mundane: if your automation provisions gateways headlessly, the old behavior wrote credentials where your audit policy says they must never be.