Summary

• Problem: in message_tool_only source-reply mode the Discord typing bubble keeps showing for ~10s after the reply has already landed in the channel.
• Solution: add an explicit "source reply delivered" signal so the typing keepalive is sealed the moment the message tool's send resolves, instead of waiting for the dispatcher's idle grace window. The signal only fires for sends that actually target the source conversation.
• What changed: new TypingController.markSourceReplyDelivered(); message(action=send) fires an optional onSourceReplyDelivered callback when sourceReplyDeliveryMode === "message_tool_only", the send is a real (non-dry-run) success, and the resolved channel + target match the source conversation (or it's the webchat internal-source sink). The callback is threaded through both runtime paths: the default Pi runtime (createOpenClawTools → pi-tools → runEmbeddedPiAgent) and the Codex app-server dynamic message tool (extensions/codex/src/app-server/run-attempt.ts → buildDynamicTools). Wired in agent-runner.ts / followup-runner.ts to call typing.markSourceReplyDelivered().
• What did NOT change: the heartbeat typing pipeline is untouched, DISPATCH_IDLE_GRACE_MS is left at 10s (shortening it makes the bug worse — see the linked issue), and the automatic source-reply path is unaffected. A message.send to a different channel/recipient inside the same turn is left alone — only the source-conversation send seals the source typing.

Motivation

Users perceive the bot as "still typing" for ~10s after a reply has already arrived in DM. It's small but it makes the agent feel laggy or stuck. Issue #84276 traces it to the keepalive loop racing with the dispatcher's finally block; this PR addresses it on the path the issue calls out (Option 2 / Option 3 in the write-up).

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 Discord typing indicator lingers ~10s after reply delivery in message_tool_only source-reply path #84276
• Related #
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Discord typing indicator no longer lingers after a message_tool_only reply lands, and only the source conversation's typing is sealed when the message tool delivers.
• Real environment tested: I don't have a live Discord workspace from this machine. To exercise the fix end to end without a live channel, I ran the runtime semantics + the new source-conversation guard directly under node. Terminal capture below shows the actual stdout from node verify-typing-fix.mjs after the patch.
• Exact steps or command run after this patch:

  node verify-typing-fix.mjs
  

  (The script inlines the post-patch TypingController lifecycle and the new sendTargetIsSourceConversation guard from src/agents/tools/message-tool.ts, then drives 8 scenarios against them.)
• Evidence after fix (terminal capture, real stdout):

Verifying TypingController.markSourceReplyDelivered + source-conversation guard (issue #84276)

[1/8] keepalive stops on markSourceReplyDelivered  (replyStart=2, cleanup=1)
[2/8] idempotent across repeat calls           (cleanup=1)
[3/8] late markRunComplete/markDispatchIdle/cleanup are no-ops once sealed
[4/8] dispatch-idle grace timer is cleared when delivery wins the race
[5/8] no-op when typing was never started     (reply=0, cleanup=0)
[6/8] source-conversation send matches even with channel-target prefix
[7/8] sends to other channels or recipients do not seal the source typing
[8/8] webchat internal-source sink always counts as a source-conversation send

All 8 scenarios pass. Discord typing keepalive halts in lockstep with delivery, and only for the source conversation.

• Observed result after fix: keepalive halts the moment message(action=send) reports a successful non-dry-run send to the source conversation. Subsequent markRunComplete / markDispatchIdle from the dispatcher's finally block are no-ops, so no further sendTyping packets refresh Discord's TTL after the reply has landed. Cross-channel and cross-recipient sends in the same turn do not affect the source-channel typing.
• What was not tested: a live Discord DM run with a real bot token. I do not have a spare bot/token wired up here. If a maintainer or @openclaw-mantis can capture the visible bubble disappearance for the redacted live recording the reviewer suggested, that closes the loop.
• Before evidence: the lingering ~10s typing bubble is documented in the original issue write-up (logs + repro steps in Discord typing indicator lingers ~10s after reply delivery in message_tool_only source-reply path #84276).

Root Cause

• Root cause: createTypingController only calls cleanup() once both runComplete and dispatchIdle are true. In message_tool_only mode those signals are both fired together from the dispatcher's finally block, after the message tool has already returned. The 6s keepalive can issue one more sendTyping while the tool is in flight, and Discord's ~10s typing TTL keeps the bubble alive long after we think we cleaned up.
• Missing detection / guardrail: there was no signal between the message tool delivering a visible reply and the typing controller. The controller had no concept of "the visible reply is on screen, stop refreshing the TTL".
• Contributing context: shortening DISPATCH_IDLE_GRACE_MS makes things worse — it seals the controller before the legitimate markDispatchIdle arrives, but Discord's TTL is independent of our cleanup so the bubble still hangs.

Regression Test Plan

• 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/typing-persistence.test.ts, src/agents/tools/message-tool.test.ts.
• Scenario the test should lock in: when the message tool successfully delivers a visible reply under sourceReplyDeliveryMode === "message_tool_only" to the source conversation, the keepalive stops immediately, onCleanup fires once, and any late markRunComplete / markDispatchIdle from the dispatcher's finally block are no-ops. A message.send to a different channel/recipient inside the same turn must not seal the source typing.
• Why this is the smallest reliable guardrail: the bug class lives in the typing controller's lifecycle gate plus the hand-off from the message tool. Both sides are now covered with unit tests (5 new lifecycle tests + 9 new message-tool tests covering source/cross/internal-source/dry-run/automatic/non-send/throwing-callback paths) and don't require a live channel to exercise.
• Existing test that already covers this: nothing. There were tests for markRunComplete / markDispatchIdle separately, but nothing for the message_tool_only delivery path.
• If no new test is added: N/A, new tests are added.

User-visible / Behavior Changes

Discord (and any other channel using message_tool_only) clears the typing indicator in lockstep with delivery instead of holding it for the channel-side TTL. No config flag. The path that was broken now matches what users already expect from the automatic path. Side messages to other conversations within the same turn are not affected.

Diagram

Before:
[message tool send] -> [reply delivered]
            keepalive tick at 6s -> sendTyping (refreshes ~10s TTL)
[run finally] -> markRunComplete + markDispatchIdle
            controller cleans up, but Discord still shows typing
            until its TTL expires (~10s after the reply landed)

After:
[message tool send to source convo] -> [reply delivered]
            -> onSourceReplyDelivered()  (guarded: source channel + target match)
            -> typing.markSourceReplyDelivered()
            -> keepalive loop stops, onCleanup fires, controller sealed
            (no further sendTyping refreshes the TTL)

[message tool send to a different conversation in the same turn]
            -> guard returns false, source typing is left alone

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No — if anything we make slightly fewer outbound sendTyping calls per turn.
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• Integration/channel: Discord DM, chat_type=direct, sourceReplyDeliveryMode === "message_tool_only".
• Relevant config (redacted):

agents:
  defaults:
    typingMode: instant
messages:
  visibleReplies: message_tool

Steps

1. Send any prompt to the agent in a Discord DM with message_tool_only configured.
2. Watch the typing indicator after the reply text appears.
3. Before this patch: typing bubble persists for ~10s. After: bubble disappears in lockstep with delivery.

Expected

• Typing bubble clears as soon as the reply message lands in the channel.

Actual

• With this patch applied, the keepalive loop is stopped via markSourceReplyDelivered() the moment the message tool reports a successful non-dry-run send to the source conversation, so no further sendTyping packets refresh the TTL.

Human Verification (required)

• Verified scenarios:
  • markSourceReplyDelivered() stops the keepalive immediately and fires onCleanup once.
  • Idempotent across repeat calls.
  • Late markRunComplete / markDispatchIdle / cleanup calls are no-ops once sealed.
  • The 10s dispatch-idle grace timer is cleared if delivery wins the race against markRunComplete.
  • Calling it before typing has started is a clean no-op.
  • Message-tool callback fires only when action === "send", sourceReplyDeliveryMode === "message_tool_only", the result is a send, and dryRun !== true. It does not fire for dry runs, automatic, or non-send actions.
  • Source-conversation guard: callback fires for default-routed sends, prefix-normalized matches (user:123 vs 123), and webchat handledBy === "internal-source" sends. It does not fire for cross-channel sends or same-channel sends to a different recipient.
  • A throwing onSourceReplyDelivered callback does not fail the tool call.
• Edge cases checked: repeat delivery (idempotent), late tool/block callbacks after delivery (controller sealed so they can't restart typing), heartbeat path (uses a separate typing pipeline so it stays unchanged), cross-conversation message.send inside the same turn (source typing untouched).
• What I did not verify: a live Discord bot run end to end. I don't have a spare bot/token on this machine.

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. The new onSourceReplyDelivered option and markSourceReplyDelivered method are both optional. Callers that don't pass the callback get exactly the previous behavior.
• Config/env changes? No.
• Migration needed? No.
• If yes, exact upgrade steps: N/A.

Risks and Mitigations

• Risk: the message tool's onSourceReplyDelivered callback throws and we swallow the error.
  • Mitigation: the swallow is intentional and narrowly scoped to the callback invocation. Typing cleanup is best-effort and should never fail a successful send. The rest of the tool result path is untouched.
• Risk: a heuristically-routed send is misclassified as cross-conversation and we miss the chance to seal typing.
  • Mitigation: the source-conversation guard normalizes the channel-target prefix on both sides before comparing, and the webchat handledBy === "internal-source" sink short-circuits to "always source". The fall-through behavior is the same as the original bug (typing lingers for the channel TTL), so a misclassification can only ever degrade to the pre-patch state — it cannot kill typing for a wrong conversation.
• Risk: an agent that calls message(action=send) to the source conversation more than once in a single turn won't get a typing indicator for the 2nd/3rd call.
  • Mitigation: in message_tool_only mode disableBlockStreaming is already true, so block streaming wasn't driving typing for those follow-up sends anyway. The trade-off (no typing for follow-up sends to the same conversation inside one turn) is the explicit design in Option 2 of the linked issue write-up, and is preferable to a typing bubble that lingers after the user has already seen the first reply.