Summary

• Problem: message-tool-only Discord replies could refresh typing from two lifecycle owners, making Discord show stale multi-second "bot is typing" after the visible reply was already delivered.
• Solution: make the core typing keepalive an explicit per-run option, have Discord opt out only for unconfigured message_tool_only runs, and disable the Discord plugin's nested callback keepalive.
• What changed: added typingKeepalive?: boolean to reply options, kept shared reply typing periodic by default, pass typingKeepalive: false from Discord only when sourceReplyDeliveryMode === "message_tool_only" and no explicit typingMode is configured, and set the Discord channel callback keepalive interval to 0.
• What did NOT change (scope boundary): explicit agents.defaults.typingMode / session.typingMode continues to win, non-Discord channels keep the existing shared keepalive default unless they opt out, typing is not disabled by default, ack reactions are unchanged, and this does not add a Discord "stop typing" call because Discord does not expose one.

Motivation

• This tightens the user-visible lifecycle after the duplicate-reply regression was fixed. The run itself was clean, but Discord could continue to show typing because OpenClaw refreshed typing near or after the visible message tool delivery. That made it look as if a second response was still being generated even when the transcript showed no fallback or second assistant run.

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

• Related EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released #84059
• Related fix(agents): tolerate in-process session writes during prompt release #84250
• Related Fix Discord reply typing lifecycle #76091
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: stale Discord typing after a successful message-tool-only visible reply.
• Real environment tested: macOS local OpenClaw v2026.5.18 gateway, Node v25.6.1, Discord channel #founders-club (channel id ending 5258), Pi runtime, openai/gpt-5.5, messages.groupChat.visibleReplies: "message_tool".
• Exact steps or command run after this patch:
  1. Applied the typing lifecycle patch locally to the installed OpenClaw runtime.
  2. Restarted the gateway.
  3. Sent Discord test messages in #founders-club.
  4. Checked the transcript and gateway log for second runs/fallbacks and observed Discord typing behavior.
• Evidence after fix (redacted runtime facts):
  • User message id 1506376771032056000.
  • One gpt-5.5 tool call at 2026-05-19T19:23:44.803Z.
  • One delivery mirror at 2026-05-19T19:23:45.823Z.
  • One successful message tool result at 2026-05-19T19:23:45.982Z with primary Discord message id 1506376839398952981.
  • Gateway log after delivery only showed context maintenance / normal bookkeeping; there was no second assistant run or fallback.
• Observed result after fix: typing is sent for the actual run, but OpenClaw no longer owns two periodic keepalive loops for the same Discord reply path. Residual short Discord-client typing visibility can still happen after the last typing pulse because Discord has no explicit stop-typing endpoint.
• What was not tested: full pnpm build && pnpm check && pnpm test; I ran focused validation for the touched auto-reply and Discord extension surfaces.
• Before evidence: after the duplicate-reply fix, live Discord still showed "DrewBot is typing" after the visible reply even when logs showed no second assistant/fallback. That pointed at typing lifecycle refresh, not duplicate generation.

Root Cause (if applicable)

• Root cause: default message-tool-only group replies start typing immediately, and Discord typing was being refreshed by both core reply typing and a Discord channel callback keepalive. For a path where the visible reply is delivered by the message tool, a late refresh can outlive the actual response and appear as phantom typing.
• Missing detection / guardrail: tests covered typing start/cleanup behavior generally, but not "send the first typing signal without a periodic keepalive" or "Discord channel callbacks should not start a nested typing keepalive."
• Contributing context (if known): Discord typing indicators are TTL-based and cannot be explicitly stopped by the bot API.

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/reply-utils.test.ts
  • extensions/discord/src/monitor/message-handler.process.test.ts
• Scenario the test should lock in: a typing controller can emit the first typing signal without periodic keepalive ticks; Discord processing does not start a nested callback keepalive; configured Discord typingMode preserves the core keepalive path.
• Why this is the smallest reliable guardrail: it verifies the exact lifecycle knobs that caused stale typing without relying on Discord client TTL timing.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• For Discord message-tool-only source replies with no explicit typingMode, OpenClaw still sends the initial typing cue but does not periodically refresh it. Explicitly configured typing behavior and non-Discord shared defaults are preserved.

Diagram (if applicable)

Before:
Discord source reply run -> core typing keepalive
                         -> Discord callback keepalive
                         -> visible message delivered -> typing may still be refreshed

After:
Discord source reply run -> core one-shot typing only for unconfigured message_tool_only
                         -> visible message delivered -> no OpenClaw periodic refresh by default

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: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local OpenClaw gateway, Node v25.6.1
• Model/provider: openai/gpt-5.5, Pi runtime
• Integration/channel (if any): Discord group/channel, message-tool-only visible replies
• Relevant config (redacted): messages.groupChat.visibleReplies: "message_tool", no explicit typingMode

Steps

1. Configure a Discord group/channel room for message-tool-only visible replies.
2. Trigger the agent in a group channel.
3. Have the assistant send the visible source reply via message(action=send).
4. Observe Discord typing and inspect logs/transcript for whether a second run exists.

Expected

• Typing starts for the real run.
• Visible reply sends once.
• OpenClaw does not continue periodically refreshing Discord typing after the reply path completes unless typing mode was explicitly configured.

Actual

• Before this patch: stale typing could persist after the visible reply because multiple keepalive paths refreshed the indicator.
• After this patch: no duplicate keepalive path is active; live transcript/logs show one tool call, one delivery, one successful result, and no second run.

Evidence

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

Focused validation run on this branch:

git diff --check origin/main...HEAD
node scripts/run-vitest.mjs run --config test/vitest/vitest.auto-reply-reply.config.ts src/auto-reply/reply/reply-utils.test.ts src/auto-reply/reply/typing-persistence.test.ts
  Test Files  2 passed (2)
  Tests       73 passed (73)

node scripts/run-vitest.mjs run --config test/vitest/vitest.extension-discord.config.ts extensions/discord/src/monitor/message-handler.process.test.ts
  Test Files  1 passed (1)
  Tests       71 passed (71)

Human Verification (required)

• Verified scenarios: live Discord message-tool-only reply after local runtime patch; transcript/logs showed one assistant tool call, one delivery mirror, one successful tool result, and no second assistant/fallback.
• Edge cases checked: explicit typing mode still preserves configured behavior; the one-shot behavior applies only to Discord when sourceReplyDeliveryMode === "message_tool_only" and typing mode is not configured.
• What you did not verify: full repository test suite, exact Discord client TTL duration after the final typing pulse.

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/No): Yes
• Config/env changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: Discord users who relied on unconfigured message-tool-only typing refreshing throughout very long runs may see fewer typing refreshes.
  • Mitigation: explicit agents.defaults.typingMode or session.typingMode continues to opt into configured behavior; non-Discord channels keep their existing shared keepalive default unless they explicitly opt out.