Installing OpenClaw and picking Feishu as a messaging channel currently crashes onboarding with Error: Cannot find module '@larksuiteoapi/node-sdk'. The plugin loader tries to import the Lark SDK from the Feishu extension directory, the file isn't there, and the process exits before you can paste your app ID and secret. The same failure has resurfaced across multiple releases in the 2026.2.x, 2026.3.x, and 2026.4.x lines on Windows, macOS, and Linux.
Quick answer: Downgrade to a known-good build with npm uninstall -g openclaw followed by npm install -g openclaw@2026.4.15, then rerun openclaw onboard.
Why the Feishu plugin fails to load
The Feishu channel extension lives at extensions/feishu/ inside the OpenClaw install and declares @larksuiteoapi/node-sdk as a runtime dependency. The root package removed that SDK from its own dependency list as part of a cleanup PR, and later the bundler began marking it as an external, unbundled dependency. When npm publishes the tarball, the plugin's node_modules aren't packed alongside it, so the module is missing on disk after a global install.
The result is a consistent stack trace during onboarding:
[plugins] feishu failed to load from /usr/lib/node_modules/openclaw/extensions/feishu/index.ts: Error: Cannot find module '@larksuiteoapi/node-sdk'
Require stack:
- /usr/lib/node_modules/openclaw/extensions/feishu/src/client.ts
Typical failure during openclaw onboard
Under pnpm, the same error points into the flattened store path, for example .pnpm/openclaw@2026.4.20.../openclaw/dist/extensions/feishu/client-yWGpoGkZ.js. The cause is identical: the Lark SDK was never installed next to the plugin entry.
Affected versions
The defect has reappeared across several releases. Builds published between the fixes tend to work; regressions land when packaging or dependency changes ship without restoring the plugin's install step.
| OpenClaw version | Feishu onboarding status |
|---|---|
| 2.14 and earlier | Works |
| 2026.2.21-2 | Broken (SDK removed from root deps) |
| 2026.2.26 | Works (minimum version for the official Lark plugin) |
| 2026.3.7 | Broken during onboard |
| 2026.3.8 | Broken; WebSocket config also missing |
| 2026.4.15 | Works (community-confirmed rollback target) |
| 2026.4.20 / 2026.4.21 | Broken; additional modules also missing |
Fix 1: Downgrade to a working build
The fastest way out is reverting to a release where the plugin tarball still includes its dependencies. 2026.4.15 is the most widely confirmed rollback target on Linux and macOS.
Step 1: Remove the broken global install. Run npm uninstall -g openclaw. If you originally installed with pnpm, use pnpm uninstall -g openclaw instead so the package manager cleans its own store.
Step 2: Install the pinned version. Run npm install -g openclaw@2026.4.15. The pnpm equivalent is pnpm install -g openclaw@2026.4.15. Wait for the install to finish without errors.
Step 3: Verify and rerun onboarding. Confirm the version with openclaw -v, then launch openclaw onboard. Pick your model, select Feishu as the channel, and paste your app ID and secret. You know it worked when the onboarding wizard advances past the plugin install step without throwing the module error and the next prompt appears.
Fix 2: Install the missing SDK globally
If you must stay on the latest build, install the Lark SDK yourself so Node can resolve the import. This is the documented workaround for the packaging bug.
Step 1: Install the SDK globally. Run npm install -g @larksuiteoapi/node-sdk. On Windows, run the terminal as Administrator; on macOS and Linux, use sudo only if your npm prefix requires it.
Step 2: Restart onboarding. Run openclaw onboard again and proceed to the Feishu channel step. The Lark SDK error should no longer appear.
Step 3: Handle the next missing module. On recent builds the bundler marks roughly two dozen dependencies as external, so the next crash may name nostr-tools, zca-js, openai, or packages under @twurple, @opentelemetry, or @tloncorp. Install each one with npm install -g <package> and relaunch onboarding until the wizard completes.
This path works but is tedious. Every missing module surfaces only after the previous one is resolved, so expect several cycles of install-and-retry.
Fix 3: Manually install the plugin's dependencies
If global installs conflict with your Node setup, install the SDK directly into the plugin directory. OpenClaw extracts the Feishu extension to a predictable path per user.
Step 1: Locate the plugin. On Linux and macOS the user-level install is ~/.openclaw/extensions/feishu. A root install may land at /usr/lib/node_modules/openclaw/extensions/feishu. On Windows, check %APPDATA%\npm\node_modules\openclaw\extensions\feishu.
Step 2: Install the SDK inside that folder. Change into the directory and run npm install @larksuiteoapi/node-sdk. This populates the plugin's own node_modules so the local require resolves.
Step 3: Rerun onboarding. Launch openclaw onboard and continue past the Feishu step. If the plugin loader still reports it as untrusted, add feishu to plugins.allow in your openclaw.json so it auto-loads on start.
Fix 4: Use the official Lark/Feishu plugin
The Lark/Feishu Open Platform team maintains a separate plugin that replaces the bundled Feishu extension. It targets OpenClaw 2026.2.26 or newer and requires Node.js v22 or higher. Switching to it avoids the bundled plugin's packaging bug entirely and adds richer integrations for messages, docs, bases, sheets, calendar, and tasks.
You can find the project at github.com/larksuite/openclaw-lark. Install it through the OpenClaw plugin system, disable the built-in Feishu plugin with plugins.entries.feishu.enabled = false, and configure the Lark plugin instead. If you're on the international Lark domain (open.larksuite.com) rather than the Chinese Feishu domain, set channels.feishu.brand to "lark" so the client targets the correct endpoint; a misrouted domain is what produces the misleading code: 1000040351, system busy error.
Environment prerequisites
None of the fixes will stick if your Node.js is too old. The OpenClaw CLI explicitly requires Node.js v22.12 or newer and will refuse to start otherwise, printing a version error on stderr. Verify your environment before installing anything:
node -v
npm -v
git --version
Check required toolchain versions
If node -v returns anything below v22.12, upgrade with nvm install 22 && nvm use 22 on macOS and Linux, or install the current LTS build from nodejs.org on Windows. Reopen your terminal after upgrading so the new binary is on PATH.
Windows and WSL2 notes
Windows installs run into the same missing-module failure as Linux, plus occasional PATH and permission issues. Running the shell as Administrator helps global npm installs succeed, but it also grants OpenClaw broader filesystem access, which carries its own risks. A WSL2 Ubuntu environment sidesteps both problems: installs are more reliable there, and you can keep OpenClaw isolated from your Windows user profile. If you go the WSL route, install Node.js v22+ inside the Linux environment and run the same npm install -g openclaw@2026.4.15 downgrade to avoid the packaging regression.
Verifying the Feishu channel is live
After onboarding completes, confirm the plugin actually loaded rather than assuming success:
| Command | Expected result |
|---|---|
openclaw -v | Prints the installed version, for example 2026.4.15 |
openclaw channels list | Lists feishu as an enabled channel |
openclaw gateway start | Gateway starts without repeated Cannot find module errors |
openclaw status | Shows the gateway and Feishu channel as running |
If the gateway logs still report the Lark SDK error, the dependency fix didn't land in the path Node is actually resolving. Check that the plugin directory you installed into matches the one printed in the error's Require stack, then repeat the install in that exact location.
When a new release appears
Because this regression has returned multiple times, treat each OpenClaw upgrade as potentially breaking for the Feishu channel. Before running npm install -g openclaw@latest, check the changelog for entries referencing the Feishu plugin, the Lark SDK, or plugin packaging. If none are present, hold on your current working version until the next patch, or keep a pinned install command ready so you can roll back quickly. The underlying packaging problem, where workspace plugin dependencies aren't bundled into the global tarball, needs a build-system change to stay fixed; until that lands, manual mitigation is the reliable path.