Summary

When a Microsoft Teams DM arrives from a non-admin user (e.g., an employee), it overwrites the main session's reply context. If the Teams provider then crashes and recovers, and a heartbeat fires in the same session, the heartbeat response is delivered to the Teams DM user instead of the configured primary channel (Telegram). This caused private business data (financial figures, security alerts) to be sent directly to an employee's Teams DM with no warning.

Steps to reproduce

1. Configure OpenClaw with Telegram as primary channel + Microsoft Teams
2. A non-admin Teams user sends a DM to the bot (e.g., "hi")
3. The msteams provider crashes mid-reply (proxy revoked error — observed in logs as msteams final reply failed: Cannot perform 'set' on a proxy that has been revoked)
4. The health monitor restarts the msteams provider
5. A heartbeat fires in the same main session (session:agent:main:main)
6. Result: The heartbeat response is delivered to the Teams DM user, not to the Telegram primary channel

Expected behavior

Heartbeat responses (and cron deliveries) should always route to the configured primary channel, regardless of what channel most recently wrote to the session. A Teams DM from a non-admin user should never become the reply target for session-level events like heartbeats.

Actual behavior

The incoming Teams DM overwrote the main session's reply context. A subsequent heartbeat response was delivered to the employee's Teams DM. The employee received private operational data including:

• A security/phishing alert with details about an internal email
• Financial payout amounts (Stripe payouts totaling ~$2,471)

The failed reply attempts (proxy revoked) did not clear the reply context, so the stale Teams context remained active and fired when the provider recovered.

OpenClaw version

2026.2.21

Operating system

MacOS

Install method

nom + Mac App

Logs, screenshots, and evidence

### Logs, screenshots, and evidence

Screenshot attached (redacted): Shows employee Teams DM containing heartbeat response with internal business data.

Key log sequence (UTC timestamps):
- `03:01` — Teams DM received, dispatched to `session:agent:main:main`, reply failed (proxy revoked)
- `03:03` — Second Teams DM, same result
- `03:14` — Health monitor restarts msteams provider
- `04:00` — Heartbeat fires in same session → response delivered to employee Teams DM ✅ (msteams now up)

Impact and severity

Critical — Data Privacy

Private operational/business data was sent to a non-admin employee with no warning or consent. In any deployment where Teams users include employees or external parties, this creates a serious data privacy risk. The operator has no way to know this is happening.

Additional information

Workaround (partial): Agents can use the message tool with an explicit channel and target for sensitive heartbeat/cron responses rather than relying on session reply routing. This bypasses the context leak but requires agent-level awareness of the issue.

Root cause hypothesis: Incoming multi-channel messages share session:agent:main:main and overwrite its reply context on arrival. Session-level events (heartbeats, cron completions) inherit last-write reply context rather than the primary channel context. Failed replies do not reset the context pointer, creating a time-bomb condition that fires when the provider recovers.