Summary

When an agent connected via MS Teams performs tool calls that take longer than ~15 seconds, the Bot Framework's TurnContext proxy expires. The agent generates a complete response, but delivery fails because the final reply still attempts to use the revoked TurnContext instead of falling back to proactive messaging.

Steps to reproduce

1. Configure OpenClaw with channels.msteams and replyStyle: "top-level"
2. Send a message that triggers multiple tool calls (e.g., web search + exec + memory search)
3. Agent takes >15s to complete all tool calls and generate response

Expected behavior

The full response should be delivered via proactive messaging (continueConversation) when the TurnContext is no longer available.

Actual behavior

• First text chunk (if emitted before TurnContext expires) is delivered ✅
• Final reply after tool calls fails with: msteams final reply failed: Cannot perform 'set' on a proxy that has been revoked ❌
• The complete response exists in the session transcript but is never delivered to the user

OpenClaw version

2026.2.15

Operating system

Ubuntu 24.04

Install method

npm global

Logs, screenshots, and evidence

msteams final reply failed: Cannot perform 'set' on a proxy that has been revoked
msteams final reply failed: Cannot perform 'get' on a proxy that has been revoked

Repeated on every message where tool calls exceed ~15s.

Impact and severity

Affected: MS Teams users with agents that use tool calls
Severity: High (agent responses silently lost)
Frequency: 100% repro when tool calls exceed ~15s
Consequence: Users see partial or no response; complete answer exists in transcript but never delivered

Additional information

With replyStyle: "top-level", content messages are correctly sent via proactive messaging. However, sendFinalReply in the dispatch flow still attempts to use the original TurnContext. When this fails, there's no fallback to proactive messaging.

The fix would be to catch the "proxy revoked" error in the final reply path and retry via continueConversation using the stored conversation reference.

Workaround: instruct agent via SOUL.md to minimize tool calls per turn, but doesn't fully solve the issue.