openclaw - 💡(How to fix) Fix [Bug]: Published package is missing plugin-sdk Telegram exports used by third-party plugins [1 participants]

Summary

On the currently published OpenClaw package (2026.3.31 in our environment), the npm package exports do not include ./plugin-sdk/telegram (or ./plugin-sdk/telegram-runtime).

That breaks third-party plugins that legitimately depend on Telegram runtime helpers via the plugin SDK surface.

Concrete failure we hit in production while reloading the Telegram Codex cockpit plugin:

Cannot find module '/home/chip/.npm-global/lib/node_modules/openclaw/dist/plugin-sdk/root-alias.cjs/telegram'
Require stack:
- /home/chip/.openclaw/extensions/openclaw-codex-app-server/src/controller.ts

Why this looks like a release/package regression

In source trees we inspected, OpenClaw already contains Telegram runtime barrels such as:

• src/plugin-sdk/telegram-runtime.ts
• src/plugin-sdk/telegram-runtime-surface.ts

But the published package installed on the host exposes only:

• ./plugin-sdk/telegram-account
• ./plugin-sdk/telegram-allow-from
• ./plugin-sdk/telegram-core
• ./plugin-sdk/telegram-surface

So third-party plugins can compile against one shape and then fail at runtime against the shipped package.

Repro

1. Install OpenClaw stable package where package.json exports omit ./plugin-sdk/telegram
2. Install [email protected]
3. Restart gateway / run openclaw doctor --non-interactive
4. Plugin fails to load with the missing-module error above

Expected

One of these should be true:

1. the published OpenClaw package restores the Telegram plugin-sdk export aliases/barrels expected by third-party plugins, or
2. release validation rejects a package build whose published exports do not match the intended plugin-sdk Telegram runtime surface

Actual

Published package lacks the export, so third-party plugin load fails at runtime.

Suggested fix

• restore/ship the Telegram plugin-sdk exports in the published package
• add a regression test that verifies expected plugin-sdk subpath exports are present in the built package manifest used for release

If useful, I can open a follow-up PR with a targeted regression test once the preferred export surface is confirmed.