1. extensions/msteams/src/thread-parent-context.ts, line 86-88 (link)

   Error results no longer cached; persistent 403s will retry on every message

   Before this PR, fetchChannelMessage silently caught errors and returned undefined. fetchParentMessageCached cached that undefined, so repeated calls for the same parent (e.g., a burst of replies) would not re-hit Graph. Now that fetchChannelMessage propagates errors, the await fetchParent(...) on line 86 throws instead of returning undefined, and touchLru is never reached — meaning nothing is cached on failure.

   In environments where Graph is persistently inaccessible (wrong permissions, restricted tenant), every incoming channel thread message will trigger two failing Graph calls (parent + replies) without any backoff or negative-result cache. The test "caches undefined (Graph error) so failures do not re-fetch on burst" in thread-parent-context.test.ts still passes because it injects a mock fetcher that returns undefined — it no longer describes the real behavior of the default fetchChannelMessage.

   Consider wrapping the await fetchParent(...) in a try/catch that stores a sentinel on error so burst retries still hit the cache:

   let message: GraphThreadMessage | undefined;
   try {
     message = await fetchParent(token, groupId, channelId, parentId);
   } catch {
     // Cache the failure so burst retries do not hammer Graph on persistent errors.
     touchLru(parentCache, key, { message: undefined, expiresAt: now + PARENT_CACHE_TTL_MS }, PARENT_CACHE_MAX);
     throw;
   }
   touchLru(parentCache, key, { message, expiresAt: now + PARENT_CACHE_TTL_MS }, PARENT_CACHE_MAX);
   return message;

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: extensions/msteams/src/thread-parent-context.ts
   Line: 86-88
   
   Comment:
   **Error results no longer cached; persistent 403s will retry on every message**
   
   Before this PR, `fetchChannelMessage` silently caught errors and returned `undefined`. `fetchParentMessageCached` cached that `undefined`, so repeated calls for the same parent (e.g., a burst of replies) would not re-hit Graph. Now that `fetchChannelMessage` propagates errors, the `await fetchParent(...)` on line 86 throws instead of returning `undefined`, and `touchLru` is never reached — meaning nothing is cached on failure.
   
   In environments where Graph is persistently inaccessible (wrong permissions, restricted tenant), every incoming channel thread message will trigger two failing Graph calls (parent + replies) without any backoff or negative-result cache. The test `"caches undefined (Graph error) so failures do not re-fetch on burst"` in `thread-parent-context.test.ts` still passes because it injects a mock fetcher that returns `undefined` — it no longer describes the real behavior of the default `fetchChannelMessage`.
   
   Consider wrapping the `await fetchParent(...)` in a try/catch that stores a sentinel on error so burst retries still hit the cache:
   
   ```ts
   let message: GraphThreadMessage | undefined;
   try {
     message = await fetchParent(token, groupId, channelId, parentId);
   } catch {
     // Cache the failure so burst retries do not hammer Graph on persistent errors.
     touchLru(parentCache, key, { message: undefined, expiresAt: now + PARENT_CACHE_TTL_MS }, PARENT_CACHE_MAX);
     throw;
   }
   touchLru(parentCache, key, { message, expiresAt: now + PARENT_CACHE_TTL_MS }, PARENT_CACHE_MAX);
   return message;
   ```
   
   How can I resolve this? If you propose a fix, please make it concise.

2. extensions/msteams/src/graph.ts, line 217-229 (link)

   graphTenantId path untested; new App instance created on every call

   loadMSTeamsSdkWithAuth(graphCreds) is called on every invocation of resolveGraphToken. For the cross-tenant path (graphTenantId !== tenantId), this instantiates a second Bot Framework App per call. For CLI commands that call resolveGraphToken in a loop this can be expensive.

   Additionally, the new graphCreds substitution has no test coverage in graph.test.ts — neither the token acquisition with graphTenantId nor the fallback when graphTenantId === tenantId. Similarly, token.test.ts has no cases that exercise graphTenantId propagation through resolveMSTeamsCredentials. For a feature that changes which OAuth tenant is used to acquire tokens, adding at least happy-path tests would help prevent regressions.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: extensions/msteams/src/graph.ts
   Line: 217-229
   
   Comment:
   **`graphTenantId` path untested; new `App` instance created on every call**
   
   `loadMSTeamsSdkWithAuth(graphCreds)` is called on every invocation of `resolveGraphToken`. For the cross-tenant path (`graphTenantId !== tenantId`), this instantiates a second Bot Framework `App` per call. For CLI commands that call `resolveGraphToken` in a loop this can be expensive.
   
   Additionally, the new `graphCreds` substitution has no test coverage in `graph.test.ts` — neither the token acquisition with `graphTenantId` nor the fallback when `graphTenantId === tenantId`. Similarly, `token.test.ts` has no cases that exercise `graphTenantId` propagation through `resolveMSTeamsCredentials`. For a feature that changes which OAuth tenant is used to acquire tokens, adding at least happy-path tests would help prevent regressions.
   
   How can I resolve this? If you propose a fix, please make it concise.

Best possible solution:

Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

Do we have a high-confidence way to reproduce the issue?

Partially. The missing capability is source-visible because current main has no graphTenantId or MSTEAMS_GRAPH_TENANT_ID, but the successful cross-tenant Microsoft Graph path needs external tenant proof.

Is this the best way to solve the issue?

No, not yet. The Teams plugin is the right owner, but this branch must be rebased to preserve current cloud/serviceUrl boundaries and then proven against a real split-tenant setup.

Security review:

Security review needs attention: The diff is security-sensitive because the new Graph tenant override must not bypass existing Teams cloud/serviceUrl boundaries.

• [medium] Graph token path can drop cloud boundary — extensions/msteams/src/graph.ts:71
  The PR branch creates the Graph-token SDK App without current main's cloud/serviceUrl options or China Graph fail-closed guard, which can misroute sovereign-cloud Graph token acquisition after conflict resolution.
  Confidence: 0.88

AGENTS.md: found and applied where relevant.

What I checked:

• stale F-rated PR: PR was opened 2026-04-15T12:36:58Z, is older than 60 days, and the latest review rated it F.
• proof blocker: real behavior proof is missing and proof tier is F, so this branch is not merge-ready without contributor follow-up.
• no human follow-up: live comments and timeline hydrated by apply contain no non-automation activity after the ClawSweeper review.

Likely related people:

• heyitsaamir: GitHub path history shows commit 04c2982 added Teams SDK cloud/serviceUrl and China boundary work across graph.ts, cloud.ts, and docs. (role: introduced current cloud boundary behavior; confidence: high; commits: 04c29825356f; files: extensions/msteams/src/graph.ts, extensions/msteams/src/cloud.ts, docs/channels/msteams.md)
• sudie-codes: GitHub path history shows substantial Teams Graph, delegated auth, pagination, reaction, and helper work in the same graph.ts/token.ts area. (role: Teams Graph feature owner; confidence: high; commits: 355794c24a39, f71ee71787c7; files: extensions/msteams/src/graph.ts, extensions/msteams/src/token.ts)
• HDYA: Commit 26f633b added federated Teams credential support across token, SDK, config type/schema, and docs surfaces now adjacent to graphTenantId. (role: Teams auth feature introducer; confidence: medium; commits: 26f633b604fd; files: extensions/msteams/src/token.ts, extensions/msteams/src/sdk.ts, src/config/types.msteams.ts)
• vincentkoc: Recent history shows Teams SDK import and Graph guard work near graph.ts, sdk.ts, and token.ts, including Graph fetch hardening. (role: recent Teams SDK/auth contributor; confidence: medium; commits: d0034e2f9912, 3cc83cb81ec3; files: extensions/msteams/src/graph.ts, extensions/msteams/src/sdk.ts, extensions/msteams/src/token.ts)
• steipete: Recent path history shows adjacent Teams docs/config/token work and the local shallow blame points current-main Teams Graph/cloud lines to the grafted current snapshot. (role: recent area contributor; confidence: medium; commits: 58912f8fd842, 3fffb34ba0c0; files: extensions/msteams/src/graph.ts, extensions/msteams/src/token.ts, docs/channels/msteams.md)

Codex review notes: model internal, reasoning high; reviewed against f3f8ca3d922c.

• The egg game starts only after the PR passes the real-behavior proof check.
• Before that, no creature or rarity is rolled. The treat waits for real proof.
• This is still just collectible flavor: proof affects review readiness, not creature quality.