Summary

• Problem: bundled plugin runtime loads in src/plugins/loader.ts still passed the loader module URL as jitiFilename, which keeps the Bun-installed image-provider hang from [Bug]: Bun global install hangs in openclaw infer image providers while loading bundled image providers #69783 reproducible on latest main.
• Why it matters: openclaw infer image providers --json can hang before any image provider registers, which makes image_generate look unavailable in Bun global installs.
• What changed: createPluginJitiLoader(...) now passes the target modulePath as jitiFilename, and a focused regression test locks that wiring in.
• What did NOT change (scope boundary): no provider-specific code, manifests, auth logic, or fallback ordering changed.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: Bun global install hangs in openclaw infer image providers while loading bundled image providers #69783
• Related [Bug]: Image Generation Failed: No image-generation provider registered for google / openai even imageGenerationModel and providers are configured. Regression version 2026.3.23 #53450
• Related [Bug]: Infinite CPU loop from jiti circular require when loading bundled plugin metadata #56946
• Related Bundled channel plugins cause stack overflow via jiti module loading #61259
• Related CLI crashes on jiti lazy getter access for bundled plugin contracts (4.7+) #63080
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: src/plugins/loader.ts called getCachedPluginJitiLoader(...) with jitiFilename: import.meta.url instead of the bundled plugin entry modulePath, so Jiti resolved bundled runtime loads relative to the loader module rather than the target plugin module.
• Missing detection / guardrail: there was no regression test asserting the jitiFilename passed by createPluginJitiLoader(...) for bundled runtime loads.
• Contributing context (if known): Bun global installs were the consistently reproducible path for the image-provider hang because that loader path was exercised while provider entrypoints themselves still imported cleanly.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/loader.jiti-filename.test.ts
• Scenario the test should lock in: a bundled plugin runtime load should pass the target bundled module path through as jitiFilename when it asks getCachedPluginJitiLoader(...) for a loader.
• Why this is the smallest reliable guardrail: the regression is one argument in the loader wiring; mocking getCachedPluginJitiLoader(...) isolates that contract without depending on a full Bun install.
• Existing test that already covers this (if any): src/plugins/jiti-loader-cache.test.ts covers cache behavior once the caller passes a filename, but it did not cover the caller wiring in src/plugins/loader.ts.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Bun-installed bundled image providers now load through the plugin runtime path with the target module path as Jiti's filename base instead of the loader module URL.

Diagram (if applicable)

Before:
[bundled plugin modulePath] -> createPluginJitiLoader -> jitiFilename=loader.ts -> Jiti resolves from loader base -> bundled image provider load can hang

After:
[bundled plugin modulePath] -> createPluginJitiLoader -> jitiFilename=modulePath -> Jiti resolves from plugin base -> bundled image provider load proceeds

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: Ubuntu 24.04.3 LTS
• Runtime/container: Node 22.22.0, Bun global install used for original repro
• Model/provider: image provider discovery path (openai bundled entrypoint was the direct import control sample)
• Integration/channel (if any): N/A
• Relevant config (redacted): provider auth present; no extra plugin-specific config required for the regression test

Steps

1. On latest main, run pnpm test src/plugins/loader.jiti-filename.test.ts.
2. Observe the new test fail before the fix because jitiFilename is file:///.../src/plugins/loader.ts instead of the bundled module path.
3. Apply the one-line loader fix and rerun the targeted plugin tests.

Expected

• Bundled runtime loads pass the bundled module path as jitiFilename.
• Targeted plugin loader tests pass.

Actual

• Before the fix, the new test failed with:
  • expected: bundled module path
  • received: file:///data/projects/openclaw/src/plugins/loader.ts
• After the fix, the targeted tests pass.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • pnpm test src/plugins/loader.jiti-filename.test.ts failed before the fix on latest main with the wrong jitiFilename.
  • pnpm test src/plugins/loader.jiti-filename.test.ts src/plugins/jiti-loader-cache.test.ts passed after the fix.
  • timeout 8s openclaw infer image providers --json still hangs in the already-installed Bun global package, confirming latest published install did not already contain this fix.
• Edge cases checked:
  • Existing cache tests still pass via src/plugins/jiti-loader-cache.test.ts.
• What you did not verify:
  • pnpm build is still red locally on latest main in scripts/stage-bundled-plugin-runtime-deps.mjs for unrelated discord runtime-deps staging (discord-api-types exact-version resolution).
  • The repository's staged check:changed hook is also red on latest main from unrelated tsgo:core errors in src/agents/pi-embedded-runner/compact.ts:887 and src/agents/pi-embedded-runner/run/attempt.ts:1132.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: another loader path may intentionally rely on import.meta.url as the Jiti filename base.
  • Mitigation: the new regression test covers the bundled runtime path specifically, and the existing cache tests still pass against the unchanged cache helper behavior.