OpenClaw Unifies Streaming Config Across Telegram, Discord, and Slack — and Locks Down Its Plugin SDK Boundaries

Two significant infrastructure changes landed in OpenClaw this weekend, both targeting the kind of technical debt that slows down platform evolution. The first replaces a scattered collection of legacy streaming configuration keys with a single canonical format. The second introduces a real workspace package for the Plugin SDK, enforcing strict import boundaries that prevent extensions from reaching into internal code.

One Config Shape to Rule Them All

If you've configured streaming behavior in OpenClaw before, you may have encountered a confusing mix of flat keys: streamMode, chunkMode, blockStreaming, nativeStreaming — each with slightly different semantics depending on whether you were configuring Telegram, Discord, or Slack.

That era is over. OpenClaw now uses a single nested structure — streaming.{mode, chunkMode, block, preview} — as the canonical configuration format across all three channels. The old flat keys still work (automatic migration handles the conversion), but new documentation and tooling exclusively reference the unified shape.

Automatic Migration, Zero Downtime

Existing configurations are migrated automatically during config ingestion. The platform's doctor command has also been updated to detect and fix legacy streaming keys, so operators can verify their configs proactively. The migration preserves all existing behavior — this is a shape change, not a behavior change.

For plugin developers, a new channel-streaming subpath export from the Plugin SDK provides compatibility helpers, making it straightforward to read streaming configuration in a channel-agnostic way.

Plugin SDK Gets Real Package Boundaries

The second change addresses a long-standing architectural concern: extensions that bypass the Plugin SDK and import directly from OpenClaw's internal source tree. Previously, a root-level path alias made this technically possible — TypeScript wouldn't complain if an extension imported from ../../src/cli/acp-cli.ts, even though that violated the intended abstraction boundary.

Now, a real workspace package at @openclaw/plugin-sdk serves as a controlled declaration bridge. Extensions that opt into the new boundary enforcement (starting with xAI) are compiled under a rootDir-restricted tsconfig that makes out-of-bounds imports a hard TypeScript error — not just a convention, but a compiler-enforced guarantee.

Canary Tests Lock It In

To make sure the boundary doesn't silently degrade, the release includes contract tests that verify two things: that clean compilation works through the boundary tsconfig, and that an intentional out-of-bounds import produces the expected TypeScript error. It's a canary — if it stops failing, the boundary is broken.

Why These Changes Matter Together

Both changes serve the same strategic goal: making OpenClaw's extension surface predictable and stable. Unified streaming config means channel plugins can be written without channel-specific configuration quirks. Enforced SDK boundaries mean plugin authors can depend on a stable interface that won't break when internal code is refactored.

For the growing ecosystem of third-party OpenClaw extensions, these are the kind of invisible infrastructure improvements that make the difference between "it works on my machine" and "it works everywhere, reliably."

What You Need to Do

For most users: nothing. Both changes are backward compatible. Legacy streaming config keys are migrated automatically, and existing extensions that haven't opted into boundary enforcement continue to work as before.

Extension developers should start planning for boundary enforcement — the xAI extension is the first to adopt it, but the pattern is designed to roll out across all bundled extensions over time.