1. ui/src/ui/storage.node.test.ts, line 16-17 (link)

   setTestLocation produces a bracketed hostname that doesn't match URL.hostname

   For host = "[::1]:18789", the test mock derives hostname by stripping the port with host.replace(/:\d+$/, ""), yielding "[::1]" (brackets retained). Real browser location.hostname for an IPv6 address is "::1" (no brackets), so this mock already diverges from reality — but more critically, normalizeGatewayTokenScope calls URL.hostname on a freshly-parsed URL, not location.hostname, so the bracketed value in the mock has no bearing on whether normalizeGatewayTokenScopeHost matches "[::1]". The test exercises a code path that would pass with the bracketed mock but fail in production where URL.hostname always returns the un-bracketed form.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: ui/src/ui/storage.node.test.ts
   Line: 16-17
   
   Comment:
   **`setTestLocation` produces a bracketed `hostname` that doesn't match `URL.hostname`**
   
   For `host = "[::1]:18789"`, the test mock derives `hostname` by stripping the port with `host.replace(/:\d+$/, "")`, yielding `"[::1]"` (brackets retained). Real browser `location.hostname` for an IPv6 address is `"::1"` (no brackets), so this mock already diverges from reality — but more critically, `normalizeGatewayTokenScope` calls `URL.hostname` on a freshly-parsed URL, not `location.hostname`, so the bracketed value in the mock has no bearing on whether `normalizeGatewayTokenScopeHost` matches `"[::1]"`. The test exercises a code path that would pass with the bracketed mock but fail in production where `URL.hostname` always returns the un-bracketed form.
   
   How can I resolve this? If you propose a fix, please make it concise.

Best possible solution:

Land a refreshed Control UI storage fix only after maintainers confirm the accepted loopback alias boundary, preserve isolation for distinct loopback gateways, add same-origin or browser-real proof, and remove the changelog edit.

Do we have a high-confidence way to reproduce the issue?

Yes, by source inspection: current main keys gateway tokens and per-gateway session selection by exact parsed host, while the linked discussion documents localhost versus 127.0.0.1 token fragmentation. I did not run a live browser reproduction.

Is this the best way to solve the issue?

No as submitted. The Control UI storage layer is a plausible owner path, but the broad 127/8 alias boundary, browser-origin proof gap, changelog edit, and conflicting uneditable branch state need resolution first.

Full review comments:

• [P1] Do not collapse all numeric 127/8 token scopes — ui/src/ui/storage.ts:33
isIpv4LoopbackLiteral() makes ws://127.0.0.1:18789/openclaw and ws://127.255.255.255:18789/openclaw normalize to the same storage key. That key feeds gateway tokens, URL-edit token preservation, and sessionsByGateway, so a distinct local listener on another 127/8 address can receive the previous gateway's auth token/session unless maintainers explicitly accept that boundary.
  Confidence: 0.88
• [P2] Prove alias reuse without changing page origins — ui/src/ui/storage.node.test.ts:284
  This test switches location.host between loopback aliases while retaining one mocked sessionStorage. Browser sessionStorage is origin-scoped, so the test can pass without proving a dashboard navigation between those hosts carries the token; add same-origin gatewayUrl-edit coverage or browser-real proof for the supported flow.
  Confidence: 0.84
• [P3] Remove the release-owned changelog entry — CHANGELOG.md:16
CHANGELOG.md is release-generated in this repo, and normal PR release-note context belongs in the PR body or commit message. Keeping this line turns a narrow UI auth/storage fix into release bookkeeping and should be dropped before merge.
  Confidence: 0.93

Overall correctness: patch is incorrect
Overall confidence: 0.89

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 5361e5a0b455.

Label justifications:

• P2: This is a normal-priority Control UI auth/storage bug fix with limited blast radius, but the submitted PR needs revision before merge.
• merge-risk: 🚨 compatibility: The PR changes browser storage key equivalence for existing gateway URLs and can alter which token or settings record is loaded after upgrade.
• merge-risk: 🚨 session-state: The normalized gateway scope is also used for sessionsByGateway, so selected Control UI sessions can become associated with a different loopback gateway URL.
• merge-risk: 🚨 security-boundary: The PR broadens gateway auth-token lookup from exact host matching to a shared numeric 127/8 loopback bucket.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🌊 off-meta tidepool and patch quality is 🧂 unranked krab.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This is a bot replacement PR, so the external-contributor proof gate does not apply, but browser-real proof is still useful for the sessionStorage origin behavior.

PR surface:

Source +31, Tests +84, Docs +1. Total +116 across 3 files.

Security concerns:

• [medium] Broad numeric loopback token-scope sharing — ui/src/ui/storage.ts:33
  The PR can reuse one gateway token for another local service bound to a different numeric 127/8 address with the same port and path, crossing the exact-host auth boundary current behavior preserves.
  Confidence: 0.88

What I checked:

• Current main exact-host scope: Current main builds the gateway storage scope from protocol, exact parsed host, and pathname, so localhost and 127.0.0.1 remain distinct today. (ui/src/ui/storage.ts:151, 5361e5a0b455)
• Scope consumers: The same normalizer feeds token sessionStorage keys, per-gateway session selection, same-scope URL-edit token preservation, settings keys, and sessionsByGateway persistence. (ui/src/ui/storage.ts:157, 5361e5a0b455)
• PR broadens numeric loopback equivalence: The PR maps every dotted-decimal 127/8 literal to localhost, so 127.0.0.1 and 127.255.255.255 on the same protocol, port, and path share one token/session scope. (ui/src/ui/storage.ts:33, 2057d4113898)
• In-app URL edit path: The Overview gateway URL input calls resolveGatewayTokenForUrlEdit while editing, so a broadened normalized scope can carry the current token into a newly typed gateway URL without changing page origin. (ui/src/ui/views/overview.ts:272, 5361e5a0b455)
• Browser proof gap in added test: The added test changes location.host between loopback aliases while retaining one mocked sessionStorage object, which does not model browser origin-scoped sessionStorage behavior. (ui/src/ui/storage.node.test.ts:284, 2057d4113898)
• Release-owned changelog policy: Root policy says CHANGELOG.md is release-only and normal PRs should carry release-note context in the PR body, squash message, or direct commit instead. (AGENTS.md:234, 5361e5a0b455)

Likely related people:

• velvet-shark: PR fix(ui): preserve control-ui auth across refresh #40892 introduced the Control UI token/session storage path that this PR changes. (role: introduced behavior; confidence: high; commits: f2f561fab1bf; files: ui/src/ui/storage.ts, ui/src/ui/storage.node.test.ts, ui/src/ui/app-settings.ts)
• sallyom: PR Scope Control UI sessions per gateway #47453 scoped Control UI sessions per gateway using the same gateway scope affected by this PR. (role: feature contributor; confidence: high; commits: d37e3d582fd8; files: ui/src/ui/storage.ts, ui/src/ui/storage.node.test.ts)
• steipete: History shows adjacent work keeping dashboard tokens out of URL storage, and the open maintainer-labeled gateway token scopes PR overlaps the broader auth-token area. (role: adjacent owner; confidence: medium; commits: 10d0e3f3ca92; files: ui/src/ui/storage.ts, ui/src/ui/storage.node.test.ts, docs/web/dashboard.md)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.