OpenClaw Deep Dive (4): Plugin SDK and Extension Development

Scenario: A Third-Party Contributor Wants to Add Zalo Suppose you're a Vietnamese developer who wants to connect OpenClaw to Zalo — Vietnam's largest instant messaging platform. The core already ships Telegram, Discord, Slack... but not Zalo. You have two paths: Submit a PR to the main repo , wait for review and merge, then forever track OpenClaw's release cadence every time the Zalo API changes. Write a standalone extension package , publish it locally or to npm, and let anyone openclaw install it on demand. The second path requires OpenClaw's core to provide a stable extension contract — no matter whether contributors use TypeScript or JavaScript, whether they publish .ts sources or compiled .js output, the core must correctly load, isolate, and run them. And if an extension crashes, the core must not go down with it. This is the problem the Plugin SDK must solve. 1. Stable Contract: openclaw/plugin-sdk Why a fixed import path? If extensions do import { ... } from "../../src/plugins/