Greptile Summary

This PR correctly fixes a localStorage key collision that occurred when multiple Gateway instances were deployed under the same domain with different basePaths. The settings key is now scoped per gateway URL (openclaw.control.settings.v1:<gatewayUrl>) following the same pattern already used for token storage, and a backward-compatible fallback chain handles migration from the legacy static key.

Findings:

• The inline comments at lines 195 and 268 describe the lookup fallback order backwards — they say "legacy first, scoped second" but the code checks the scoped key first and the legacy key last.
• The legacy "openclaw.control.settings.v1" key is never explicitly removed from localStorage after migration. It will linger indefinitely as stale data, though it won't affect behavior once the scoped key is written.
• The intermediate SETTINGS_KEY_PREFIX + "default" fallback in the lookup chain (openclaw.control.settings.v1:default) is a new-format key that could only have been written by this new code when gatewayUrl is empty, so it is unlikely to aid migration from the old system in practice.

Confidence Score: 4/5

• PR is safe to merge; the core scoping logic is correct and migration is handled, with only minor style and cleanup concerns.
• The fix correctly follows the existing token-scoping pattern and migration from the legacy key works as intended. The two identified issues — a backwards comment and missing cleanup of the legacy key — are non-blocking style/best-practice concerns that don't affect correctness.
• ui/src/ui/storage.ts — review the backwards comment and consider adding explicit legacy key cleanup after migration.

This is a comment left during a code review.
Path: ui/src/ui/storage.ts
Line: 196-197

Comment:
**Legacy key never removed after migration**

When `loadSettings` (or `persistSettings`) reads from the legacy key `"openclaw.control.settings.v1"` and successfully migrates to the new scoped key, the old entry is never deleted from `localStorage`. While this is not a functional bug today (the scoped key takes priority), it leaves stale data in storage indefinitely and could cause confusion if the scoped key is somehow absent in the future.

Consider explicitly cleaning up the legacy key after a successful migration write:

```typescript
// After storage?.setItem(scopedKey, ...) in persistSettings:
storage?.removeItem("openclaw.control.settings.v1");
```

Similarly in `loadSettings`, once settings are loaded from the legacy key and `persistSettings` is called (or immediately after the initial load), the legacy key could be removed to avoid it persisting forever.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: ui/src/ui/storage.ts
Line: 195-197

Comment:
**Comment describes lookup order backwards**

The comment says _"First check for legacy key (no scope), then check for scoped key"_, but the actual code does the opposite — it checks the scoped key first and falls back to the legacy key last. The same backwards comment appears at line 268 in `persistSettings`. This will confuse future readers who expect the described order to match the actual precedence.

The comment should read something like: _"First check for scoped key, then fall back to legacy key for migration"_.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 389b83f}

Landed via temp rebase onto main.

• Gate: pnpm check (red on unrelated src/infra/bonjour.ts type error after rebase), pnpm build (pass), pnpm test (red on unrelated cron/outbound/exec-approval suites after rebase), pnpm --dir ui build (pass), pnpm --dir ui exec vitest run --config vitest.node.config.ts src/ui/storage.node.test.ts (pass)
• Land commit: 6061a6a
• Merge commit: 5ece9af

Thanks @bobBot-claw!