Summary

• Problem: openclaw gateway status printed a bare Control UI URL while openclaw dashboard could include #token=..., so token-auth setups could open the UI in an unauthenticated state (token_missing).
• Why it matters: users opening the dashboard from status output could see a stuck/non-functional chat surface and assume UI breakage.
• What changed: added a shared Control UI access URL resolver; gateway status now prints gateway.controlUiAccessUrl with safe token-fragment embedding parity with openclaw dashboard; added a SecretRef hint path; redacted token fragments in gateway status --json; added focused tests.
• What did NOT change (scope boundary): no change to gateway auth mode semantics, no SecretRef token embedding in URLs, no new auth provider behavior.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: UI chat not opening openclaw/openclaw#45471
• Related # none
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: status output and dashboard command used different URL-generation paths, causing token-fragment behavior drift.
• Missing detection / guardrail: no test asserted token-fragment parity and JSON redaction in daemon status output.
• Prior context (git blame, prior PR, issue, or refactor if known): openclaw dashboard already resolved token-aware URLs; status path used raw link generation.
• Why this regressed now: long-standing parity gap became visible in token-auth usage patterns.
• If unknown, what was ruled out: ruled out changing auth mode or SecretRef behavior as the fix target.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file:
  • src/commands/control-ui-access-url.test.ts
  • src/cli/daemon-cli/status.print.test.ts
  • src/cli/daemon-cli/status.gather.test.ts
  • src/commands/dashboard.test.ts
• Scenario the test should lock in: status/dashboard URL parity for token embedding rules and token redaction in JSON output.
• Why this is the smallest reliable guardrail: behavior is deterministic command-layer logic with no external dependency required.
• Existing test that already covers this (if any): dashboard tests covered command behavior; status coverage was added here.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• openclaw gateway status now prints a token-fragment dashboard URL when local token resolution allows it (same safety rules as openclaw dashboard).
• openclaw gateway status --json redacts token fragments from gateway.controlUiAccessUrl.
• SecretRef-backed tokens continue to avoid URL embedding and now include a clearer hint.

Diagram (if applicable)

Before:
[user runs `openclaw gateway status`] -> [sees bare URL] -> [opens Control UI] -> [token missing / auth prompt]

After:
[user runs `openclaw gateway status`] -> [sees safe tokenized URL when allowed] -> [opens Control UI] -> [authenticated dashboard]

Security Impact (required)

• New permissions/capabilities? (Yes/No): No
• Secrets/tokens handling changed? (Yes/No): Yes
• New/changed network calls? (Yes/No): No
• Command/tool execution surface changed? (Yes/No): No
• Data access scope changed? (Yes/No): No
• If any Yes, explain risk + mitigation: token handling now explicitly redacts token fragments in JSON output and still refuses embedding for SecretRef-managed tokens.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local CLI runtime
• Model/provider: N/A
• Integration/channel (if any): Web Control UI + gateway auth token mode
• Relevant config (redacted): gateway.auth.mode=token, gateway.auth.token set (plain token and SecretRef scenarios)

Steps

1. Configure token auth and run openclaw gateway status.
2. Open dashboard URL from status output.
3. Run openclaw gateway status --json and inspect gateway.controlUiAccessUrl.

Expected

• Status URL follows dashboard token-embedding rules.
• JSON output does not leak #token=....

Actual

• Implemented and verified in tests + local checks.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios:
  • token-fragment URL generation parity between status and dashboard
  • SecretRef non-embedding path + hint
  • JSON token redaction
• Edge cases checked:
  • unresolved token references
  • LAN bind coercion path used by dashboard links
• What you did not verify:
  • full end-user browser flow on every OS variant (validated command/test layer)

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No): Yes
• Config/env changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: token-bearing URLs shown in terminal output when local token resolution is allowed.
  • Mitigation: preserve SecretRef non-embedding behavior and redact token fragments from JSON output.