openclaw - ✅(Solved) Fix doctor --fix sets messages.groupChat.visibleReplies=message_tool, then warns the message tool is unavailable [3 pull requests, 1 comments, 2 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#78066Fetched 2026-05-06 06:17:14
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
2
Author
Timeline (top)
cross-referenced ×3commented ×1

Fix Action

Workaround

Re-patch after every --fix:

openclaw config set messages.groupChat.visibleReplies automatic

PR fix notes

PR #78078: fix(doctor): recommend automatic visibleReplies when message tool is unavailable (#78066)

Description (problem / solution / changelog)

Root cause

normalizeMissingGroupVisibleRepliesDefault unconditionally set messages.groupChat.visibleReplies to "message_tool" when applying doctor --fix, without checking whether the message tool is actually reachable under the operator's active tool policy.

After the fix:

$ openclaw doctor --fix --yes
[...] Set messages.groupChat.visibleReplies to "message_tool" ...
$ openclaw doctor
[WARNING] messages.groupChat.visibleReplies is "message_tool" but message tool unavailable

A doctor --fix run that produces a config that the next doctor run immediately warns about is a self-contradicting loop.

Fix

Export resolveMessageToolAvailability from preview-warnings.ts (the same helper already used by the warning path) and call it in the normalizer. When the message tool is unavailable for the global tool policy, recommend "automatic" instead of "message_tool".

Files changed

  • src/commands/doctor/shared/preview-warnings.ts — export resolveMessageToolAvailability
  • src/commands/doctor/shared/legacy-config-core-normalizers.ts — gate recommendation on tool availability
  • src/commands/doctor/shared/legacy-config-core-normalizers.visibleReplies.test.ts — 4 regression tests

Tests

✓ recommends message_tool when message tool is available (full profile)
✓ recommends automatic when message tool is unavailable (minimal profile)
✓ does not apply fix when visibleReplies is already set
✓ does not apply fix when no channels are configured

Test Files  1 passed (1)
    Tests  4 passed (4)

Closes #78066

Changed files

  • extensions/codex/src/app-server/run-attempt.ts (modified, +16/-3)
  • extensions/ollama/provider-discovery.test.ts (modified, +22/-0)
  • extensions/ollama/src/discovery-shared.ts (modified, +7/-1)
  • src/agents/skills/plugin-skills.ts (modified, +1/-1)
  • src/commands/doctor/shared/legacy-config-core-normalizers.ts (modified, +7/-2)
  • src/commands/doctor/shared/legacy-config-core-normalizers.visibleReplies.test.ts (added, +49/-0)
  • src/commands/doctor/shared/preview-warnings.ts (modified, +1/-1)
  • src/daemon/schtasks.startup-fallback.test.ts (modified, +13/-0)
  • src/daemon/schtasks.ts (modified, +4/-0)

PR #78106: fix(doctor): recommend automatic visibleReplies when message tool is unavailable (#78066)

Description (problem / solution / changelog)

Root cause

normalizeMissingGroupVisibleRepliesDefault unconditionally set messages.groupChat.visibleReplies to "message_tool" when applying doctor --fix, without checking whether the message tool is actually reachable under the active tool policy.

After running --fix, the next doctor invocation immediately emits:

messages.groupChat.visibleReplies is set to "message_tool", but the message tool is unavailable — OpenClaw falls back to automatic visible replies.

This is a self-contradicting fix loop on every setup where the message tool is not enabled (e.g. tools.profile: minimal or full with no message tool).

Fix

Export resolveMessageToolAvailability from preview-warnings.ts — the same helper the warning path already uses — and call it inside the normalizer. When the message tool is unavailable for the global tool policy, recommend "automatic" instead of "message_tool".

Files changed (3 files, clean branch off upstream main)

  • src/commands/doctor/shared/preview-warnings.tsfunctionexport function for resolveMessageToolAvailability
  • src/commands/doctor/shared/legacy-config-core-normalizers.ts — gate on tool availability; vary change-log message
  • src/commands/doctor/shared/legacy-config-core-normalizers.visibleReplies.test.ts — 4 regression tests (new file)

Tests

✓ recommends message_tool when message tool is available (full profile)
✓ recommends automatic when message tool is unavailable (minimal profile)
✓ does not apply fix when visibleReplies is already set
✓ does not apply fix when no channels are configured

Test Files  1 passed (1) · Tests  4 passed (4)

Closes #78066

Changed files

  • src/commands/doctor/shared/legacy-config-core-normalizers.ts (modified, +7/-2)
  • src/commands/doctor/shared/legacy-config-core-normalizers.visibleReplies.test.ts (added, +49/-0)
  • src/commands/doctor/shared/preview-warnings.ts (modified, +1/-1)

PR #78244: fix(doctor): skip message_tool default when message tool is unavailable

Description (problem / solution / changelog)

Summary

doctor --fix was unconditionally setting messages.groupChat.visibleReplies to "message_tool" on installs without configured channels, even when the active tool policy has no message tool available. The next doctor run would then emit a warning that the set value is unavailable and falls back to automatic.

Root cause

normalizeMissingGroupVisibleRepliesDefault in src/commands/doctor/shared/legacy-config-core-normalizers.ts had no check for message tool availability before assigning "message_tool". The preview-warnings path already knew how to detect that "message_tool" is unavailable — the normalizer simply wasn't using the same check.

Fix

normalizeMissingGroupVisibleRepliesDefault now checks whether the message tool is permitted by the resolved tool policy before setting "message_tool". When the message tool is unavailable, the function returns early without modifying the config, leaving the effective default at "automatic" instead.

The check is implemented using the same tool-policy resolution helpers (isToolAllowedByPolicies, resolveToolProfilePolicy, mergeAlsoAllowPolicy, pickSandboxToolPolicy) that preview-warnings.ts uses, so both paths agree on what "message tool available" means.

Reproduction (before fix)

openclaw doctor --fix --yes   # sets visibleReplies = "message_tool"
openclaw doctor                # warns: message tool is unavailable

After fix

openclaw doctor --fix --yes   # no-op for visibleReplies when message tool unavailable
openclaw doctor                # no warning

Verification

  • Existing unit tests in preview-warnings.test.ts cover the warning path independently and remain unaffected.
  • The logic change is guarded: the normalizer still applies "message_tool" on installs where the tool is actually available.

Closes #78066

Changed files

  • src/commands/doctor/shared/legacy-config-core-normalizers.ts (modified, +39/-0)

Code Example

openclaw doctor --fix --yes
openclaw doctor

---

if active_tool_policy_has_message_tool:
    recommend(visibleReplies = "message_tool")
else:
    ensure(visibleReplies in ["automatic", undefined])

---

openclaw config set messages.groupChat.visibleReplies automatic
RAW_BUFFERClick to expand / collapse

Reproduction

On a fresh OpenClaw 2026.5.4 install where the active tool policy does not enable the message tool (e.g. tools.profile = full with no explicit message tool wired), run:

openclaw doctor --fix --yes
openclaw doctor

The first run applies a recommended config change; the second run warns about that same change.

Observed

After --fix, the next doctor pass emits:

messages.groupChat.visibleReplies is set to "message_tool", but the message tool is unavailable for default tool policy; OpenClaw falls back to automatic visible replies, so normal replies may post to the source chat. Enable the message tool or set messages.groupChat.visibleReplies to "automatic".

The value it warns about was set by the previous --fix run. Every subsequent doctor invocation continues to emit the warning until the operator manually patches messages.groupChat.visibleReplies back to automatic.

Expected

doctor --fix should not apply a recommendation that the next doctor run will immediately flag as a warning. One of two things should happen instead:

  1. Skip the visibleReplies = message_tool recommendation when the message tool is not present in the active tool policy.
  2. Recommend automatic in that case (with a note that message_tool becomes the recommended setting if/when the message tool is enabled).

Suggested fix

Gate the visibleReplies = message_tool recommendation on whether the message tool is actually present in the resolved tool policy at fix time:

if active_tool_policy_has_message_tool:
    recommend(visibleReplies = "message_tool")
else:
    ensure(visibleReplies in ["automatic", undefined])

This affects installs that use a default tool profile without explicitly enabling the message tool, which is common for single-channel deployments.

Workaround

Re-patch after every --fix:

openclaw config set messages.groupChat.visibleReplies automatic

Environment

  • OpenClaw 2026.5.4
  • Ubuntu 26.04, kernel 7.0.0-15
  • Single Telegram channel
  • tools.profile = full, tools.exec.security = full
  • Local Ollama provider (gpt-oss:120b)

Related

#73471 frames a more general concern about doctor --fix applying recommendations automatically. This is another concrete instance of that shape.

extent analysis

TL;DR

The openclaw doctor --fix command should be modified to gate the visibleReplies = message_tool recommendation based on the presence of the message tool in the active tool policy.

Guidance

  • Verify that the message tool is enabled in the active tool policy before applying the visibleReplies = message_tool recommendation.
  • Consider implementing a conditional check, as suggested in the issue, to ensure that the recommendation is only applied when the message tool is present.
  • As a temporary workaround, re-patch the configuration after every --fix run using openclaw config set messages.groupChat.visibleReplies automatic.
  • Review related issue #73471 for a more general discussion on the concerns surrounding doctor --fix applying recommendations automatically.

Example

if active_tool_policy_has_message_tool:
    recommend(visibleReplies = "message_tool")
else:
    ensure(visibleReplies in ["automatic", undefined])

Notes

This fix is specific to OpenClaw 2026.5.4 and may not apply to other versions. The workaround provided is a temporary solution until the underlying issue is addressed.

Recommendation

Apply workaround: re-patch the configuration after every --fix run using openclaw config set messages.groupChat.visibleReplies automatic, as this provides a reliable way to avoid the warning until the root cause is fixed.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING