Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Plugin-backed channels can become unknown in subagent flows when OPENCLAW_STATE_DIR is relative [2 pull requests, 3 comments, 4 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#52250•Fetched 2026-04-08 01:13:43
View on GitHub
Comments
3
Participants
4
Timeline
10
Reactions
0
Author
PerfectPanPerfectPan
Participants
Hollychou924Hollychou924PerfectPanPerfectPanRyceRyceteqianteqian
Timeline (top)
commented ×3cross-referenced ×3labeled ×2closed ×1

A plugin-backed channel that is recognized before a subagent/tool-resolution path can become unknown afterward when OPENCLAW_STATE_DIR is relative.

Root Cause

Affected: users of plugin-backed channels such as feishu or custom channel plugins in subagent/spawned-agent flows with a relative state dir Severity: High in the affected flow because the channel becomes unusable Frequency: Deterministic in the attached repro Consequence: plugin-backed channels fail validation as unknown channel

Fix Action

Fixed

PR fix notes

PR #52262: fix(plugins): reuse active registry during tool resolution

Description (problem / solution / changelog)

Summary

  • add resolveEffectivePluginRegistry() as the single place that decides whether to reuse the active registry or perform a fallback plugin load
    • make tool resolution and plugin-backed provider registries share that same effective-registry logic
    • reuse the active registry only after the runtime has explicitly loaded one, while preserving the existing fallback load behavior when startup has not done that yet

Why

This fixes #52250.

In the broken path, a later tool-resolution step could reload plugins under a different state/workspace context and replace the process-global active plugin registry. After that, plugin-backed channels such as feishu could become unknown in subagent flows.

The earlier activate: false, cache: false approach avoided the overwrite, but it also rebuilt a second registry and could split stateful plugin runtime/service instances. This version fixes the same bug by converging all hot paths on a single effective-registry resolver instead.

Verification

  • pnpm exec vitest run src/plugins/runtime.test.ts src/plugins/tools.optional.test.ts src/image-generation/provider-registry.test.ts src/tts/provider-registry.test.ts src/media-understanding/providers/index.loader.test.ts src/gateway/server-methods/tools-catalog.test.ts src/agents/openclaw-tools.plugin-context.test.ts
    • on the relative-state-dir repro path, the channel remained known after tool resolution (before=true, after=true)

Changed files

  • src/image-generation/provider-registry.test.ts (added, +25/-0)
  • src/image-generation/provider-registry.ts (modified, +4/-6)
  • src/media-understanding/providers/index.loader.test.ts (added, +25/-0)
  • src/media-understanding/providers/index.ts (modified, +4/-6)
  • src/plugins/effective-registry.ts (added, +26/-0)
  • src/plugins/runtime.test.ts (modified, +9/-0)
  • src/plugins/runtime.ts (modified, +8/-0)
  • src/plugins/tools.optional.test.ts (modified, +32/-0)
  • src/plugins/tools.ts (modified, +2/-2)
  • src/tts/provider-registry.test.ts (added, +25/-0)
  • src/tts/provider-registry.ts (modified, +4/-6)

PR #52264: fix(gateway): normalize explicit state dir overrides at startup

Description (problem / solution / changelog)

Summary

  • normalize explicit OPENCLAW_STATE_DIR / CLAWDBOT_STATE_DIR overrides to absolute paths at startup
  • call the normalization from both the gateway CLI path and direct startGatewayServer() startup
  • add focused tests for path pinning and startup ordering

Why

This is a follow-up hardening change for #52250.

Relative state-dir overrides remain cwd-sensitive. Normalizing them at startup removes the trigger path before later workspace or cwd changes can retarget plugin/state discovery.

Verification

  • pnpm exec vitest run --config vitest.unit.config.ts src/config/paths.test.ts src/cli/gateway-cli/run.option-collisions.test.ts
  • validated against the same standalone repro fixture at https://github.com/PerfectPan/openclaw-repro-plugin-registry-subagent by normalizing the relative state-dir override before the later cwd change
    • before: absolute state dir, channel known
    • after: absolute state dir, channel still known

Changed files

  • src/cli/gateway-cli/run.option-collisions.test.ts (modified, +15/-0)
  • src/cli/gateway-cli/run.ts (modified, +2/-0)
  • src/config/paths.test.ts (modified, +50/-0)
  • src/config/paths.ts (modified, +12/-0)
  • src/gateway/server.impl.ts (modified, +2/-0)

Code Example

Standalone repro repo: https://github.com/PerfectPan/openclaw-repro-plugin-registry-subagent

Observed in broken path:
- `pnpm repro` -> `before.isDemoFeishuChannelKnown = true`, `after.isDemoFeishuChannelKnown = false`

Observed in control path:
- `pnpm repro:absolute-state-dir` -> `before = true`, `after = true`
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

A plugin-backed channel that is recognized before a subagent/tool-resolution path can become unknown afterward when OPENCLAW_STATE_DIR is relative.

Steps to reproduce

  • Clone https://github.com/PerfectPan/openclaw-repro-plugin-registry-subagent
  • Run pnpm install
  • Run OPENCLAW_REPO_DIR=<unfixed-openclaw-checkout> pnpm repro
  • Observe before.isDemoFeishuChannelKnown = true and after.isDemoFeishuChannelKnown = false
  • Run OPENCLAW_REPO_DIR=<same-checkout> pnpm repro:absolute-state-dir
  • Observe before = true and after = true

Expected behavior

Resolving plugin tools should not replace the active plugin registry, so the same plugin-backed channel should remain recognized after the subagent/tool-resolution path runs.

Actual behavior

In the broken repro path, the plugin-backed channel is recognized before the second plugin load and becomes unknown afterward. In the control case with an absolute state dir, the channel stays recognized.

OpenClaw version

ff6541f69d2e6cd88424953b13a43a20fa7aefb9 (dynamic repro target); current main still appears affected by source inspection at 5137a51307469721e509df011f0fbcfee1a5d21a

Operating system

macOS 26.3.1 (arm64)

Install method

local source checkout via pnpm / browser-use repro repo

Model

N/A (no model call required to reproduce)

Provider / routing chain

N/A (no provider routing required to reproduce)

Additional provider/model setup details

The reproducer uses a minimal local plugin-backed channel (demo-feishu) instead of the real feishu plugin, so no external service is required. The failure depends on a relative OPENCLAW_STATE_DIR, a later cwd change, and a second plugin load triggered by resolvePluginTools().

Logs, screenshots, and evidence

Standalone repro repo: https://github.com/PerfectPan/openclaw-repro-plugin-registry-subagent

Observed in broken path:
- `pnpm repro` -> `before.isDemoFeishuChannelKnown = true`, `after.isDemoFeishuChannelKnown = false`

Observed in control path:
- `pnpm repro:absolute-state-dir` -> `before = true`, `after = true`

Impact and severity

Affected: users of plugin-backed channels such as feishu or custom channel plugins in subagent/spawned-agent flows with a relative state dir Severity: High in the affected flow because the channel becomes unusable Frequency: Deterministic in the attached repro Consequence: plugin-backed channels fail validation as unknown channel

Additional information

This became reproducible in our setup after e6897c800bbf74d730d130ac0197a72cc9562e4d (Plugins: fix env-aware root resolution and caching, March 12, 2026). Based on current source inspection, resolvePluginTools() still calls loadOpenClawPlugins() without activate: false, and explicit relative state-dir overrides are still cwd-sensitive. A likely fix is to make tool resolution use a non-activating, non-cached plugin snapshot and to normalize explicit state-dir overrides to absolute paths early in startup.

extent analysis

Fix Plan

To resolve the issue, we need to make the following changes:

  • Modify resolvePluginTools() to use a non-activating, non-cached plugin snapshot.
  • Normalize explicit state-dir overrides to absolute paths early in startup.

Code Changes

// In resolvePluginTools()
const pluginSnapshot = loadOpenClawPlugins({ activate: false, cache: false });

// In startup code
const stateDir = path.resolve(process.cwd(), OPENCLAW_STATE_DIR);

Additionally, update the loadOpenClawPlugins() function to accept options for activation and caching:

function loadOpenClawPlugins(options = {}) {
  const { activate = true, cache = true } = options;
  // ...
}

Configuration Changes

Ensure that the OPENCLAW_STATE_DIR is set to an absolute path. If it's set relative, update the code to resolve it to an absolute path using path.resolve().

Temporary Workaround

As a temporary workaround, users can set OPENCLAW_STATE_DIR to an absolute path to avoid the issue.

Verification

To verify the fix, run the repro script with the updated code and check that the before.isDemoFeishuChannelKnown and after.isDemoFeishuChannelKnown values are both true.

Extra Tips

  • Always use absolute paths for state directories to avoid issues with relative paths.
  • Consider adding tests to ensure that plugin-backed channels remain recognized after tool resolution.

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

Resolving plugin tools should not replace the active plugin registry, so the same plugin-backed channel should remain recognized after the subagent/tool-resolution path runs.

#installation#tensor shape#autograd error#model save/load#optimization

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]: Plugin-backed channels can become unknown in subagent flows when OPENCLAW_STATE_DIR is relative [2 pull requests, 3 comments, 4 participants]