Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Bun global install hangs in openclaw infer image providers while loading bundled image providers [3 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#69783•Fetched 2026-04-22 07:48:21
View on GitHub
Comments
2
Participants
3
Timeline
2
Reactions
0
Author
yidianyikoyidianyiko
Participants
dengluozhangdengluozhangrafiki270rafiki270yidianyikoyidianyiko
Timeline (top)
commented ×2

openclaw infer image providers --json hangs indefinitely in a Bun global install of OpenClaw 2026.4.15 even though the bundled image-provider entrypoints can be imported directly.

Root Cause

openclaw infer image providers --json hangs indefinitely in a Bun global install of OpenClaw 2026.4.15 even though the bundled image-provider entrypoints can be imported directly.

PR fix notes

PR #70073: fix(plugins): use module path for bundled jiti loads

Description (problem / solution / changelog)

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 #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 #69783
  • Related #53450
  • Related #56946
  • Related #61259
  • Related #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.

Changed files

  • src/plugins/loader.jiti-filename.test.ts (added, +99/-0)
  • src/plugins/loader.ts (modified, +1/-1)

PR #70080: fix(bun): use modulePath for jitiFilename in bundled plugin loader (#69783)

Description (problem / solution / changelog)

Fixes #69783 — In Bun global install, import.meta.url in bundled plugins points to a cached path instead of the actual module path, causing jiti loader to hang. Changed to use modulePath parameter instead.

Changed files

  • extensions/browser/src/browser/pw-session.test.ts (modified, +75/-0)
  • extensions/browser/src/browser/pw-session.ts (modified, +65/-0)
  • extensions/browser/src/browser/pw-tools-core.browser-ssrf-guard.test.ts (modified, +1/-0)
  • extensions/browser/src/browser/pw-tools-core.snapshot.ts (modified, +10/-1)
  • extensions/telegram/src/bot-message-context.body.ts (modified, +10/-1)
  • extensions/whatsapp/src/auto-reply.web-auto-reply.last-route.test.ts (modified, +109/-0)
  • extensions/whatsapp/src/auto-reply/monitor/on-message.ts (modified, +6/-0)
  • src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.custom-provider-payloads.test.ts (added, +113/-0)
  • src/agents/pi-embedded-subscribe.ts (modified, +5/-3)
  • src/agents/sandbox/remote-fs-bridge.test.ts (modified, +57/-0)
  • src/agents/sandbox/remote-fs-bridge.ts (modified, +16/-2)
  • src/infra/system-events.test.ts (modified, +31/-0)
  • src/infra/system-events.ts (modified, +6/-1)
  • src/plugins/bundled-capability-runtime.ts (modified, +1/-1)
  • src/plugins/bundled-channel-config-metadata.ts (modified, +1/-1)
  • src/plugins/loader.ts (modified, +1/-1)
  • src/plugins/public-surface-loader.ts (modified, +2/-2)
  • src/plugins/source-loader.ts (modified, +1/-1)
  • src/tasks/task-registry.audit.test.ts (modified, +77/-0)
  • src/tasks/task-registry.ts (modified, +7/-4)

PR #69893: fix: multiple bundled plugin and channel regression fixes

Description (problem / solution / changelog)

Multiple regression fixes for bundled plugins and channel plugins.

Fixes included:

  • #69793: Telegram photo inbound media type classification
  • #69783: Bun global install hang (jitiFilename modulePath fix)
  • #69831: Telegram grammy version mismatch (staging skip + bundledDependencies)
  • #70025: Feishu @larksuiteoapi/node-sdk missing bundledDependencies
  • #70026: SIGTERM instead of SIGKILL for supervisor cleanup
  • #69478: Deduplicate enqueued system events
  • #69229: Task createdAt/startAt timestamp clamping
  • #69410: AssistantTexts populated at message_end
  • #69369: Docker binds in RemoteShellSandboxFsBridge
  • #69289: Resolve ax refs in browser actions

Changed files

  • extensions/browser/src/browser/pw-session.test.ts (modified, +75/-0)
  • extensions/browser/src/browser/pw-session.ts (modified, +65/-0)
  • extensions/browser/src/browser/pw-tools-core.browser-ssrf-guard.test.ts (modified, +1/-0)
  • extensions/browser/src/browser/pw-tools-core.snapshot.ts (modified, +10/-1)
  • extensions/feishu/package.json (modified, +3/-0)
  • extensions/telegram/package.json (modified, +4/-1)
  • extensions/telegram/src/bot-message-context.body.ts (modified, +10/-1)
  • extensions/whatsapp/src/auto-reply.web-auto-reply.last-route.test.ts (modified, +109/-0)
  • extensions/whatsapp/src/auto-reply/monitor/on-message.ts (modified, +6/-0)
  • src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.custom-provider-payloads.test.ts (added, +113/-0)
  • src/agents/pi-embedded-subscribe.ts (modified, +5/-3)
  • src/agents/sandbox/remote-fs-bridge.test.ts (modified, +57/-0)
  • src/agents/sandbox/remote-fs-bridge.ts (modified, +16/-2)
  • src/infra/system-events.test.ts (modified, +31/-0)
  • src/infra/system-events.ts (modified, +6/-1)
  • src/plugins/bundled-capability-runtime.ts (modified, +1/-1)
  • src/plugins/bundled-channel-config-metadata.ts (modified, +1/-1)
  • src/plugins/loader.ts (modified, +1/-1)
  • src/plugins/public-surface-loader.ts (modified, +2/-2)
  • src/plugins/source-loader.ts (modified, +1/-1)
  • src/process/supervisor/supervisor.ts (modified, +1/-1)
  • src/tasks/task-registry.audit.test.ts (modified, +77/-0)
  • src/tasks/task-registry.ts (modified, +7/-4)

Code Example

$ openclaw --version
OpenClaw 2026.4.15 (041266a)

$ timeout 8s openclaw infer image providers --json; echo EXIT_CODE:$?
EXIT_CODE:124

$ node --input-type=module -e "const mod = await import('/home/.../.bun/install/global/node_modules/openclaw/dist/extensions/openai/index.js'); console.log(Object.keys(mod)); console.log(typeof mod.default);"
[ 'default' ]
object
RAW_BUFFERClick to expand / collapse

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

openclaw infer image providers --json hangs indefinitely in a Bun global install of OpenClaw 2026.4.15 even though the bundled image-provider entrypoints can be imported directly.

Steps to reproduce

  1. Install [email protected] globally with Bun.
  2. Run openclaw infer image providers --json on Ubuntu 24.04.3 LTS.
  3. Observe that the command does not print JSON or exit.
  4. Wrap the same command in timeout 8s ... and observe exit code 124.
  5. In the same install, import the bundled OpenAI image provider entrypoint directly with Node and observe that it loads successfully.

Expected behavior

Per docs/cli/infer.md and docs/tools/image-generation.md, openclaw infer image providers --json should return a JSON list of discovered image-generation providers instead of hanging.

Actual behavior

The command hangs indefinitely.

In the same install:

  • openclaw infer model auth status --json returns normally.
  • Direct native import of the bundled provider entrypoint returns normally.
  • The failure only appears when bundled image providers are resolved through the runtime plugin-loader path.

OpenClaw version

2026.4.15 (041266a)

Operating system

Ubuntu 24.04.3 LTS

Install method

Bun global install (bun add -g openclaw)

Model

NOT_ENOUGH_INFO

Provider / routing chain

openclaw CLI -> bundled plugin loader -> bundled image provider entrypoints

Additional provider/model setup details

openclaw infer model auth status --json returned normally in the same install.

GEMINI_API_KEY was present in the environment during the repro.

No image generation request reached an upstream provider in this repro path.

Logs, screenshots, and evidence

$ openclaw --version
OpenClaw 2026.4.15 (041266a)

$ timeout 8s openclaw infer image providers --json; echo EXIT_CODE:$?
EXIT_CODE:124

$ node --input-type=module -e "const mod = await import('/home/.../.bun/install/global/node_modules/openclaw/dist/extensions/openai/index.js'); console.log(Object.keys(mod)); console.log(typeof mod.default);"
[ 'default' ]
object

Local code inspection shows src/plugins/loader.ts:434 through src/plugins/loader.ts:439 passes jitiFilename: import.meta.url into getCachedPluginJitiLoader(...) for bundled plugin loads.

During local debugging, changing only that argument to jitiFilename: modulePath allowed the same installed bundled image-provider module to load immediately in the same environment.

Impact and severity

Affected: Bun global installs that need image provider discovery or image_generate

Severity: High (blocks image tool availability)

Frequency: Every observed run on this install

Consequence: openclaw infer image providers hangs and image-generation tooling appears unavailable

Additional information

This appears to be in the Jiti / bundled-plugin-loader path rather than in a specific image provider implementation.

Related issue family, but different symptom/repro: #53450, #56946, #61259, #63080.

I also inspected the published [email protected] package locally and found the compiled loader still contains jitiFilename: import.meta.url, so the latest beta may still be affected.

extent analysis

TL;DR

The issue can likely be fixed by changing the jitiFilename argument in getCachedPluginJitiLoader to use modulePath instead of import.meta.url for bundled plugin loads.

Guidance

  • The problem seems to be related to how the bundled plugin loader handles the jitiFilename argument, specifically when using import.meta.url.
  • To verify the issue, run the command openclaw infer image providers --json and observe if it hangs indefinitely.
  • To mitigate the issue, try changing the jitiFilename argument to modulePath in the getCachedPluginJitiLoader function, as done during local debugging.
  • The fact that the issue is not present when importing the bundled image provider entrypoint directly with Node suggests that the problem is specific to the plugin loader path.

Example

No code snippet is provided as the issue is related to a specific implementation detail in the OpenClaw codebase.

Notes

The issue appears to be specific to Bun global installs and the bundled plugin loader path. The problem may still be present in the latest beta version of OpenClaw.

Recommendation

Apply workaround: Change the jitiFilename argument to modulePath in the getCachedPluginJitiLoader function to fix the issue. This change allowed the bundled image-provider module to load immediately during local debugging.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Per docs/cli/infer.md and docs/tools/image-generation.md, openclaw infer image providers --json should return a JSON list of discovered image-generation providers instead of hanging.

#api#batch processing#GPU compatibility#latency issue#model loading

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Bun global install hangs in openclaw infer image providers while loading bundled image providers [3 pull requests, 2 comments, 3 participants]