Skip to content

fix(msteams): add @microsoft/agents-hosting to root dependencies#43761

Closed
BradGroux wants to merge 1 commit intomainfrom
fix/msteams-bundled-deps-root-mirror
Closed

fix(msteams): add @microsoft/agents-hosting to root dependencies#43761
BradGroux wants to merge 1 commit intomainfrom
fix/msteams-bundled-deps-root-mirror

Conversation

@BradGroux
Copy link
Copy Markdown
Contributor

@BradGroux BradGroux commented Mar 12, 2026 •
edited
Loading

Summary

Fixes the runtime crash Cannot find module '@microsoft/agents-hosting' that occurs when the bundled msteams extension is loaded in global npm or Homebrew installs, as originally reported in #15622.

Relationship to #12849

PR #12849 addressed the plugin installation side of #15622 by adding a bundled-source fallback when npm pack returns a 404. That fix landed, but the runtime module resolution issue persisted: even after successful installation, the msteams extension crashes at load time because @microsoft/agents-hosting is not hoisted to the root node_modules. This PR closes the remaining gap by mirroring the dependency into the root package.json.

Root Cause

First reported in #15622: after updating OpenClaw, the Teams channel breaks with Cannot find module '@microsoft/agents-hosting'.

Bundled extensions ship inside the openclaw package via the files: ["extensions/"] entry in package.json, but their own node_modules directories are not included in the published tarball. When OpenClaw is installed globally (npm, Homebrew, pnpm global), Node's module resolution starts from the main openclaw package and cannot find @microsoft/agents-hosting because it was only declared in the extension's package.json.

The repo's rootDependencyMirrorAllowlist mechanism (enforced by scripts/release-check.ts) was explicitly marking this gap as "expected" — so the release-check gate passed, but the runtime still failed.

What Changed

File Change
package.json Added "@microsoft/agents-hosting": "^1.3.1" to root dependencies
extensions/msteams/package.json Cleared the now-stale rootDependencyMirrorAllowlist entry (was ["@microsoft/agents-hosting"], now [])
pnpm-lock.yaml Updated to include the new root dependency

The version range ^1.3.1 matches the extension's own declaration in extensions/msteams/package.json.

Validation

  • ✅ test/release-check.test.ts — all 8 tests pass
  • ✅ Root dependency mirror gap check — no drift detected across all bundled extensions
  • ✅ extensions/msteams/ test suite — 224/225 pass; the 1 failure (probe.test.ts credential check) is pre-existing on main and unrelated to this change
  • ✅ pnpm-lock.yaml updated via pnpm install --lockfile-only on current main

Why This Supersedes #16606

PR #16606 by @daocoding correctly identified the root cause and proposed the right fix direction. However, it:

  1. Only edited package.json — missing the pnpm-lock.yaml update required for merge
  2. Added 3 packages (@microsoft/agents-hosting, @microsoft/agents-hosting-express, @microsoft/agents-hosting-extensions-teams) — but only @microsoft/agents-hosting is actually imported by the extension code (the other two were sub-packages from an older SDK split)
  3. Used version ^1.2.3 — the extension now declares ^1.3.1
  4. Did not clean up rootDependencyMirrorAllowlist — which would cause the release-check gate to flag stale entries

This PR implements the minimal correct fix against current main.

Architectural Note

The rootDependencyMirrorAllowlist mechanism is a pragmatic workaround for the fundamental issue: bundled extensions declare their own dependencies but those deps aren't available in the root node_modules at runtime. A more robust solution would be to either:

  • Include extension node_modules in the published tarball, or
  • Pre-bundle extensions into self-contained artifacts during the build

This is out of scope for this fix but noted for future consideration.

Scope & Caveats

This PR targets one specific failure mode: the recurring Cannot find module '@microsoft/agents-hosting' crash that breaks the msteams extension after updates. The underlying issue — bundled extensions whose dependencies aren't hoisted to the root node_modules — is not unique to Teams; the same class of problem has surfaced for other extensions and install paths (see #41431, #9357, #17089). This fix addresses the Teams instance by mirroring the dependency into the root package, but it is not a general solution to the broader bundled-extension resolution pattern.

What this does NOT cover:

References

@BradGroux
fix(msteams): add @microsoft/agents-hosting to root dependencies
9a5f4cc 
Bundled extensions ship inside the openclaw package (via the files array),
but their node_modules are not included. In global/Homebrew installs, Node
module resolution cannot find @microsoft/agents-hosting because it was only
declared in the extension's package.json and explicitly allowlisted as an
expected gap via rootDependencyMirrorAllowlist.

This commit:
- Adds @microsoft/agents-hosting ^1.3.1 to the root package.json
  dependencies so it is installed alongside openclaw in all install modes
- Clears the now-stale rootDependencyMirrorAllowlist entry in the msteams
  extension manifest so the release-check gate will catch future drift
- Updates pnpm-lock.yaml to include the new root dependency

Fixes the runtime error:
  Cannot find module '@microsoft/agents-hosting'

Supersedes #16606.
Refs: #15622, #9357, #17089, #41431
Copilot AI review requested due to automatic review settings March 12, 2026 06:38
@openclaw-barnacle openclaw-barnacle bot added channel: msteams Channel integration: msteams size: XS maintainer Maintainer-authored PR labels Mar 12, 2026
@BradGroux BradGroux mentioned this pull request Mar 12, 2026
Closed
Copilot AI reviewed Mar 12, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes runtime Cannot find module '@microsoft/agents-hosting' crash for global npm/Homebrew installs by hoisting the msteams extension's dependency to the root package.json.

Changes:

  • Added @microsoft/agents-hosting: ^1.3.1 to root package.json dependencies
  • Cleared the rootDependencyMirrorAllowlist in the msteams extension since the dependency is now mirrored
  • Updated pnpm-lock.yaml accordingly

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.

File Description
package.json Added @microsoft/agents-hosting to root dependencies
extensions/msteams/package.json Emptied rootDependencyMirrorAllowlist since the gap is resolved
pnpm-lock.yaml Lock file updated for new root dependency
Files not reviewed (1)
  • pnpm-lock.yaml: Language not supported

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 12, 2026

Greptile Summary

This PR fixes a runtime crash (Cannot find module '@microsoft/agents-hosting') that occurs when the bundled msteams extension is loaded after a global npm or Homebrew install. The fix is minimal and correct: the missing dependency is added to the root package.json at the version already declared by the extension (^1.3.1), the now-stale rootDependencyMirrorAllowlist entry is cleared so the release-check gate stays accurate, and pnpm-lock.yaml is updated accordingly.

  • @microsoft/agents-hosting: ^1.3.1 added to root dependencies in package.json, matching the version declared in extensions/msteams/package.json
  • rootDependencyMirrorAllowlist cleared to [] in extensions/msteams/package.json — the release-check logic confirms this is consistent: with the dep now present in root dependencies, missing will be empty and will equal the empty allowlist
  • pnpm-lock.yaml updated, resolving the specifier to 1.3.1
  • The changelog confirms @microsoft/agents-hosting-express and @microsoft/agents-hosting-extensions-teams were intentionally removed from root deps previously (deps: remove dead root dependency #22471), so the PR is correct to add only @microsoft/agents-hosting

Confidence Score: 5/5

  • This PR is safe to merge — it is a minimal, well-reasoned dependency fix with no behavioral changes to application logic.
  • The change is a three-file addition of a single root dependency that was already declared (and validated) at the extension level. The version is pinned to an exact range (^1.3.1) that matches the extension's own declaration, the lockfile is updated, and the allowlist cleanup is consistent with the release-check gate logic. No application code is modified.
  • No files require special attention.

Last reviewed commit: 9a5f4cc

@BradGroux BradGroux self-assigned this Mar 12, 2026
@BradGroux
Copy link
Copy Markdown
Contributor Author

BradGroux commented Mar 12, 2026

@onutc - Please review when you get a chance - see my message in Discord for more context, thanks!

@BradGroux
Copy link
Copy Markdown
Contributor Author

BradGroux commented Mar 12, 2026 •
edited
Loading

I don’t think this should merge in its current form.

The core issue here appears to be architectural, not just a missing package or post-update reinstall step. The Teams extension does not appear to be sealed as its own deployable runtime unit. It still seems to rely on module resolution from the surrounding global/OpenClaw install tree, which makes it fragile across updates.

That matters because a source-level package.json is not the same thing as an isolated runtime boundary.

If the extension’s required runtime dependencies are being resolved from shared or global install locations instead of from an extension-owned install/runtime artifact, then updates to OpenClaw can still break the extension even when the extension itself has not changed.

At minimum, I think we need to answer these questions before merging:

  1. Are extension runtime dependencies guaranteed to be installed and resolved from an extension-specific boundary, rather than from the shared/global OpenClaw tree?
  2. If not, what is the intended packaging/deployment model for extensions that have runtime-only dependencies?
  3. Are other extensions exposed to the same failure mode during updates?
  4. Is this PR fixing the root cause, or just reapplying one missing dependency after the fact?

I don’t think we should merge this until we have a clearer picture of the runtime dependency path. Right now, it risks papering over a packaging/deployment problem rather than actually proving the underlying model is sound.

I’d rather pause here, verify how extension runtime dependencies are being resolved during and after updates, and then decide whether this PR is fixing the root cause or just the current symptom.

Moving to Draft as I work through this.

@BradGroux BradGroux marked this pull request as draft March 12, 2026 09:26
@BradGroux
Copy link
Copy Markdown
Contributor Author

BradGroux commented Mar 12, 2026 •
edited
Loading

What I’m seeing is a broader pattern in OpenClaw where extensions/plugins with runtime dependencies can break across install/update paths when those dependencies are not reliably preserved, bundled, or resolved from a stable runtime boundary.

Why I’m concerned

  • A source-level package.json is not, by itself, proof of a sealed runtime boundary.
  • If an extension’s runtime dependencies are still effectively coming from the shared/global OpenClaw install tree, then updates can break the extension even when the extension itself has not changed.
  • This PR may restore the current missing dependency, but I’m not yet convinced it resolves the larger class of failure.

This does not appear to be Teams-only. I went looking for related OpenClaw issues/PRs and found a recurring pattern across multiple extensions/plugins. These are the related issues/PRs I found that most clearly point to the same extension/plugin dependency-loss pattern. This may not be exhaustive:

Directly relevant issues

Same failure class showing up in memory-lancedb / bundled deps

Related PRs

My current takeaway

  • This looks like a recurring packaging/runtime-dependency problem, not a one-off Teams incident.
  • The recurring pattern is: extension/plugin code exists, but runtime deps are lost, skipped, or incorrectly resolved across global install, npm pack, pnpm, brew, Docker, or update flows.

TL;DR - This doesn't look like an issue isolated to Microsoft Teams.

@BradGroux
Copy link
Copy Markdown
Contributor Author

BradGroux commented Mar 12, 2026 •
edited
Loading

Another way to view the findings, known affected extensions/plugins:

  • MSTeams
  • Matrix
  • Feishu
  • memory-lancedb
  • ACPX
  • google-antigravity-auth

1. MSTeams - missing/wiped: @microsoft/agents-hosting
refs: #15622, #16606, #43761, #17089

2. Matrix - missing/wiped: @vector-im/matrix-bot-sdk
refs: #41431, #16031, #28370, #31231

3. Feishu - missing after install / npm pack flow
refs: #43355, #33723, #24211, #37187

4. memory-lancedb - missing/wiped: @lancedb/lancedb and related native/runtime deps
refs: #26100, #28792, #20060, #22687, #42668, #13671, #22692

5. ACPX plugin - subdependencies not installed on global npm install
ref: #40006

6. google-antigravity-auth - plugin removed across updates
ref: #29348

@BradGroux
Copy link
Copy Markdown
Contributor Author

BradGroux commented Mar 13, 2026

@umangsehgal @SidU - Would love your input on this if you get the chance.

@BradGroux BradGroux mentioned this pull request Mar 17, 2026
Draft
@BradGroux
Copy link
Copy Markdown
Contributor Author

BradGroux commented Mar 26, 2026

Closing as resolved by #51808 (merged 2026-03-24), which migrated the Teams extension to the official Microsoft Agents SDK and eliminated the @microsoft/agents-hosting dependency entirely. Adding it to root deps is no longer necessary.

@BradGroux BradGroux closed this Mar 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Copilot code review Copilot Copilot left review comments

Assignees

@BradGroux BradGroux

Labels

channel: msteams Channel integration: msteams maintainer Maintainer-authored PR size: XS

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@BradGroux