Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: openclaw dashboard opens localhost URL even when the local gateway is unreachable [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#55003•Fetched 2026-04-08 01:33:47
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
PeterleixxPeterleixx
Participants
PeterleixxPeterleixx
Timeline (top)
cross-referenced ×1

On a fresh local macOS install, openclaw dashboard prints and opens http://127.0.0.1:18789/ even when the local gateway is not reachable yet.

Error Message

$ openclaw dashboard Dashboard URL: http://127.0.0.1:18789/ Copied to clipboard. Opened in your browser. Keep that tab to control OpenClaw.

$ openclaw status Gateway ... unreachable (connect failed: connect ECONNREFUSED 127.0.0.1:18789) Gateway service LaunchAgent not installed

$ openclaw daemon status Last gateway error: Gateway start blocked: set gateway.mode=local (current: unset) or pass --allow-unconfigured.

Root Cause

On a fresh local macOS install, openclaw dashboard prints and opens http://127.0.0.1:18789/ even when the local gateway is not reachable yet.

Fix Action

Fix / Workaround

Observed workaround:

PR fix notes

PR #55004: fix: preflight local dashboard reachability before auto-open

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

  • Problem: openclaw dashboard always copied and opened the local dashboard URL without first checking whether the local gateway was reachable.
  • Why it matters: on fresh installs this produced a dead 127.0.0.1:18789 tab and pushed users toward browser/firewall debugging instead of the real daemon/config fixes.
  • What changed: add a local-mode dashboard preflight probe, treat auth-close responses as reachable, skip clipboard/browser side effects when the gateway is down, and print direct remediation commands for missing config/mode/service state.
  • What did NOT change (scope boundary): remote-mode dashboard flows, tokenized dashboard URL generation, and the existing happy-path browser open behavior when the gateway is reachable.

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 #55003
  • Related #
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

  • Root cause: dashboardCommand built the local URL, copied it, and opened the browser without probing the local gateway or consulting local service/config state first.
  • Missing detection / guardrail: there was no preflight reachability gate before side effects, even though the CLI already had probe helpers and daemon/config diagnostics.
  • Prior context (git blame, prior PR, issue, or refactor if known): the command originated in bb7397c636 (feat: add dashboard command), and later auth/token refactors preserved URL generation but still did not add a reachability check.
  • Why this regressed now: this path is an existing missing guardrail, not a newly identified behavioral regression; the beta install flow made it obvious because gateway.mode unset now blocks startup more explicitly.
  • If unknown, what was ruled out: ruled out browser/firewall as the primary cause on the reproduced install because no process was listening on 127.0.0.1:18789, openclaw status reported ECONNREFUSED, and openclaw daemon status pointed at gateway.mode=local being unset.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should have caught this. Otherwise write N/A.

  • 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/dashboard.links.test.ts
  • Scenario the test should lock in: when the local gateway probe returns a connect failure, openclaw dashboard must print remediation and skip clipboard/browser side effects.
  • Why this is the smallest reliable guardrail: the bug is entirely in the CLI decision branch before any browser or service integration boundary; mocked probe + daemon state is sufficient and deterministic.
  • Existing test that already covers this (if any): the file already covered the reachable happy path, --no-open, and SecretRef token handling; src/cli/daemon-cli/restart-health.test.ts already covered auth-close reachability semantics.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.

  • openclaw dashboard no longer copies or opens a dead local dashboard URL when the local gateway is unreachable.
  • In the local unreachable case, the CLI now prints direct fixes such as openclaw config set gateway.mode local, openclaw daemon install, openclaw daemon start/restart, and openclaw gateway probe.

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • 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:

Repro + Verification

Environment

  • OS: macOS 14.7.5 (arm64)
  • Runtime/container: Node 25.1.0, npm global install via official beta installer
  • Model/provider: openai-codex/gpt-5.4 via openai-codex
  • Integration/channel (if any): none
  • Relevant config (redacted): local dashboard config with gateway.mode initially unset; later local token auth enabled by openclaw daemon install

Steps

  1. Install OpenClaw beta locally and leave the local gateway unbootstrapped (gateway.mode unset and no LaunchAgent installed yet).
  2. Run openclaw dashboard.
  3. Observe the current CLI behavior opens http://127.0.0.1:18789/ even though openclaw status reports the local gateway unreachable.

Expected

  • The command should stop before copy/open side effects and print actionable remediation.

Actual

  • The command printed a dashboard URL, copied it, and opened a dead localhost tab.

Evidence

Attach at least one:

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

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: reproduced the broken local bootstrap path on a fresh beta macOS install; verified openclaw status / openclaw daemon status showed the real root cause; ran npx pnpm vitest run src/commands/dashboard.links.test.ts src/cli/daemon-cli/restart-health.test.ts; ran the repo pre-commit check chain successfully during commit.
  • Edge cases checked: existing happy-path dashboard tests still pass; SecretRef/unresolved token tests still pass; auth-close reachability semantics still pass via src/cli/daemon-cli/restart-health.test.ts.
  • What you did not verify: remote-mode dashboard behavior, end-to-end browser rendering against a freshly built CLI binary, and non-macOS service wording.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

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

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert commit 2abe342da8 or remove the local preflight gate from src/commands/dashboard.ts
  • Files/config to restore: src/commands/dashboard.ts, src/commands/dashboard.links.test.ts, src/commands/status.daemon.ts
  • Known bad symptoms reviewers should watch for: false negatives where openclaw dashboard refuses to auto-open a healthy local gateway

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

  • Risk: a transient local probe failure could suppress browser auto-open even though the gateway would have become reachable moments later.
    • Mitigation: auth-close cases are explicitly treated as reachable, the probe timeout stays short and local-only, and the CLI now prints direct remediation instead of a misleading success message.

Changed files

  • src/commands/dashboard.links.test.ts (modified, +122/-6)
  • src/commands/dashboard.ts (modified, +85/-0)
  • src/commands/status.daemon.ts (modified, +2/-0)

Code Example

Dashboard URL: http://127.0.0.1:18789/
Copied to clipboard.
Opened in your browser. Keep that tab to control OpenClaw.

---

Gateway ... unreachable (connect failed: connect ECONNREFUSED 127.0.0.1:18789)
Gateway service  LaunchAgent not installed

---

Gateway start blocked: set gateway.mode=local (current: unset) or pass --allow-unconfigured.

---

$ openclaw dashboard
Dashboard URL: http://127.0.0.1:18789/
Copied to clipboard.
Opened in your browser. Keep that tab to control OpenClaw.

$ openclaw status
Gateway ... unreachable (connect failed: connect ECONNREFUSED 127.0.0.1:18789)
Gateway service  LaunchAgent not installed

$ openclaw daemon status
Last gateway error: Gateway start blocked: set gateway.mode=local (current: unset) or pass --allow-unconfigured.

---

openclaw daemon install
openclaw config set gateway.mode local
openclaw daemon restart
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug

Summary

On a fresh local macOS install, openclaw dashboard prints and opens http://127.0.0.1:18789/ even when the local gateway is not reachable yet.

Steps to reproduce

  1. Install OpenClaw beta on macOS with curl -fsSL https://openclaw.ai/install.sh | bash -s -- --beta.
  2. Leave the local gateway unbootstrapped (gateway.mode unset and no LaunchAgent installed yet).
  3. Run openclaw dashboard.
  4. Observe that the CLI prints a dashboard URL, copies it, and reports Opened in your browser, but openclaw status shows the gateway is unreachable on 127.0.0.1:18789.

Expected behavior

openclaw dashboard should only auto-open a local dashboard URL when the local gateway is reachable, or it should stop with an actionable remediation instead of implying success.

Actual behavior

The command printed:

Dashboard URL: http://127.0.0.1:18789/
Copied to clipboard.
Opened in your browser. Keep that tab to control OpenClaw.

but openclaw status reported:

Gateway ... unreachable (connect failed: connect ECONNREFUSED 127.0.0.1:18789)
Gateway service  LaunchAgent not installed

and after installing the LaunchAgent, openclaw daemon status still reported:

Gateway start blocked: set gateway.mode=local (current: unset) or pass --allow-unconfigured.

OpenClaw version

2026.3.24-beta.2 (e9ac286)

Operating system

macOS 14.7.5 (arm64)

Install method

npm global via the official beta installer script

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> openai-codex

Additional provider/model setup details

The dashboard failure reproduces before any model request is sent. The provider/model configuration does not appear to affect the broken dashboard bootstrap path.

Logs, screenshots, and evidence

$ openclaw dashboard
Dashboard URL: http://127.0.0.1:18789/
Copied to clipboard.
Opened in your browser. Keep that tab to control OpenClaw.

$ openclaw status
Gateway ... unreachable (connect failed: connect ECONNREFUSED 127.0.0.1:18789)
Gateway service  LaunchAgent not installed

$ openclaw daemon status
Last gateway error: Gateway start blocked: set gateway.mode=local (current: unset) or pass --allow-unconfigured.

Impact and severity

Affected: fresh local installs using the local dashboard bootstrap path Severity: Medium to high (blocks dashboard onboarding and misdirects debugging toward browser/firewall issues) Frequency: 1/1 observed on this install Consequence: users get a dead localhost tab and have to manually discover the daemon/config fixes

Additional information

Observed workaround:

openclaw daemon install
openclaw config set gateway.mode local
openclaw daemon restart

I did not confirm a last-known-good version for this exact path, so regression history is NOT_ENOUGH_INFO.

extent analysis

Fix Plan

To fix the issue, we need to modify the openclaw dashboard command to check if the local gateway is reachable before printing and opening the dashboard URL.

Here are the steps:

  • Check the gateway status before attempting to open the dashboard URL
  • If the gateway is not reachable, print an error message and provide instructions on how to configure the gateway
  • If the gateway is reachable, proceed with printing and opening the dashboard URL

Example code changes:

import subprocess

# Check gateway status
def check_gateway_status():
    try:
        # Run the command to check gateway status
        subprocess.check_output(['openclaw', 'status'])
        return True
    except subprocess.CalledProcessError:
        return False

# Open dashboard URL if gateway is reachable
def open_dashboard():
    if check_gateway_status():
        # Print and open dashboard URL
        print("Dashboard URL: http://127.0.0.1:18789/")
        # Code to copy to clipboard and open in browser
    else:
        # Print error message and instructions
        print("Error: Gateway is not reachable. Please configure the gateway by running:")
        print("openclaw daemon install")
        print("openclaw config set gateway.mode local")
        print("openclaw daemon restart")

# Call the open_dashboard function
open_dashboard()

Verification

To verify that the fix worked, follow these steps:

  • Run openclaw dashboard on a fresh local install with the gateway unbootstrapped
  • Check that the command prints an error message and provides instructions on how to configure the gateway
  • Configure the gateway by running the provided commands
  • Run openclaw dashboard again and check that the command prints and opens the dashboard URL successfully

Extra Tips

  • Make sure to test the fix on different environments and versions to ensure it works as expected
  • Consider adding additional error handling and logging to improve the user experience
  • Document the fix and the workaround in the OpenClaw documentation to help users who may encounter the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

openclaw dashboard should only auto-open a local dashboard URL when the local gateway is reachable, or it should stop with an actionable remediation instead of implying success.

#retriever error#indexing error#inference speed#output truncation#response parsing

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING