Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from August 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.
My Gateway keeps warning that it cannot install the configured Mistral provider plugin. I do not use Mistral, and I removed every Mistral entry I could find from openclaw.json, but the missing-plugin warning still appears and the Gateway is crash-looping. Where else can an unexpected provider plugin come from?
First check whether this is a tracked plugin install or a different activation source. Run these as the same operating-system user and profile that own the Gateway service:
openclaw --version
openclaw gateway status --deep
openclaw plugins list --verbose
openclaw plugins inspect mistral --runtime --json
Do not delete plugin files or edit SQLite. If Mistral is actually present, use the plugin manager’s supported disable or uninstall path after reviewing what depends on it.
Those checks say Mistral is not installed and it is absent from the plugin inventory. The same configuration is being used by the CLI and service, but the Gateway still keeps restarting.
That rules out the initial stale-install theory. The warning can still be triggered by effective provider intent outside the visible plugin inventory. Check bounded plugin registry and Doctor output, then review one service-journal window around the crash. Avoid update repair while the process is repeatedly trying to install the unwanted provider.
The shell does not show a Mistral variable, but the service status says systemd loads a separate Gateway environment file.
That service-owned environment is the next place to check. Inspect variable names only and redact every value:
awk -F= 'tolower($0) ~ /mistral|plugin|provider|model/ { print NR ":" $1 "=<redacted>" }' GATEWAY_ENV_FILE
If it shows MISTRAL_API_KEY or another Mistral-specific activation setting that you do not use, remove only that entry from the service-owned environment through your normal configuration process, then restart and verify:
openclaw gateway restart
openclaw gateway status --deep
openclaw plugins inspect mistral --runtime --json
Do not share the environment file itself. A credential in the service environment can activate a provider even when no provider block remains in openclaw.json.
That was it. The Gateway environment contained MISTRAL_API_KEY. Removing that unused entry and restarting stopped the plugin warning and the crash loop.
That confirms the effective service environment was auto-activating the provider. Keep required provider credentials in the supported protected environment, remove only stale provider intent, and check both the interactive shell and the Gateway service whenever their behavior differs.