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:
- If the current context can run the suggested command, present it normally.
- If the current context probably cannot complete it, say so explicitly.
- 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.
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:
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:
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:
But when trying to follow that suggestion from the current flow/context:
So the experience became: good advice, wrong place.
Expected behavior
One of these:
For example:
openclaw doctor --non-interactivein terminal/web UI with approvals available."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
doctorexists 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
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:
This was not a doctor correctness problem; it was an actionability / execution-context problem.