Problem

openclaw channels add --channel discord ... (and presumably other bundled channels) registers the bundled extension directory /app/dist/extensions/discord as a user plugins.load.paths entry and an installs.json installRecords.<id>.source = "path" install. OpenClaw then warns about its own write on the very next config read:

Config warnings:
- plugins: plugin: ignored plugins.load.paths entry that points at OpenClaw's
  current bundled plugin directory; remove this redundant path or run
  openclaw doctor --fix

So channels add writes a config the loader knows is invalid and self-flags as redundant, but the writer never refuses or sanitizes the entry.

In a clean container this is "only" a noisy warning — the loader ignores the path and the gateway boots fine. In a less-clean install (existing runtime-deps mirror state, host bind mount with mismatched ownership, prior partial setup) it has appeared in user reports as plugin failed during register: ENOENT: no such file or directory, copyfile <X> -> <X> where source and destination are the same path. I have not been able to reproduce that secondary failure in a fresh container, so I'm only filing the first-order issue here.

Repro (clean, container, no prior state)

OpenClaw 2026.4.26, Docker Desktop on macOS, openclaw:local image built from main.

# Fresh isolated state
mkdir -p /tmp/oc-repro/{config,workspace}
docker run --rm --user root \
  -v /tmp/oc-repro/config:/data \
  -v /tmp/oc-repro/workspace:/work \
  openclaw:local sh -c 'chown -R 1000:1000 /data /work'

# Onboard non-interactively, no channels
docker run --rm \
  -v /tmp/oc-repro/config:/home/node/.openclaw \
  -v /tmp/oc-repro/workspace:/home/node/.openclaw/workspace \
  --entrypoint node openclaw:local dist/index.js \
  onboard --mode local --no-install-daemon --non-interactive --accept-risk \
    --skip-channels --skip-skills --skip-search --skip-ui --skip-health --skip-bootstrap \
    --auth-choice skip --gateway-auth token --gateway-token TEST_TOKEN \
    --gateway-bind loopback --gateway-port 19789

# At this point ~/.openclaw/openclaw.json has NO plugins block. Good.

# Add Discord
docker run --rm \
  -v /tmp/oc-repro/config:/home/node/.openclaw \
  -v /tmp/oc-repro/workspace:/home/node/.openclaw/workspace \
  --entrypoint node openclaw:local dist/index.js \
  channels add --channel discord --token TEST.FAKE.TOKEN

Observed

• The channels add invocation prints plugins: plugin: ignored plugins.load.paths entry that points at OpenClaw's current bundled plugin directory on its own write.
• ~/.openclaw/openclaw.json now contains:

  "plugins": {
    "entries": { "discord": { "enabled": true } },
    "load": { "paths": ["/app/dist/extensions/discord"] }
  }

• ~/.openclaw/plugins/installs.json now contains:

  "installRecords": {
    "discord": {
      "source": "path",
      "spec": "@openclaw/discord",
      "sourcePath": "./dist/extensions/discord",
      "installedAt": "..."
    }
  }

• discord is a bundled channel; this entry is exactly the redundant one the loader rejects.

Expected

channels add should detect that the channel id resolves to a bundled plugin and not write a plugins.load.paths entry or a source: "path" installRecords.<id> for it. Specifically:

• No write to plugins.load.paths for any path that lives under the running runtime's dist/extensions/.
• installRecords.<id>.source = "bundled" (or no install record at all) for ids that are already discovered as bundled plugins.

Same code path as the interactive wizard

The channels add CLI and the interactive onboard wizard both go through the same setupChannels() function. References pinned at cb9955dd5cf2e465c373f1ef99d074cdd0fbb60c:

src/wizard/setup.ts — wizard's channel step (what ./scripts/docker/setup.sh ultimately invokes when the user picks Discord during onboarding):

if (opts.skipChannels ?? opts.skipProviders) {
  await prompter.note("Skipping channel setup.", "Channels");
} else {
  const { listChannelPlugins } = await import("../channels/plugins/index.js");
  const { setupChannels } = await import("../commands/onboard-channels.js");
  // ...
  nextConfig = await setupChannels(nextConfig, runtime, prompter, { /* ... */ });
}

src/commands/channels/add.ts — the CLI used in the repro above:

const [{ buildAgentSummaries }, onboardChannels] = await Promise.all([
  import("../agents.config.js"),
  loadOnboardChannels(),
]);
// ...
let nextConfig = await onboardChannels.setupChannels(cfg, runtime, prompter, { /* ... */ });

src/commands/agents.commands.add.ts and src/commands/configure.wizard.ts reach the same setupChannels() similarly.

So users hitting Discord (bot token) during setup.sh's wizard, or running the documented channels add --channel discord --token <token> post-setup step, end up at the same writer. The CLI repro above is a faithful proxy for the wizard path.

Side observations (in case they help triage)

• openclaw doctor --fix does clear the bad plugins.load.paths entry on a fresh container — so this is not the same as #53649 / #62976. Doctor is a one-shot remediation; the underlying writer is the bug.
• Re-running channels add after doctor --fix (with the gateway up or with a second-account --name) does not re-add the path. Only the first registration of the channel triggers it.
• Effect on users: the warning recurs on every gateway start and every config read until they manually edit JSON or run doctor --fix. In docker setups with bind-mounted host dirs and stale runtime-deps mirrors, this seems to be one of the contributors to the copyfile X -> X ENOENT we've seen reported, though I couldn't isolate a clean repro of that.

Environment

• OpenClaw 2026.4.26
• Docker Desktop 4.x on macOS, openclaw:local image built from current main
• Host bind mount for ~/.openclaw
• No third-party plugins, no upgrade migration

Scope: not Docker-specific (code evidence)

I only ran the repro in Docker, but the failing code path explicitly selects the bad branch because a plugin is bundled — independent of how OpenClaw was installed.

In src/commands/onboarding-plugin-install.ts at cb9955dd5cf2e465c373f1ef99d074cdd0fbb60c:

function resolveInstallDefaultChoice(params: {
  cfg: OpenClawConfig;
  entry: OnboardingPluginInstallEntry;
  localPath?: string | null;
  bundledLocalPath?: string | null;
  hasNpmSpec: boolean;
}): InstallChoice {
  const { cfg, entry, localPath, bundledLocalPath, hasNpmSpec } = params;
  if (!hasNpmSpec) {
    return localPath ? "local" : "skip";
  }
  if (!localPath) {
    return "npm";
  }
  if (bundledLocalPath) {
    return "local";          // <-- bundled plugin always falls into the "local" branch
  }
  // ...
}

And the "local" branch then unconditionally appends to plugins.load.paths and writes a source: "path" install record:

if (choice === "local" && localPath) {
  // ...
  next = addPluginLoadPath(enableResult.config, localPath);
  next = await recordLocalPluginInstall({ cfg: next, entry, localPath, npmSpec, workspaceDir });
  // ...
}

resolveBundledLocalPath resolves the running runtime's bundled directory regardless of install method, so the bundled branch is taken on Docker, npm global, and source-tree (pnpm openclaw) the same way. Only the absolute path string written into config differs per install:

• Docker: /app/dist/extensions/discord
• npm global (Linux): /usr/lib/node_modules/openclaw/dist/extensions/discord
• npm global (macOS): ~/.npm-global/lib/node_modules/openclaw/dist/extensions/discord
• Source tree: <repo>/dist/extensions/discord

Closed issue #53649 also reported a plugins.load.paths-area problem on a non-Docker (npm global) install, which is consistent with this surface being shared.

I'm happy to add a non-Docker repro if a maintainer wants confirmation before triage, but the code path itself isn't gated on Docker.

Suggested fix area

The writer is channels add (or whatever shared registration path it goes through). Owner-boundary-wise this looks like it belongs to the channels registration code (src/channels/**) rather than extensions/discord/** since the symptom is identical for any bundled channel and is shared infrastructure. Happy to take a stab at a PR if a maintainer confirms the right seam.