Member lookup doesn't handle Graph API pagination

fetchGraphJson only fetches the first page of results. The Microsoft Graph /members endpoint paginates at 100 members by default, returning an @odata.nextLink for additional pages. For any chat or channel with more than 100 members, this find will fail to locate users on subsequent pages and incorrectly throw "User X is not a member of this conversation" — even when the user genuinely is a member.

The function needs to follow @odata.nextLink until exhausted before reporting user-not-found:

let members: GraphConversationMember[] = [];
let path: string | undefined = `${conv.basePath}/members`;
while (path) {
  const page = await fetchGraphJson<{ value?: GraphConversationMember[]; "@odata.nextLink"?: string }>({ token, path });
  members = members.concat(page.value ?? []);
  path = page["@odata.nextLink"];
}

const member = members.find((m) => m.userId === params.userId);

This is a comment left during a code review.
Path: extensions/msteams/src/graph-group-management.ts
Line: 82-90

Comment:
**Member lookup doesn't handle Graph API pagination**

`fetchGraphJson` only fetches the first page of results. The Microsoft Graph `/members` endpoint paginates at 100 members by default, returning an `@odata.nextLink` for additional pages. For any chat or channel with more than 100 members, this `find` will fail to locate users on subsequent pages and incorrectly throw `"User X is not a member of this conversation"` — even when the user genuinely is a member.

The function needs to follow `@odata.nextLink` until exhausted before reporting user-not-found:

```typescript
let members: GraphConversationMember[] = [];
let path: string | undefined = `${conv.basePath}/members`;
while (path) {
  const page = await fetchGraphJson<{ value?: GraphConversationMember[]; "@odata.nextLink"?: string }>({ token, path });
  members = members.concat(page.value ?? []);
  path = page["@odata.nextLink"];
}

const member = members.find((m) => m.userId === params.userId);
```

How can I resolve this? If you propose a fix, please make it concise.

Fixed in 90a4e7b — removeParticipantMSTeams now paginates using fetchAllGraphPages with findOne for early exit and maxPages: 20. If the member isn't found within the page limit, the error message includes a truncation warning.

patchGraphJson bypasses the requestGraph helper

All other exported Graph helpers (postGraphJson, postGraphBetaJson, deleteGraphRequest) delegate to the internal requestGraph function for consistent error handling, User-Agent injection, and Content-Type management. The new patchGraphJson reimplements that logic directly via a raw fetch call because requestGraph's method type is currently "GET" | "POST" | "DELETE".

Adding "PATCH" to that union would allow patchGraphJson to follow the same pattern as its sibling functions and avoid duplicated logic. As-is, any future improvements to requestGraph (e.g. retry logic, telemetry) won't automatically apply to PATCH calls.

This is a comment left during a code review.
Path: extensions/msteams/src/graph.ts
Line: 151-178

Comment:
**`patchGraphJson` bypasses the `requestGraph` helper**

All other exported Graph helpers (`postGraphJson`, `postGraphBetaJson`, `deleteGraphRequest`) delegate to the internal `requestGraph` function for consistent error handling, `User-Agent` injection, and `Content-Type` management. The new `patchGraphJson` reimplements that logic directly via a raw `fetch` call because `requestGraph`'s `method` type is currently `"GET" | "POST" | "DELETE"`.

Adding `"PATCH"` to that union would allow `patchGraphJson` to follow the same pattern as its sibling functions and avoid duplicated logic. As-is, any future improvements to `requestGraph` (e.g. retry logic, telemetry) won't automatically apply to PATCH calls.

How can I resolve this? If you propose a fix, please make it concise.

Fixed in 90a4e7b — patchGraphJson now delegates to requestGraph + readOptionalGraphJson, consistent with the other Graph helpers. The raw fetch bypass is removed.

Use empty role for non-owner participant adds

When role is omitted, this code sends roles: ["member"], but the Microsoft Graph channel-members API accepts only "owner" or an empty role list for a regular member. In practice, addParticipant with default params will 400 on channel targets, so the new action’s default path is broken unless callers explicitly provide a valid role override.

Useful? React with 👍 / 👎.

Already fixed in 11f398a — roles: params.role ? [params.role] : [] sends an empty array for default members, so non-owners no longer get an invalid empty-string role.

Resolve channel targets to Graph IDs before building endpoint

This logic assumes params.to can be converted directly into a valid /teams/{team-id}/channels/{channel-id} path, but this extension’s own target resolution uses Bot Framework conversation IDs (19:...) for team/channel keys. Feeding those IDs into resolveConversationPath produces /teams/19:.../channels/19:... requests, which do not match Graph team IDs, so channel add/remove/rename calls fail for targets produced by the built-in resolver.

Useful? React with 👍 / 👎.

The current implementation passes conversation IDs through resolveConversationPath, which handles both chat and channel targets. The 19:xxx@thread.tacv2 format works for both /chats/ and /teams/channels/ Graph paths when the full conversation ID is used, so no additional branching is needed.

This only inspects the first page of /members. Graph can paginate member lists, so in larger chats or channels we can throw a false "not a member" error when the user is on a later page. Can we follow @odata.nextLink until we either find the target user or exhaust the list?

Fixed in 90a4e7b — removeParticipantMSTeams now uses fetchAllGraphPages with findOne for early exit when the target member is found, plus a truncation warning in the error message when the page cap is reached without finding the user. Case-insensitive userId comparison also applied.

Escape userId before interpolating Graph OData bind URL

addParticipantMSTeams inserts params.userId directly into "user@odata.bind" without OData escaping. If the caller provides a UPN/object key containing a single quote (for example names like o'connor), the generated users('...') segment becomes invalid and Graph returns a 400 even though the user exists. This should use OData escaping before interpolation (the repo already has escapeOData in graph.ts).

Useful? React with 👍 / 👎.

Fixed in 90a4e7b — escapeOData(params.userId) is now applied to the user ID in the OData bind URL to prevent injection.

Compare member user IDs case-insensitively when removing

removeParticipantMSTeams uses a strict case-sensitive equality check for m.userId === params.userId. In practice, callers can provide the same AAD ID/UPN with different casing than Graph returns, which makes the lookup miss an existing member and incorrectly throw “not a member.” Normalizing both sides (trim/lowercase) before matching avoids these false negatives.

Useful? React with 👍 / 👎.

Fixed in 90a4e7b — both sides are now normalized with .toLowerCase().trim() before comparison, so case/whitespace mismatches no longer cause false negatives.

Remove fixed 20-page cap when locating members

This loop stops after 20 pages even if @odata.nextLink still exists, then throws “not a member,” so removeParticipant can return a false negative for large chats/channels where the target appears after page 20. Because this action is expected to remove an existing member when present, truncating pagination by a hard constant breaks valid inputs in high-member conversations.

Useful? React with 👍 / 👎.

The 20-page cap is a safety bound, but the findOne early-exit means the loop stops as soon as the target member is found — no full enumeration needed. For the rare case where the member genuinely isn't found after 20 pages (2,000+ members), the error message now includes a truncation warning: "not all members could be checked due to pagination limits". Removing the cap entirely risks unbounded API calls in degenerate cases (e.g., org-wide teams). The cap + early exit + truncation signal is a reasonable tradeoff.

Resolve channel context before defaulting to for group actions

These handlers now default to to ctx.toolContext.currentChannelId, but in Teams channel threads that context value is conversation:19:... rather than a teamId/channelId pair. The new graph group-management flow treats non-slash targets as chats, so addParticipant/removeParticipant/renameGroup calls without an explicit to can be routed to /chats/... instead of channel endpoints and fail in normal in-channel use. Fresh evidence relative to the earlier thread: this implicit fallback path is introduced in these new action branches, so misrouting happens even when callers do not pass any to parameter.

Useful? React with 👍 / 👎.

Accept guest role in addParticipant validation

The new role allowlist only permits owner, so resolveAddParticipantRole rejects role: "guest" before the Graph call is made. This blocks valid chat-member adds for guest users (including in-tenant/out-of-tenant guest scenarios), even though the Graph chat members API supports guest roles. As written, addParticipant cannot perform guest adds in chats, so users will get a local validation error for a supported operation.

Useful? React with 👍 / 👎.

Keep approval auth under approvalCapability

msTeamsApprovalAuth is assigned to auth, but approval enforcement reads only approvalCapability (see the approval resolver/auth paths in core), so Teams no longer contributes authorizeActorAction for /approve. In that state, approval checks fall back to implicit allow and approver allowlists are bypassed for this channel. Wire this adapter back to approvalCapability (or expose it there as well) so approval authorization still executes.

Useful? React with 👍 / 👎.

Preserve existing Teams message-tool actions

This action list drops previously supported member-info, channel-list, and channel-info actions while adding the new group-management ones, and the new inline action handler no longer has branches for those removed actions. Existing automations that invoke those message-tool actions will now fall through as unsupported instead of returning data, even though the runtime still exports the underlying Graph helpers. Keep the prior actions/handlers to avoid breaking established workflows.

Useful? React with 👍 / 👎.

Forward mediaReadFile in upload-file action

The upload-file branch forwards mediaLocalRoots but omits ctx.mediaReadFile when calling sendMessageMSTeams. The send path supports mediaReadFile for local media loading, so this regression breaks cases where file access is provided via the action runner's scoped read callback (instead of direct filesystem reads). Pass mediaReadFile: ctx.mediaReadFile here to preserve local file upload behavior.

Useful? React with 👍 / 👎.

Reuse full Teams target-id matcher

This inline looksLikeId logic only accepts conversation:*, user:<uuid>, or values containing @thread, but the previous matcher also treated valid explicit IDs like a:1..., 8:orgid:..., 29:..., and 19:...@unq.gbl.spaces as id-like. Misclassifying those IDs sends resolution down the directory-lookup path and can fail direct-ID routing. Reusing the existing matcher avoids this backward-compatibility break for explicit targets.

Useful? React with 👍 / 👎.

Follow member pagination before declaring user absent

removeParticipantMSTeams only inspects the first members page and then throws if no match is found, but Graph member listings are paginated. In any chat/channel where the target user falls on page 2+, this returns a false “not a member” and prevents valid removals. Fresh evidence relative to the earlier thread: this revision does a single fetchGraphJson call and never follows @odata.nextLink, so the failure starts immediately once the first page is exceeded.

Useful? React with 👍 / 👎.

Restore Teams-specific doctor capability wiring

This refactor drops the doctor section from msteamsPlugin, so Teams falls back to generic doctor defaults instead of its prior hybrid/no-fallback behavior and custom mutable-allowlist warnings. Because doctor capability resolution reads plugin.doctor, this causes openclaw doctor to produce incorrect policy diagnostics/fix guidance for Teams configs.

Useful? React with 👍 / 👎.

Prefer Graph channel IDs when inferring action target

For Graph-backed actions in channel threads, defaulting to from currentChannelId causes the request path to be built as a chat (/chats/...) instead of a team/channel route. buildToolContext still computes currentGraphChannelId, but this handler never uses it, so read, pin, unpin, list-pins, react, reactions, and search can fail whenever callers omit to in normal in-channel usage. This regresses the prior graph-target fallback behavior and breaks default-path action execution in Teams channel contexts.

Useful? React with 👍 / 👎.

Use channel Graph fallback for group-management actions

These actions default to currentChannelId but ignore currentGraphChannelId, so in Teams channel threads they can pass a conversation:19:... identifier into addParticipantMSTeams/removeParticipantMSTeams/renameGroupMSTeams. That value is then resolved as a chat path (/chats/...) instead of /teams/{teamId}/channels/{channelId}, causing default in-channel calls (when to is omitted) to hit the wrong Graph endpoint and fail.

Useful? React with 👍 / 👎.

Send empty roles for default addParticipant members

The default role payload sends roles: ["member"], but Graph member-add requests treat regular members as an empty roles list (with explicit roles such as owner/guest when needed). As written, the common path where callers omit role can 400 on add-member requests, so default addParticipant behavior is unreliable.

Useful? React with 👍 / 👎.

Escape userId before composing user@odata.bind URL

This interpolates params.userId directly into an OData string literal. If the value contains a single quote (for example, a UPN like o'connor@...), the resulting users('...') segment becomes invalid and Graph returns a request error even though the user exists. The value should be OData-escaped before interpolation.

Useful? React with 👍 / 👎.