PR #73583: Fix Telegram status and group reply delivery

• Repository: openclaw/openclaw
• Author: VACInc
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/73583

Description (problem / solution / changelog)

Summary

• Send Telegram native /status through the direct status helper instead of the normal buffered answer dispatcher.
• Preserve Telegram topic threading/reply-to behavior for direct status responses while keeping /fast status on the generic native command route.
• Pass Telegram group sourceReplyDeliveryMode into normal message turns, so model guidance matches message-tool-only delivery.
• Add a core suppressed-source fallback hook for group/channel turns that produce ordinary assistant output instead of using the channel message tool.
• Wire that fallback into Telegram group/topic delivery so final replies, block replies, and verbose progress do not disappear silently when automatic source delivery is suppressed.
• Normalize suppressed-source fallback payloads through the normal reply dispatcher semantics before channel delivery, so exact silent tokens and channel transforms do not leak through the Telegram fallback.
• Route queued follow-up run failures back to the original channel/topic as a generic error reply, so model/auth failures do not leave Telegram topics silent.

Root cause

Telegram native /status was authorized for the requested group/user, but after resolving the command it still delivered through the generic Telegram reply dispatcher. During an active chat turn that delivery path can be occupied by normal answer streaming/final delivery, so /status could appear to do nothing until the turn cleared.

Normal Telegram group/topic messages had a related delivery-mode mismatch after the message-tool-only privacy change: the dispatcher suppresses automatic group/channel finals by default unless messages.groupChat.visibleReplies is automatic, but Telegram was not passing the effective mode into the reply runtime or providing a channel fallback for suppressed ordinary assistant output. That let the model produce a plain final reply while the channel treated it as private-only and did not send it back to Telegram.

Live topic testing exposed two more gaps: some turns emitted visible assistant text as block-streamed output instead of a final return value, and verbose progress messages also returned early under the same suppressed delivery mode. The fallback now covers final answers, block replies, and verbose progress without changing the preferred message-tool behavior or bypassing sendPolicy: deny.

A later live check showed two Telegram topic messages did reach OpenClaw but both failed in the queued/follow-up runner with openai-codex/gpt-5.5 auth 401 errors and no model fallback configured. That queued runner path logged the model failure and returned without routing a failure payload, so Telegram still looked dead even though the transport and inbound handling were working.

Upstream reconciliation

• Current main already fixed native-command generic visibility via #73672 / 195f704c74a2, so this branch no longer carries the native skill-command fallback portion from the original patch.
• Current main still did not contain the Telegram direct /status fast path, the core suppressed-source fallback contract, the Telegram group/topic fallback, or the queued follow-up failure reply, so this PR is still needed rather than closeable as upstreamed.
• The review concern about senderIsOwner is addressed by threading Telegram command auth's computed senderIsOwner into resolveDirectStatusReplyForSession.

Validation

• pnpm test extensions/telegram/src/bot.create-telegram-bot.test.ts -- -t "threads native command replies inside topics|reloads native command routing bindings"
• pnpm test extensions/telegram/src/bot-message-dispatch.test.ts -- -t "source reply delivery mode|suppressed group final"
• pnpm test src/auto-reply/reply/dispatch-from-config.test.ts -- -t "suppressed source fallback|source delivery|verbose progress"
• pnpm test src/auto-reply/reply/dispatch-from-config.test.ts -- -t "suppressed source fallback|normalizes suppressed final replies|uses dispatcher normalization"
• pnpm test src/auto-reply/reply/followup-runner.test.ts -- -t "routes a generic error reply"
• pnpm test src/auto-reply/reply/followup-runner.test.ts
• pnpm exec oxfmt --check --threads=1 extensions/telegram/src/bot-message-dispatch.test.ts extensions/telegram/src/bot-message-dispatch.ts extensions/telegram/src/bot-native-commands.ts extensions/telegram/src/bot.create-telegram-bot.test-harness.ts extensions/telegram/src/bot.create-telegram-bot.test.ts src/auto-reply/get-reply-options.types.ts src/auto-reply/reply/dispatch-from-config.test.ts src/auto-reply/reply/dispatch-from-config.ts
• pnpm exec oxfmt --check --threads=1 src/auto-reply/reply/followup-runner.ts src/auto-reply/reply/followup-runner.test.ts
• git diff --check

Not run

• pnpm check:changed in Blacksmith Testbox: local Blacksmith CLI is not authenticated in this shell (blacksmith testbox warmup ci-check-testbox.yml --ref main --idle-timeout 90 reports not authenticated). GitHub CI should run against the pushed SHA.

Changed files

• extensions/telegram/src/bot-core.ts (modified, +133/-3)
• extensions/telegram/src/bot-message-dispatch.test.ts (modified, +98/-0)
• extensions/telegram/src/bot-message-dispatch.ts (modified, +48/-1)
• extensions/telegram/src/bot-native-commands.ts (modified, +62/-0)
• extensions/telegram/src/bot.create-telegram-bot.test-harness.ts (modified, +27/-0)
• extensions/telegram/src/bot.create-telegram-bot.test.ts (modified, +122/-13)
• extensions/telegram/src/bot/delivery.send.ts (modified, +18/-2)
• extensions/telegram/src/reply-run-runtime.ts (added, +1/-0)
• extensions/telegram/src/sequential-key.runtime.ts (added, +113/-0)
• extensions/telegram/src/sequential-key.test.ts (modified, +32/-0)
• extensions/telegram/src/sequential-key.ts (modified, +20/-1)
• src/agents/context-runtime-state.ts (modified, +3/-0)
• src/agents/context.ts (modified, +10/-6)
• src/agents/model-selection-cli.ts (modified, +16/-3)
• src/auto-reply/get-reply-options.types.ts (modified, +12/-0)
• src/auto-reply/reply/dispatch-from-config.test.ts (modified, +196/-0)
• src/auto-reply/reply/dispatch-from-config.ts (modified, +43/-10)
• src/auto-reply/reply/followup-runner.test.ts (modified, +34/-0)
• src/auto-reply/reply/followup-runner.ts (modified, +19/-0)
• src/auto-reply/reply/reply-dispatcher.ts (modified, +26/-15)
• src/auto-reply/reply/reply-dispatcher.types.ts (modified, +4/-0)
• src/auto-reply/reply/reply-run-registry.test.ts (modified, +16/-0)
• src/auto-reply/reply/reply-run-registry.ts (modified, +4/-0)
• src/gateway/protocol/schema/sessions.ts (modified, +6/-0)
• src/gateway/server-methods/sessions.ts (modified, +29/-0)
• src/gateway/server.sessions.list-changed.test.ts (modified, +1/-1)
• src/gateway/session-utils.fs.ts (modified, +58/-1)
• src/gateway/session-utils.ts (modified, +163/-22)
• src/plugin-sdk/reply-runtime.ts (modified, +1/-0)
• src/utils/usage-format.ts (modified, +33/-2)

PR #75099: fix(auto-reply): surface private group replies

• Repository: openclaw/openclaw
• Author: steipete
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/75099

Description (problem / solution / changelog)

Summary

• Problem: after 2026.4.27, group/channel source turns defaulted to private message_tool_only replies without a runtime warning or an agent-accessible config repair path.
• Why it matters: affected Discord, Slack, Telegram, Feishu, and other group/channel rooms looked like successful runs in the dashboard while the room never received a final reply.
• What changed: warn once when the implicit private default is first used, allow messages.visibleReplies / messages.groupChat.visibleReplies through config.patch, and fall back to automatic delivery when the message tool is unavailable.
• What did NOT change: the intentional group/channel safety default remains private-by-default when the message tool is available.

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 #74876
• Related #74842
• Related #74868
• Related #73046
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: #73046 intentionally changed group/channel source replies to message_tool_only, but the shared resolver applied it to every group/channel surface without an upgrade warning, without an easy config.patch repair path, and without checking whether the message tool could actually send visibly.
• Missing detection / guardrail: no runtime warning for implicit private defaults, no config mutation allowlist entry for visible-reply keys, and no regression test for missing message tool fallback.
• Contributing context: the changelog entry framed the change as Discord/group chats even though the resolver uses normalized group / channel chat type and therefore affects all channels.

Regression Test Plan (if applicable)

• 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/auto-reply/reply/source-reply-delivery-mode.test.ts, src/auto-reply/reply/dispatch-from-config.test.ts, src/agents/tools/gateway-tool-guard-coverage.test.ts
• Scenario the test should lock in: implicit group/channel default warns and stays tool-only, unavailable message tool falls back to automatic delivery, and visible-reply config keys can be patched.
• Why this is the smallest reliable guardrail: the bug lives in the shared resolver, dispatch policy handoff, and agent-facing config mutation guard.
• Existing test that already covers this (if any): existing dispatch tests covered the private default, but not the warning, config repair path, or unavailable-tool fallback.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Group/channel rooms still default to private final replies when message tool output is available.
• Operators now get a one-shot warning the first time an implicit private group/channel default is applied.
• messages.groupChat.visibleReplies = "automatic" can be applied via config.patch instead of manual JSON editing.
• If message_tool_only is selected but the message tool is unavailable, OpenClaw now delivers the final reply automatically instead of silently dropping visible output.
• Docs and changelog now say this applies to all group/channel chats and clarify hot reload.

Diagram (if applicable)

Before:
group/channel turn -> implicit message_tool_only -> final reply private -> room appears silent
message tool unavailable -> no visible path

After:
group/channel turn -> implicit message_tool_only -> warning + message tool visible path
message tool unavailable -> automatic delivery fallback
operator repair -> config.patch messages.groupChat.visibleReplies = "automatic"

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? Yes
• Data access scope changed? No
• If any Yes, explain risk + mitigation: the agent-facing gateway config mutation allowlist now permits two bounded enum config keys that affect reply visibility only. It does not allow secrets, auth, tool policy, sandbox, or network settings.

Repro + Verification

Environment

• OS: macOS local, Blacksmith Testbox Linux CI parity
• Runtime/container: Node 22 / pnpm
• Model/provider: N/A
• Integration/channel (if any): shared group/channel delivery policy; reported on Discord and all group/channel rooms
• Relevant config (redacted): absent messages.groupChat.visibleReplies on group/channel turns

Steps

1. Process a group/channel turn with no explicit visible-reply config.
2. Observe source reply delivery mode and final reply dispatch behavior.
3. Set tools.allow without message and process the same group/channel turn.
4. Patch messages.groupChat.visibleReplies via the gateway config mutation guard.

Expected

• Implicit default remains private-by-default but warns once.
• Missing message tool does not silence visible output.
• Visible-reply keys are patchable.

Actual

• Before this PR, implicit default was silent, missing message tool could leave no visible delivery path, and the config keys were protected from config.patch.

Evidence

• 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: resolver warning/default/fallback behavior, dispatch fallback to final reply delivery, gateway config mutation allowlist, docs/config metadata checks.
• Edge cases checked: native commands still automatic; explicit automatic config still automatic; explicit tool-only remains tool-only when message is available.
• What you did not verify: live Discord/Slack/Telegram/Feishu room roundtrip.

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.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? Yes
• Migration needed? No
• If yes, exact upgrade steps: optional operator repair remains messages.groupChat.visibleReplies = "automatic" to restore legacy room auto-posting. The gateway hot-reloads messages config unless file watching/reload is disabled.

Risks and Mitigations

• Risk: Falling back to automatic delivery when message is unavailable could make some tool-only rooms visible again.
  • Mitigation: the fallback only applies when there is no tool path to produce visible output; when message is available, the private-by-default safety posture is unchanged.
• Risk: config.patch could be used to change group/channel visibility.
  • Mitigation: this is the intended repair affordance and is limited to two non-secret enum keys.

Changed files

• CHANGELOG.md (modified, +1/-1)
• docs/.generated/config-baseline.sha256 (modified, +2/-2)
• docs/channels/groups.md (modified, +3/-0)
• docs/gateway/config-channels.md (modified, +2/-0)
• src/agents/tools/gateway-tool-guard-coverage.test.ts (modified, +28/-0)
• src/agents/tools/gateway-tool.ts (modified, +4/-0)
• src/auto-reply/reply/dispatch-from-config.test.ts (modified, +25/-0)
• src/auto-reply/reply/dispatch-from-config.ts (modified, +33/-0)
• src/auto-reply/reply/source-reply-delivery-mode.test.ts (modified, +84/-1)
• src/auto-reply/reply/source-reply-delivery-mode.ts (modified, +36/-2)
• src/plugin-sdk/channel-reply-pipeline.ts (modified, +1/-0)

PR #75382: fix(auto-reply): keep group visible replies deliverable

• Repository: openclaw/openclaw
• Author: steipete
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/75382

Description (problem / solution / changelog)

Summary

• keep the message tool available when group/channel visible replies require message-tool delivery
• include group/subagent tool policy in visible-reply fallback detection so restricted rooms fall back to automatic delivery instead of going silent
• extend qa-channel and qa-lab with Discord/Slack-style group:<room> coverage for message-tool replies and fallback replies

Verification

• pnpm test extensions/qa-channel/src/bus-client.test.ts extensions/qa-channel/src/channel.test.ts extensions/qa-lab/src/scenario-catalog.test.ts extensions/qa-lab/src/providers/mock-openai/server.test.ts src/auto-reply/reply/dispatch-from-config.test.ts src/auto-reply/reply/followup-runner.test.ts
• pnpm config:channels:check
• git diff --check
• OPENCLAW_QA_SUITE_PROGRESS=1 fnm exec --using v22.21.1 node --input-type=module ... for group-visible-reply-tool and group-message-tool-unavailable-fallback

QA artifact: .artifacts/qa-e2e/group-visible-replies-pr/qa-suite-report.md

Fixes #74842. Refs #75207.

Changed files

• CHANGELOG.md (modified, +1/-0)
• docs/channels/qa-channel.md (modified, +2/-0)
• extensions/qa-channel/src/bus-client.test.ts (modified, +14/-1)
• extensions/qa-channel/src/bus-client.ts (modified, +9/-3)
• extensions/qa-channel/src/channel-actions.ts (modified, +1/-1)
• extensions/qa-channel/src/channel.test.ts (modified, +121/-0)
• extensions/qa-channel/src/channel.ts (modified, +20/-3)
• extensions/qa-channel/src/config-schema.ts (modified, +15/-1)
• extensions/qa-channel/src/inbound.ts (modified, +10/-9)
• extensions/qa-channel/src/types.ts (modified, +10/-0)
• extensions/qa-lab/src/bus-queries.ts (modified, +5/-0)
• extensions/qa-lab/src/providers/mock-openai/server.ts (modified, +18/-0)
• extensions/qa-lab/src/runtime-api.ts (modified, +1/-0)
• extensions/qa-lab/src/suite.ts (modified, +12/-0)
• qa/scenarios/channels/group-message-tool-unavailable-fallback.md (added, +98/-0)
• qa/scenarios/channels/group-visible-reply-tool.md (added, +96/-0)
• src/agents/pi-tools.policy.ts (modified, +5/-7)
• src/auto-reply/reply/agent-runner-execution.ts (modified, +2/-0)
• src/auto-reply/reply/dispatch-from-config.test.ts (modified, +36/-0)
• src/auto-reply/reply/dispatch-from-config.ts (modified, +61/-5)
• src/auto-reply/reply/followup-runner.test.ts (modified, +1/-0)
• src/auto-reply/reply/followup-runner.ts (modified, +1/-0)
• src/config/bundled-channel-config-metadata.generated.ts (modified, +172/-0)
• src/plugin-sdk/qa-channel-protocol.ts (modified, +1/-1)