Duplicate lossless-openclaw-orchestrator plugin IDs persist after 1.5.0 install/update

[100yenadmin]

Summary

After installing/updating LCO, OpenClaw still logs duplicate lossless-openclaw-orchestrator plugin id warnings. The warning shows an explicit config-selected plugin overriding another config/global plugin source, which means the install can leave multiple LCO plugin copies discoverable and the active winner is not obvious from the operator surface.

Environment

• OpenClaw: 2026.7.1-beta.5 (b6387af)
• LCO release line: v1.5.0
• Plugin id: lossless-openclaw-orchestrator
• Observed: July 11, 2026 gateway startup/config warnings

What I observed

• The generated npm project dependency list includes lossless-openclaw-orchestrator: 1.5.0.
• Gateway startup repeatedly logged warnings in this shape:

plugins.entries.lossless-openclaw-orchestrator:
plugin lossless-openclaw-orchestrator:
duplicate plugin id resolved by explicit config-selected plugin;
config plugin will be overridden by config plugin (<repo-checkout>/dist/packages/openclaw-plugin/src/index.js)

• Earlier startup warnings also showed a global plugin copy being overridden by a config-selected plugin.
• Later warnings still showed another config-plugin source being overridden by the selected LCO checkout/build.

Local absolute paths intentionally redacted here; the important bit is that multiple plugin sources with the same id remained discoverable after the update.

Expected behavior

The LCO install/update/doctor path should make duplicate plugin identity deterministic and easy to clean up:

• Report every discovered lossless-openclaw-orchestrator source path and version.
• Mark exactly which source OpenClaw will load.
• Explain why the losing source is still discoverable.
• Provide a safe cleanup command or checklist for removing stale generated/worktree/global copies.
• Ideally, postinstall should avoid leaving duplicate plugin entries/load paths active in the first place.

Why this matters

When LCO behavior is being validated, duplicate plugin-id warnings make it unclear which build is actually running. That undermines release proof: the package can say 1.5.0, but the gateway may be selecting a local checkout or shadow copy.

Suggested acceptance tests

• Fixture an OpenClaw profile with two LCO plugin sources using the same id.
• Verify LCO doctor reports both sources, active winner, and cleanup action.
• Verify cleanup removes or disables the losing source without touching unrelated plugins.
• Verify a clean install emits no duplicate plugin-id warnings.

[coderabbitai]

🔗 Related PRs

#77 - Fix OpenClaw native tool plugin metadata [merged]
#142 - [codex] Fix OpenClaw plugin manifest version drift [merged]
#195 - Classify OpenClaw dogfood install outcomes [merged]
#697 - feat: add first-run LCO find facade [merged]
#706 - Release 1.4.5 maintenance [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[evaos-code-review-bot]

evaOS issue enrichment

Issue: #759 - Duplicate lossless-openclaw-orchestrator plugin IDs persist after 1.5.0 install/update
State: open

Related issues/PRs: none detected from issue metadata.
Existing labels: bug, enhancement, safety, protocol-drift, orchestrator.
Suggested labels: docs, tests.
Suggested owners: none.

Related context

• No same-repo issue/PR references detected in issue metadata.

Agent-start packet

Problem shape: Duplicate lossless-openclaw-orchestrator plugin IDs persist after 1.5.0 install/update - ## Summary After installing/updating LCO, OpenClaw still logs duplicate lossless-openclaw-orchestrator plugin id warnings. The warning shows an explicit config-selected plugin overriding another config/global plugin
Product fit: Implementation issue; keep product fit lightweight unless VISION.md/repo policy raises a constraint.
Implementation wedge: Prototype the candidate module behind a config flag or fixture before committing to the dependency.

Build / borrow / buy scan:

• Build: identify the smallest implementation wedge that proves the issue without broad rollout.
• Borrow: inspect same-repo prior art, repo memory, GitNexus context, and allowlisted cross-repo examples first.
• Buy/use: run capped external OSS/library/API/current-market research with citations, observed dates, and why each source matters.
• Library choice: compare maintenance, API fit, license, bundle/runtime cost, and integration proof.

Candidate sources:

• VISION.md / repo policy / repo-memory.md / GitNexus packet.
• Same-repo issues and PRs referenced by issue metadata.
• Allowlisted cross-repo GitHub examples with direct issue/PR/repo URLs.
• External OSS repositories or library/API docs with freshness dates.

Acceptance criteria:

• Preserve and execute the issue's stated acceptance criteria.
• Include source citations for any external OSS/library/current-market claims.
• Keep issue-enrichment comments sticky and idempotent.
• Keep labels, owners, reviewers, and roadmap fields suggestion-only.

Proof plan:

• Focused unit/fixture test for the changed planner behavior.
• Dry-run issue-enrichment evidence packet before live comment posting.
• Redaction check for issue body, citations, and generated markdown.
• Dependency/license/API-fit note before adding or relying on a package.

Known traps:

• Do not treat related links as proof by themselves; each source needs a reason why it matters.
• Do not scan old issue backlogs or exceed repo-level enrichment throttles.
• External research must stay capped, cited, fresh-dated, and redacted.

Non-goals:

• Do not auto-apply labels, owners, reviewers, roadmap fields, or milestones.
• Do not bulk-enrich old backlog issues from this planner output.
• Do not claim external market or OSS research was performed unless cited sources are present.

Context-source taxonomy:

• [enabled] vision_repo_policy_memory_gitnexus: Use repo vision, policy, memory, and GitNexus first before external research.
• [enabled] same_repo_issues_prs: No explicit same-repo references detected; still safe as bounded local context.
• [enabled] allowlisted_cross_repo_github: Triggered by issue class; keep to configured allowlist and source caps.
• [enabled] external_oss_examples: Use for build/borrow/buy precedent with citations and observed dates.
• [enabled] library_api_docs: Use when implementation may depend on a module, SDK, API, or framework choice.
• [deferred] current_market_examples: Deferred for implementation-only issues.
• [enabled] internal_mcp_docs: Use internal docs/MCP context when available; missing context is degraded, not blocking.

Validation suggestions

• Confirm owner, acceptance criteria, and validation evidence before implementation.

Triage gaps

• Owner or reviewer signal not detected in issue body.

No labels, owners, reviewers, or roadmap fields were changed by this bot.

[100yenadmin]

Retaining after exact-main audit at 3cd3c5b. The current OpenClaw dogfood path selects the first matching plugin but does not report every source/version, the winner/loser reason, or a safe cleanup action; no duplicate-ID fixture proves cleanup. Owner: @100yenadmin. Revisit when a duplicate-source fixture and cleanup implementation prove unrelated plugins are untouched and a clean install emits no duplicate warning.