Bug type

Behavior bug (incorrect output/state without crash)

Summary

In the MS Teams pairing flow, the first direct message creates a pairing request but returns before saving a conversation reference, so openclaw pairing approve msteams <code> --notify cannot proactively notify the requester.

Steps to reproduce

1. Deploy OpenClaw with the MS Teams channel enabled on a fresh host.
2. Upload/install the Teams app in personal scope.
3. Send the bot a first 1:1 DM from a user who is not yet allowlisted.
4. Observe logs: "msteams pairing request created" followed by "dropping dm (not allowlisted)".
5. Approve the pending request with openclaw pairing approve msteams <code> --notify (or an equivalent wrapper that calls it).
6. Observe the CLI logs "Approved msteams sender " and then "Failed to notify requester: Error: No conversation reference found for user:".
7. Send a second DM from the same user after approval; the bot now replies normally.

Expected behavior

The first inbound DM should persist the Teams conversation reference before the pairing/allowlist return path, so --notify can proactively send the approval message. At minimum, approving a pairing request with --notify should work immediately after the first DM.

Actual behavior

The first DM creates the pairing request but does not persist a conversation reference. Approval succeeds, but the notify step always fails with No conversation reference found for user:<id>. Only after the user sends a second DM does the bot have a stored conversation reference and start replying normally.

OpenClaw version

2026.3.8 (3caab92)

Operating system

Ubuntu 24.04 LTS

Install method

install-cli.sh on a fresh Azure VM

Model

openai/gpt-5.2

Provider / routing chain

openclaw -> Azure OpenAI Responses API

Config file / key location

/data/openclaw.json ; channels.msteams ; /etc/openclaw/openclaw.env

Additional provider/model setup details

The issue reproduces on a fresh Azure deployment with the built-in MS Teams extension. The model/provider is not the trigger; this is a channel-flow bug in the Teams pairing path. Relevant source analysis:

• extensions/msteams/src/monitor-handler/message-handler.ts: the pairing branch logs "msteams pairing request created" and then returns on "dropping dm (not allowlisted)" before the later conversationStore.upsert(...) block runs.
• extensions/msteams/src/channel.ts: notifyApproval sends proactively via sendMessageMSTeams({ to: id, text: PAIRING_APPROVED_MESSAGE }).
• extensions/msteams/src/send-context.ts: proactive sends require a stored conversation reference and throw No conversation reference found for user:<id> if none exists.

This makes the first-DM pairing notification path structurally impossible.

Logs, screenshots, and evidence

Impact and severity

Affected: first-time MS Teams DM users in pairing mode
Severity: medium-high (breaks onboarding / approval notification path)
Frequency: 100% reproducible
Consequence: the user does not receive the approval/proactive notify message after the first DM, and pairing UX is broken until they send a second message manually

Additional information

This looks related to, but distinct from, #23777. #23777 deals with delivery-queue fallout after No conversation reference found. This report is about the root cause in the first-DM Teams pairing flow: the conversation reference is not saved before the pairing return path. Workaround: approve the pairing, then have the user send a second DM; only then does the bot have a stored conversation reference.