OpenClaw Main Repairs Remote Gateway Authentication Probes and macOS Config Conflicts

OpenClaw has merged a coordinated repair for the macOS app’s remote Gateway path. The three faults sit on the same trust boundary: onboarding could advance without proving authentication, token recovery was not usable from that flow, and a later app sync could overwrite newer external edits to gateway.remote.*.

Upstream reproduces the config conflict on shipped 2026.7.1. The fixes merged after the 2026.7.2-beta.7 tag, so neither version string alone proves they are installed.

Authentication is now the onboarding gate

PR #117904 makes successful Gateway authentication—not merely network reachability—the condition for remote onboarding to continue.

That distinction matters. A TCP or HTTP connection can prove that something answered at an address; it does not prove the app has established the authorized OpenClaw control relationship it needs. Onboarding should not present a remote setup as complete while the next authenticated operation is guaranteed to fail.

Token recovery becomes an explicit operator action

PR #118051 connects safe Gateway token recovery to macOS onboarding. The operator can deliberately recover the configured token through the supported CLI path and enter it into the app rather than being stranded between a reachable remote and an unavailable credential.

Treat recovered tokens as credentials:

• do not paste them into chat, tickets or shell history unnecessarily;
• do not include them in screenshots or diagnostics;
• rotate them if exposure is suspected; and
• verify the remote identity before entering the token.

The correction improves recovery; it does not make the token non-sensitive.

Password-only remotes now pass the actual probe

PR #118134 fixes the initial setup wizard and later configure wizard reporting a healthy password-protected remote Gateway as unreachable.

The old hint path read only gateway.remote.token; the configure health action could select a remote URL while resolving local credentials, and one remote branch returned before running the requested health action. The repaired path resolves the selected remote target’s token-or-password surface through one owner and runs the configured health check.

Target binding is the security-critical part. A local Gateway password is not forwarded to a remote target, and an ambient URL override cannot redirect the selected remote credential to another Gateway. A changed remote URL receives no stored credential unless the operator explicitly supplies one for that target.

Upstream reports a packaged live proof with two isolated password-protected Gateways and synthetic credentials. That is stronger than a mocked reachability test, but operators should still repeat it against their actual reverse proxy and SecretRef policy.

External edits no longer lose to a stale app snapshot

PR #118046 fixes the more destructive configuration race. In remote mode, an external CLI or tool could write newer gateway.remote.* values, then a later app sync could silently restore the app’s older copy.

The merged approach reconciles external changes and adds conflict recovery rather than assuming the app is always the sole writer.

Interpretation: configuration ownership is optimistic concurrency, not “last GUI save wins.” A client holding stale state must detect that the durable configuration changed before publishing its version.

Who should prioritize this

Move the containing build to staging if you:

• use the macOS app against a Gateway on another host;
• rotate remote tokens outside the app;
• automate gateway.remote.* changes;
• switch remote endpoints; or
• saw settings revert after onboarding or app synchronization.

Local-only macOS users are less exposed to this specific cluster.

Safe acceptance test

Use a disposable remote Gateway and synthetic credentials:

1. configure a reachable endpoint with invalid auth and confirm onboarding does not advance;
2. use the supported recovery path with a test token and confirm authenticated onboarding completes;
3. edit one gateway.remote.* value outside the app;
4. let the app observe and synchronize configuration;
5. confirm the newer external value remains or a visible conflict is raised;
6. make a later intentional app edit and confirm it publishes once; and
7. run setup and configure health against a password-only remote while an unrelated ambient Gateway URL is present, and prove credentials stay with the selected target; and
8. restart both sides and verify the same endpoint and auth state remain authoritative.

Record redacted field names and revision timestamps, never token values.

Recovery for affected installations

If remote settings may already have been overwritten:

• stop making competing edits;
• preserve the current config and app logs with secrets redacted;
• identify the intended endpoint and most recent authorized writer;
• verify the remote Gateway identity independently;
• restore one canonical configuration through a supported path; and
• rotate credentials if they were exposed during troubleshooting.

Do not merge two config copies by blindly choosing the newest file timestamp; a stale process can write later than the legitimate change.

Evidence and limits

The official merged PRs establish the authentication gate, token-recovery path and live 2026.7.1 config-overwrite reproduction. OpenClaw Academy did not connect the macOS app to a remote Gateway or handle a real token. Upstream attached compatibility, auth-provider and availability risk to the config reconciliation change, so staged conflict testing remains necessary.

Bottom line

Remote onboarding is complete only after a target-bound authenticated connection, and a macOS client must not overwrite newer remote settings from a stale snapshot. Operators using remote mode should wait for a containing build, then test token and password auth, ambient URL isolation, credential recovery and concurrent config writers together.