Greptile Summary

Adds a CVE-safe recovery hint to dashboardCommand that fires when both clipboard copy and browser auto-open fail and the token URL was intended for delivery. The hint correctly avoids logging the token value or the populated fragment string, and a new regression test pins the contract.

Two P2 observations worth considering before merging:

• The hint message tells users to "append as a URL fragment" but omits the fragment key name, which may leave headless users uncertain about the exact URL syntax needed.
• The condition !copied && !opened && includeTokenInUrl also triggers when --no-open is used and clipboard fails, producing two simultaneous hints whose combined message could be slightly misleading.

Confidence Score: 4/5

Safe to merge; only P2 UX and coverage concerns, no runtime defects introduced.

The change is small and well-targeted. No P0 or P1 bugs were found. The two P2 observations (missing fragment key name in hint, and double-hint in --no-open + clipboard-fail path) are UX and coverage issues, not correctness defects. CVE safety contract is preserved by both the implementation and the updated test suite.

No files require special attention; src/commands/dashboard.ts lines 95–99 are the only new logic and both concerns relate to that block.

This is a comment left during a code review.
Path: src/commands/dashboard.ts
Line: 95-99

Comment:
**Hint fires in `--no-open` + clipboard-fail path too**

When a user explicitly passes `--no-open`, `opened` is always `false` (never assigned in the `noOpen` branch), so if clipboard also fails, this block fires alongside the existing `--no-open` hint ("Browser launch disabled (--no-open). Use the URL above."). The user sees two partially contradictory messages: one telling them to use the bare URL above, and one telling them to manually construct the fragment URL. The existing test at line 201 doesn't assert absence of the new hint, so this goes undetected.

If the intent is for the hint to fire in the `--no-open` scenario as well (the PR description says it does), it would be worth adding a test covering that scenario explicitly, and confirming the two messages together make sense.

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

---

This is a comment left during a code review.
Path: src/commands/dashboard.ts
Line: 95-99

Comment:
**Hint omits the URL fragment key name**

The message says "append your gateway token… as a URL fragment" but doesn't name the key (`token`). A headless user who hasn't seen the source will need to guess or consult docs to construct the correct fragment. The CVE constraint prohibits logging an actual secret value, but logging only the key name — with an explicit placeholder and no real value — carries no credential risk and would not trigger the existing CVE assertions.

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

_{Reviews (1): Last reviewed commit: "fix(dashboard): guide users to manual to..." | Re-trigger Greptile}

Addressed both P2 observations in commit 1204cc61b9:

P2-1 — fragment key name: the hint now names the URL fragment key (`token`) explicitly so headless users know the URL syntax. The literal #token= substring is still avoided to keep the existing CVE regression tests at dashboard.links.test.ts:121 and :165 passing — the new wording uses backticks around the key name and a paraphrase of the fragment placement, which is unambiguous to humans without spelling out the forbidden substring.

P2-2 — double hint in --no-open + clipboard-fail: named the state (fallbackToManualAuth) and added a suppressNoOpenHint gate so the redundant "Browser launch disabled (--no-open). Use the URL above." is suppressed when the manual-auth hint speaks for that scenario. The SSH-path hint is preserved (its info — port forwarding — is complementary, not redundant).

Test coverage updated:

• New assertion in the CVE-safe test pins that the hint contains the literal substring `token` (key name).
• The pre-existing respects --no-open with plain URL hint when clipboard fails test was split into two: one for the token-configured case (now asserts suppression + manual-auth hint), and a preserved one for the no-token case (still expects "Use the URL above.").

All CVE regression tests still pass; 11/11 in dashboard.links.test.ts, 4/4 in dashboard.test.ts, full pnpm check:changed is green.

Thanks for the QC review. Both non-blocking suggestions were independently raised by @greptile-apps and addressed in commit 1204cc61b9:

• Fragment key name — the hint now includes key `token` so headless users know the URL syntax. The literal #token= substring is intentionally avoided to keep the existing CVE regression tests at dashboard.links.test.ts:121 and :165 passing.
• --no-open message dedup — suppressNoOpenHint is now gated on options.noOpen === true && fallbackToManualAuth, so the redundant "Browser launch disabled (--no-open). Use the URL above." is suppressed when the manual-auth hint speaks for that scenario. The SSH-path hint is preserved (its info is complementary, not redundant).

pnpm test src/commands/dashboard.links.test.ts src/commands/dashboard.test.ts passes 15/15, including the existing CVE regression tests and a new no-token-preservation test.

Both addresses look correct.

The key \token`literal in the hint message threads the needle well — it tells headless users the URL syntax without triggering the CVE regression on#token=`. The test at line 184 pins that contract explicitly.

The suppressNoOpenHint logic is also clean: it's scoped to options.noOpen === true && fallbackToManualAuth, so the SSH-path hint (which comes from formatControlUiSshHintMock and takes the same hint && branch) is unaffected — options.noOpen won't be true on that path.

The split of the old --no-open test into token-configured vs. no-token-configured cases is a nice touch too; the coverage is now unambiguous.

LGTM. No further concerns.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules and .greptile/config.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/25349172574
• Updated: 2026-05-04T23:33:09.676Z

Codex review: needs maintainer review before merge.

Summary
The PR adds a dashboard CLI manual-auth fallback hint, regression tests, and a changelog entry for tokenized URL delivery failures.

Reproducibility: yes. Source inspection gives a high-confidence path: configure a literal gateway.auth.token or OPENCLAW_GATEWAY_TOKEN, make clipboard delivery fail, and make browser opening unavailable or pass --no-open; current main logs the bare dashboard URL without token-source or fragment-key recovery guidance.

Next step before merge
No repair PR is needed because this PR already contains the focused implementation; the remaining action is maintainer review plus exact-head validation.

Security
Cleared: Cleared: the diff only changes dashboard CLI logging, regression tests, and changelog text, with no dependency, workflow, install, release, or secret-value logging expansion.