Skip to content

Post-restart suggestion to run openclaw doctor --non-interactive is not always actionable in heartbeat / approval-constrained contexts #69755

@1yihui

Description

@1yihui

Bug type

UX / operational follow-up flow

Beta release blocker

No

Summary

After a config patch / restart, OpenClaw can suggest a follow-up command like:

openclaw doctor --non-interactive

That suggestion is sensible in principle, but in some contexts (especially heartbeat-like or approval-constrained surfaces), the suggested command is not actually actionable from where the message is delivered.

The result is a broken follow-up loop:

  • the system gives a reasonable next step
  • but the current interaction surface cannot actually complete it
  • or execution hits approval constraints with no clean completion path

Real scenario

I hit this after a config patch / restart on a local macOS OpenClaw setup.

OpenClaw reported the restart/config patch success and suggested running:

openclaw doctor --non-interactive

But when trying to follow that suggestion from the current flow/context:

  • the command hit approval constraints
  • the surface was not a good place to complete that approval loop
  • the result was effectively a non-actionable recommendation

So the experience became: good advice, wrong place.

Expected behavior

One of these:

  1. If the current context can run the suggested command, present it normally.
  2. If the current context probably cannot complete it, say so explicitly.
  3. Route the user to the right place for follow-up (e.g. terminal or approvals-capable web UI).

For example:

  • "Recommended follow-up: run openclaw doctor --non-interactive in terminal/web UI with approvals available."
  • or: "Doctor check deferred because this surface cannot complete approvals."

Actual behavior

The restart/config-patch notice suggests a command that may not actually be executable from the current context, especially when approvals are involved.

This makes the post-restart flow feel less closed-loop than it should.

Why this matters

The issue is not that doctor exists or that approvals exist.
The issue is that the recommendation is presented as if it were an immediate next step, even when the current surface/session cannot actually complete that step.

Suggested fix direction

  • Make restart sentinel follow-up messages more context-aware.
  • Distinguish between recommended and actionable here.
  • Provide explicit fallback guidance for constrained contexts.
  • Optionally prefer a lighter read-only health check in contexts where approval-capable execution is unavailable.

OpenClaw version

2026.4.15

Operating system

macOS 15 / Darwin 25.x

Install method

npm global

Model

N/A

Provider / routing chain

N/A

Logs, screenshots, and evidence

Representative failure pattern after following the recommendation:

Exec denied (... approval-timeout (allowlist-miss)): openclaw doctor --non-interactive

This was not a doctor correctness problem; it was an actionability / execution-context problem.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions