Bug type

Behavior bug (incorrect output/state without crash)

Summary

Control UI shares a single localStorage key across all basePath instances, causing settings from one Gateway to be incorrectly applied to another when multiple Gateways are deployed under the same domain.

Steps to reproduce

1. Deploy two Gateway instances under the same domain with different basePaths:
   - https://example.com/gateway-a/ → Gateway A
   - https://example.com/gateway-b/ → Gateway B
2. Open https://example.com/gateway-a/chat in a browser
   - Connect to Gateway A (default URL correctly inferred from basePath)
   - Change any setting (e.g., theme, split ratio, nav width)
3. Open https://example.com/gateway-b/chat in a new tab
   - Observe the Control UI connection
4. (Optional) Modify settings in the /gateway-b/ tab, then refresh /gateway-a/

Expected behavior

• Each basePath instance (/gateway-a/, /gateway-b/) should maintain independent settings in localStorage
• Opening https://example.com/gateway-b/chat should connect to Gateway B with its own settings
• Settings changed in one Gateway should not affect the other

Actual behavior

• All basePath instances share the same localStorage key: "openclaw.control.settings.v1"
• Opening https://example.com/gateway-b/chat reads gatewayUrl from localStorage (saved by /gateway-a/)
• User connects to Gateway A instead of Gateway B
• Settings (theme, layout, etc.) from one Gateway incorrectly apply to another
• Modifying settings in one tab overwrites settings for all basePath instances

OpenClaw version

2026.3.13

Operating system

Ubuntu 24.04

Install method

No response

Model

minimax

Provider / routing chain

openclaw -> minimax

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

https://github.com/user-attachments/assets/97aac9e9-5d30-4603-80e1-c0672e435a82

Impact and severity

No response

Additional information

Root cause:

• loadSettings() in ui/src/ui/storage.ts uses a single key for all basePath values
• localStorage values take priority over URL-inferred defaults
• inferBasePathFromPathname() correctly derives basePath, but the storage layer does not use it for key isolation

Impact scenarios:

• Enterprise deployments with multiple team Gateways under one domain
• Reverse proxy setups serving multiple Gateway instances at different paths
• Development/testing with multiple local Gateway instances

Affected versions:

• Likely all versions with Control UI (needs verification)

Workaround:

• Manually clear localStorage when switching between Gateway basePaths
• Use separate domains/subdomains for each Gateway (not always feasible)

Proposed fix:

• Append normalized basePath to localStorage key (e.g., "openclaw.control.settings.v1:/gateway-a")
• Implement migration logic to preserve existing settings for upgraded users
• Maintain backward compatibility for root-path deployments (basePath = "")