Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After Mattermost was externalized in 2026.6.11, the configured-plugin repair can install @openclaw/mattermost but does not explicitly enable the external plugin, so gateway startup still omits Mattermost.

Steps to reproduce

1. Start a fresh 2026.6.10 OpenClaw container with channels.mattermost.enabled=true, baseUrl=http://mattermost:8065, and the bot token supplied by env SecretRef.
2. Verify 2026.6.10 loads Mattermost and connects.
3. Replace the OpenClaw container with ghcr.io/openclaw/openclaw:2026.6.11, preserving the same state/config.
4. Run openclaw doctor --fix --non-interactive inside the 2026.6.11 container.
5. Restart the 2026.6.11 gateway.

Expected behavior

Doctor should leave the repaired externalized Mattermost plugin in a state that the gateway can start. After repair and restart, gateway startup should include Mattermost and connect to the configured Mattermost bot.

Actual behavior

Doctor reports:

Installed missing configured plugin "mattermost" from @openclaw/mattermost.

But after restarting the same 2026.6.11 container, gateway startup still logs only the built-in plugin set and omits Mattermost:

[gateway] http server listening (7 plugins: browser, canvas, device-pair, file-transfer, memory-core, phone-control, talk-voice; ...)
[gateway] starting channels and sidecars...
[gateway] ready

openclaw message send --channel mattermost ... can load the installed plugin from the CLI path, but the gateway does not start it until the explicit activation bit is added:

openclaw config set plugins.entries.mattermost.enabled true --strict-json

After setting that and restarting 2026.6.11, the gateway loads Mattermost and connects:

[gateway] http server listening (8 plugins: browser, canvas, device-pair, file-transfer, mattermost, memory-core, phone-control, talk-voice; ...)
[mattermost] [default] starting channel
[mattermost] connected as @test

OpenClaw version

2026.6.10 -> 2026.6.11

Operating system

Docker container on a local Docker host; Mattermost was another container on the same Docker network.

Install method

docker / container image replacement

Model

llamacpp/qwen3.6-mtp-gguf

Provider / routing chain

OpenClaw -> local llama.cpp OpenAI-completions-compatible endpoint

Additional provider/model setup details

The model was only needed to prove inbound Mattermost replies on 2026.6.10. The activation failure is independent of model output because gateway startup never loads the Mattermost channel plugin.

Logs

# 2026.6.10 baseline
[gateway] http server listening (8 plugins: browser, canvas, device-pair, file-transfer, mattermost, memory-core, phone-control, talk-voice; ...)
[mattermost] [default] starting channel
[mattermost] connected as @test

# 2026.6.11 after doctor --fix and restart
[gateway] http server listening (7 plugins: browser, canvas, device-pair, file-transfer, memory-core, phone-control, talk-voice; ...)
[gateway] starting channels and sidecars...
[gateway] ready

# 2026.6.11 after manual activation and restart
[gateway] http server listening (8 plugins: browser, canvas, device-pair, file-transfer, mattermost, memory-core, phone-control, talk-voice; ...)
[mattermost] [default] starting channel
[mattermost] connected as @test

Screenshots, recordings, and evidence

Observed live against a Mattermost 11.8.2 container using a redacted bot token. 2026.6.10 could send outbound Mattermost messages and received/replied to an inbound Mattermost post. The same state on 2026.6.11 omitted Mattermost until plugins.entries.mattermost.enabled=true was set.

Relevant source evidence:

• package.json:115 excludes dist/extensions/mattermost/** from the 2026.6.11 package.
• extensions/mattermost/package.json:40 declares @openclaw/mattermost install metadata and bundledDist=false.
• src/plugins/gateway-startup-plugin-ids.ts:1815 gates configured channel plugins for gateway startup.
• src/plugins/gateway-startup-plugin-ids.ts:1861 requires non-bundled channel plugins to be explicitly enabled.
• src/plugins/config-activation-shared.ts:107 treats plugins.entries.<id>.enabled=true as explicit selection.
• src/commands/doctor/repair-sequencing.ts:122 has the config repair path that materializes repaired plugin ids.
• src/config/plugin-auto-enable.shared.ts:908 writes plugins.entries.<id>.enabled=true for non-built-in plugin auto-enable candidates.

Impact and severity

Affected: users with configured Mattermost channels upgrading from a bundled Mattermost release to 2026.6.11.

Severity: High. The gateway starts successfully but silently omits the channel, so Mattermost inbound messages are not consumed and outbound channel sends fail.

Frequency: Always in the observed 2026.6.10 -> 2026.6.11 container repro until plugins.entries.mattermost.enabled=true is added.

Consequence: Missed Mattermost messages and no bot replies after upgrade.

Additional information

The likely fix is for configured-plugin repair/update migration to materialize explicit activation for repaired externalized configured channels, e.g. plugins.entries.mattermost.enabled=true or the equivalent current activation contract. Installing the package alone is insufficient for gateway startup.