OpenClaw Main Repairs macOS Remote Gateway Authentication and 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.

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. 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 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 failed auth, credential recovery and concurrent config writers together.