Greptile Summary

This PR fixes three interacting bugs that caused self-built Docker images to fail to start after the channel-to-extension migration on main. The fixes are surgical and well-scoped: updating the OPENCLAW_EXTENSIONS ARG default to auto-detect all extensions, restoring the pnpm self-referencing symlink that pnpm prune --prod strips, and adding a missing tsdown build entry for the plugin runtime module.

Key changes:

• Dockerfile: OPENCLAW_EXTENSIONS now defaults to "__all__" with shell logic that also handles the empty-string override sent by docker-setup.sh — covering the root cause of the silent no-extensions build.
• Dockerfile: RUN ln -s /app /app/node_modules/openclaw restores the self-referencing package link needed for openclaw/plugin-sdk/* subpath imports after pruning.
• tsdown.config.ts: New nodeBuildConfig entry for src/plugins/runtime/index.ts → dist/runtime/index.js, so the lazy runtime resolver finds the compiled module in production where /app/src/ is absent.
• The stale # Opt-in extension dependencies header comment (line 3) is left unchanged but now contradicts the new "all by default" behaviour.

Confidence Score: 4/5

• Safe to merge — all three fixes are correct and directly address the described breakage; only minor style/documentation nits remain.
• The logic of each fix is sound: the shell condition [ -z "$OPENCLAW_EXTENSIONS" ] || [ "$OPENCLAW_EXTENSIONS" = "__all__" ] correctly handles both the docker-setup.sh empty-string override and the new sentinel; the symlink target /app is valid in the final runtime image; and the tsdown entry key "runtime/index" correctly maps to dist/runtime/index.js. The only deductions are for using ln -s instead of the idiomatic ln -sf (inconsistent with line 242) and a stale header comment, neither of which affects correctness.
• No files require special attention — both Dockerfile and tsdown.config.ts changes are straightforward and low-risk.

This is a comment left during a code review.
Path: Dockerfile
Line: 117

Comment:
**Use `ln -sf` for consistency and idempotency**

The rest of the Dockerfile uses `ln -sf` (line 242: `ln -sf /app/openclaw.mjs /usr/local/bin/openclaw`), but this line uses plain `ln -s`. While `pnpm prune --prod` currently removes the self-referencing symlink, using `-f` (force) would make this layer idempotent and guard against future `pnpm` version changes that might leave the symlink in place — causing the build to fail with "File exists".

```suggestion
RUN ln -sf /app /app/node_modules/openclaw
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: Dockerfile
Line: 3-4

Comment:
**Stale "Opt-in" header comment conflicts with new default**

The header on line 3 still says "Opt-in extension dependencies at build time", but after this PR the behaviour is the opposite — all extensions are built by default, and passing `OPENCLAW_EXTENSIONS` is now an opt-*out* mechanism to limit to a subset. The accurate description was added on lines 15–16 just before the `ARG`, so the old header is now misleading.

```suggestion
# Extension build control (space-separated directory names, or leave unset for all).
# Example: docker build --build-arg OPENCLAW_EXTENSIONS="diagnostics-otel matrix" .
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 5989881}

Similar PRs and issues
Most directly related

#48422 — duplicate/adjacent runtime-module breakage you referenced
Closest sibling bug: same breakage window, different missing runtime artifact.

#48447 — fix: mirror bundled extension deps in root package.json (#48189)
Very similar class of bug: Docker/runtime packaging misses extension dependencies, causing Cannot find package ... errors.

Root-cause / enabling PRs
These three are the strongest “similar PRs” to cite because they explain how the breakage got introduced.

#45725 — refactor: move WhatsApp channel implementation to extensions/

#45967 — refactor: remove channel shim directories, point all imports to extensions

#32223 — container builds: opt-in extension deps via OPENCLAW_EXTENSIONS build arg

Same symptom family: packaged/runtime module resolution breaks
These are very good supporting examples because they show the same pattern of extensions depending on ../../../src/... or missing packaged runtime artifacts:

#46609 — Signal plugin failed to load: Cannot find module '../../../src/infra/outbound/send-deps.js'

#47021 — Telegram plugin fails after refactor: Cannot find module '../../../src/infra/outbound/deliver.js'

#41832 — BlueBubbles plugin fails to load: Cannot find module '../../../src/infra/parse-finite-number.js'

#32662 — Nextcloud Talk failed to load: Cannot find module '../../../src/infra/abort-signal.js'

#37915 — Nextcloud Talk plugin fails to load: same abort-signal.js packaging failure

#18846 — llm-task dynamic import fails for pi-embedded-runner.js because source/dist agent entry is missing

Closing this as implemented after Codex review.

Current main already covers the reported Docker self-build/runtime failure through later plugin runtime-deps and plugin-sdk alias fixes, so this PR's Dockerfile-only workaround is obsolete on main.

What I checked:

• Bundled plugins now self-repair runtime deps during load: The plugin loader now installs bundled runtime deps for enabled bundled plugins, then either mirrors the runtime root into an external stage dir or injects a packaged openclaw/plugin-sdk/* alias under dist/extensions/node_modules/openclaw when the plugin root is writable. That removes the need for a Dockerfile-level /app/node_modules/openclaw symlink workaround. (src/plugins/loader.ts:2196, 48b9452c0795)
• Main writes packaged plugin-sdk aliases instead of relying on root symlink: ensureOpenClawPluginSdkAlias writes dist/extensions/node_modules/openclaw/package.json plus plugin-sdk/*.js wrappers, which directly addresses the packaged-install openclaw/plugin-sdk/* resolution problem raised in the PR. (src/plugins/bundled-runtime-root.ts:211, 48b9452c0795)
• Regression test covers external stage dir + plugin-sdk imports with no openclaw symlink: Current tests load a bundled plugin that imports openclaw/plugin-sdk/text-runtime from an external stage dir and explicitly assert that dist/extensions/node_modules/openclaw does not exist. That is direct evidence the old symlink-based failure mode is fixed on main. (src/plugins/loader.test.ts:1457, 48b9452c0795)
• Changelog records the packaged-install/plugin-sdk fix on main: Unreleased changelog entry: bundled plugin openclaw/plugin-sdk/* resolution was restored for packaged installs and external runtime-deps stage roots, specifically calling out the old Cannot find package 'openclaw' crash-loop after missing dependency repair. (CHANGELOG.md:104, 48b9452c0795)
• The original monorepo-only relative-import premise is no longer true for production extension code: A repo-wide search found ../../../src/... imports only in tests/test-support paths, not in shipped extension runtime code. That removes the main build/runtime premise described in the PR body.
• Docker docs still describe OPENCLAW_EXTENSIONS as optional pre-install behavior: Current docs describe OPENCLAW_EXTENSIONS as an optional build-time pre-install knob, which matches the new runtime-deps repair path rather than the PR's claim that empty/default must be treated as broken. Public docs: docs/install/docker.md. (docs/install/docker.md:121, 48b9452c0795)

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Review notes: reviewed against 4013c658537e; fix evidence: commit 48b9452c0795.