Plugin install failed: codex is disabled (blocked by allowlist).

[topaz ridge]

Plugin install failed: codex is disabled (blocked by allowlist). give me the powershell to set it

[restive sonnet]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[versed stream]

Garen, first grab the version since plugin behavior has changed a bit across recent builds:

openclaw --version

Then this PowerShell appends codex to plugins.allow without wiping your existing allowlist, explicitly enables the plugin entry, validates, and restarts:

$ErrorActionPreference = "Stop"

$allow = @()
try {
  $raw = openclaw config get plugins.allow --json 2>$null
  if ($LASTEXITCODE -eq 0 -and $raw -and $raw -ne "null") {
    $allow = @($raw | ConvertFrom-Json)

[versed stream]

  }
} catch {}

$allow = @($allow + "codex" | Sort-Object -Unique)

openclaw config set plugins.allow ($allow | ConvertTo-Json -Compress) --strict-json
openclaw config set plugins.entries.codex.enabled true --strict-json
openclaw config validate
openclaw gateway restart

If it still says blocked, check whether codex is also in plugins.deny:

openclaw config get plugins.deny --json

[versed stream]

Plugin docs: https://docs.openclaw.ai/tools/plugin

[topaz ridge]

so this is what i need to set it using powershell
openclaw config set plugins.allow ($allow | ConvertTo-Json -Compress) --strict-json
openclaw config set plugins.entries.codex.enabled true --strict-json

[versed stream]

Yep, those are the two actual settings.

Just make sure $allow exists first. Minimal PowerShell version:

$allow = @("codex")
openclaw config set plugins.allow ($allow | ConvertTo-Json -Compress) --strict-json
openclaw config set plugins.entries.codex.enabled true --strict-json
openclaw config validate
openclaw gateway restart

If you already have other allowed plugins, use the longer snippet above so you append codex instead of replacing the list.

[topaz ridge]

and why it is forcing me to do this Config warnings:

• plugins.entries.amazon-bedrock: plugin not installed: amazon-bedrock — install the official external plugin with: openclaw plugins install @openclaw/amazon-bedrock-provider

[versed stream]

It’s not forcing Codex stuff. That warning means your config already has a section for plugins.entries.amazon-bedrock, but the actual Bedrock provider plugin package is not installed.

Pick one:

If you do not use Amazon Bedrock, remove the stale config entry:

openclaw config unset 'plugins.entries.amazon-bedrock'
openclaw config validate
openclaw gateway restart

If you do use Amazon Bedrock, install the plugin it’s asking for:

openclaw plugins install @openclaw/amazon-bedrock-provider

[versed stream]

openclaw config validate
openclaw gateway restart

The warning is basically: “I found config for a plugin, but I can’t load that plugin.” Bedrock docs are here: https://docs.openclaw.ai/providers/bedrock

[topaz ridge]

im seeing a lot of things show some yellow collor.. [agent/embedded] [trace:embedded-run] core-plugin-tool stages: runId=f88e0251-6028-411e-8399-f5d4ac84d265 sessionId=254e3df4-c51a-457f-bd7e-76afde88095f phase=core-plugin-tools totalMs=5915 stages=tool-policy:5275ms@5275ms,workspace-policy:0ms@5275ms,base-coding-tools:0ms@5275ms,shell-tools:0ms@5275ms,openclaw-tools:session-workspace:3ms@5278ms,openclaw-tools:image-tool:96ms@5374ms,openclaw-tools:image-generate-tool:25ms@5399ms,openclaw-tools:video-generate-tool:20ms@5419ms,openclaw-tools:music-generate-tool:0ms@5419ms,openclaw-tools:pdf-tool:0ms@5419ms,openclaw-tools:web-search-tool:0ms@5419ms,openclaw-tools:web-fetch-tool:0ms@5419ms,openclaw-tools:message-tool:5ms@5424ms,openclaw-tools:nodes-tool:0ms@5424ms,openclaw-tools:core-tool-list:1ms@5425ms,openclaw-tools:plugin-tools:486ms@5911ms,openclaw-tools:0ms@5911ms,message-provider-policy:0ms@5911ms,model-provider-policy:0ms@5911ms,authorization-policy:1ms@5912ms,schema-normalization:2ms@5914ms,tool-hooks:0ms@5914ms,abort-wrappers:0ms@5914ms,deferred-followup-descriptions:1ms@5915ms,attempt:create-openclaw-coding-tools:0ms@5915ms,attempt:tools-allow:0ms@5915ms
18:17:23 [diagnostic] liveness warning: reasons=event_loop_delay interval=31s eventLoopDelayP99Ms=71.2 eventLoopDelayMaxMs=5943.3 eventLoopUtilization=0.643 cpuCoreRatio=0.618 active=1 waiting=0 queued=1 phase=channels.telegram.start-account recentPhases=sidecars.main-session-recovery:8ms,sidecars.restart-sentinel:38ms,post-attach.update-sentinel:16ms,post-ready.maintenance:375ms,sidecars.model-prewarm:6958ms,sidecars.session-locks:6408ms work=[active=agent:main:telegram:direct:1163347802(processing,q=1,age=20s last=run:completed) queued=agent:main:telegram:direct:1163347802(processing,q=1,age=20s last=run:completed)]
18:17:25 [agent/embedded] [trace:embedded-run] prep

stages: runId=f88e0251-6028-411e-8399-f5d4ac84d265 sessionId=254e3df4-c51a-457f-bd7e-76afde88095f phase=stream-ready totalMs=10053 stages=workspace-sandbox:2ms@2ms,skills:0ms@2ms,core-plugin-tools:5915ms@5917ms,bootstrap-context:2424ms@8341ms,bundle-tools:1099ms@9440ms,system-prompt:6ms@9446ms,session-resource-loader:563ms@10009ms,agent-session:2ms@10011ms,stream-setup:42ms@10053ms
18:17:34 [fetch-timeout] fetch timeout after 10000ms (elapsed 11037ms) operation=fetchWithTimeout url=https://api.telegram.org/bot854096…VdQ4/getMe

[versed stream]

That yellow is mostly diagnostic/warning noise, not necessarily a failure.

The two lines mean different things:

• [trace:embedded-run] core-plugin-tool stages... = timing trace for building the tool list. In your paste, tool-policy:5275ms is the slow part.
• liveness warning: reasons=event_loop_delay... = the gateway noticed Node’s event loop was blocked/delayed for a bit. Your max was ~5.9s, and the recent phases mention model-prewarm / session-locks, so it may just be startup or an active Telegram agent run being heavy.

If OpenClaw is still responding, I’d treat this as “watch it” rather than panic. If you want the console less noisy, set console logging to warnings/errors only:

openclaw config set logging.consoleLevel warn
openclaw gateway restart

If it is actually hanging or messages are delayed, grab the shareable diagnostics:

[versed stream]

openclaw --version
openclaw status --all
openclaw gateway stability
openclaw logs --tail 200

Docs: https://docs.openclaw.ai/logging and https://docs.openclaw.ai/gateway/health

[versed stream]

That second line is the useful one: OpenClaw is timing out while calling Telegram’s Bot API getMe.

So this is not Codex/plugin allowlist anymore. It means the machine running the gateway can’t reliably reach https://api.telegram.org within 10s, or Telegram/API traffic is being slowed/blocked by DNS, IPv6, firewall, VPN, proxy, or VPS egress.

On that same machine, test basic reachability in PowerShell:

Test-NetConnection api.telegram.org -Port 443
Invoke-WebRequest https://api.telegram.org -UseBasicParsing

Also: avoid pasting raw Telegram URLs/log lines with /bot... in them. That can expose the bot token if it isn’t redacted.

If you’re on WSL/VPS/VPN and Telegram keeps timing out, the docs call out IPv6/proxy issues. You can try forcing the Telegram network path away from family auto-selection:

[versed stream]

openclaw config set channels.telegram.network.autoSelectFamily false --strict-json
openclaw gateway restart

If your network requires a proxy, configure channels.telegram.proxy instead. Telegram docs: https://docs.openclaw.ai/channels/telegram#polling-or-network-instability

[topaz ridge]

[ws] closed before connect conn=dba765cf-a027-4668-9c48-d99e27ab31c3 peer=127.0.0.1:49661->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://localhost:18789 host=localhost:18789 ua=n/a code=1000 reason=n/a
18:31:18 [ws] closed before connect conn=74686d08-59c5-4c73-a96e-7673111ac999 peer=127.0.0.1:49658->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://localhost:18789 host=localhost:18789 ua=n/a code=1000 reason=n/a
18:31:20 [ws] protocol mismatch conn=07ff87c7-2e66-45b6-9797-d8834627f538 remote=127.0.0.1 client=openclaw-control-ui ui v0.0.1
18:31:27 [ws] protocol mismatch conn=980ef543-9c36-43d0-b65a-66cf84dc9e78 remote=127.0.0.1 client=openclaw-control-ui ui v0.0.1
18:31:35 [ws] protocol mismatch conn=890aff4d-3c50-4b26-99ea-ab05e9ff2a8b remote=127.0.0.1 client=openclaw-control-ui ui v0.0.1

[versed stream]

That one is clearer: [ws] protocol mismatch ... client=openclaw-control-ui ui v0.0.1 means the browser Control UI and the Gateway are speaking different WebSocket protocol versions.

Most common causes:

• old dashboard tab still open after updating/restarting OpenClaw
• browser cached old Control UI assets
• running from source but dist/control-ui wasn’t rebuilt after an update

Try this first:

openclaw --version
openclaw gateway restart
openclaw dashboard

Then hard-refresh the dashboard tab, or open it in a private/incognito window.

[versed stream]

If you installed/running from a git source checkout, rebuild the UI from the OpenClaw repo:

cd path\to\openclaw
pnpm install
pnpm build
pnpm ui:build
openclaw gateway restart
openclaw dashboard

You can also run:

openclaw doctor

[versed stream]

It has a UI freshness check and may offer to rebuild when it detects the protocol mismatch. Docs: https://docs.openclaw.ai/gateway/protocol and https://docs.openclaw.ai/web/control-ui#building-the-ui

[topaz ridge]

elegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:42:50 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:42:50 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:42:51 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:42:51 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:42:52 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:42:52 [ws] protocol mismatch conn=af438401-e0e6-4449-b011-5a07eff1ebac remote=127.0.0.1 client=openclaw-control-ui ui v0.0.1

[versed stream]

This is still the Telegram init problem.

What’s happening:

• Telegram startup calls getMe to initialize bot info.
• Your previous log showed getMe timing out after 10s.
• Because init never completed, a queued/spooled Telegram update keeps retrying and hits Bot not initialized!.

So fix Telegram reachability/token first, or temporarily turn Telegram off while you fix the dashboard/UI mismatch.

Quick checks:

openclaw --version
openclaw config get channels.telegram.enabled --json
openclaw config get channels.telegram.timeoutSeconds --json
Test-NetConnection api.telegram.org -Port 443

[versed stream]

If reachability is just slow, try a longer Telegram timeout:

openclaw config set channels.telegram.timeoutSeconds 30 --strict-json
openclaw gateway restart

If you want to stop the retry spam while debugging other things:

openclaw config set channels.telegram.enabled false --strict-json
openclaw gateway restart

Then re-enable it after the network/token issue is fixed:

[versed stream]

openclaw config set channels.telegram.enabled true --strict-json
openclaw gateway restart

The [ws] protocol mismatch line is separate: that’s still stale/mismatched Control UI assets or an old browser tab, so the UI rebuild/hard-refresh advice from above still applies.

[topaz ridge]

from you make me do this openclaw config set logging.consoleLevel warn alot of things start acting up

[versed stream]

Fair. Roll that back first so we’re not debugging with changed visibility:

openclaw config unset logging.consoleLevel
openclaw gateway restart

Or set it explicitly back to normal info logging:

openclaw config set logging.consoleLevel info
openclaw gateway restart

That setting should only change what prints to the console, not Telegram/Codex/UI behavior, but I should have kept it as optional noise reduction instead of mixing it into active troubleshooting. The things you pasted after it still point to two separate underlying problems:

• Telegram: api.telegram.org/getMe timeout → bot init fails → spooled update retries.

[versed stream]

• Dashboard: ws protocol mismatch ... openclaw-control-ui ui v0.0.1 → stale/mismatched Control UI assets or old tab.

After rolling logging back, run:

openclaw --version
openclaw status --all
openclaw config validate

If you paste those outputs, we can separate what’s actually broken from what’s just log noise.

[topaz ridge]

this just keep running.. 18:58:38 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:58:38 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:58:39 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:58:39 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:58:40 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
18:58:40 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.

[versed stream]

Yep, that loop will keep going because Telegram has a queued update and the bot never finished initializing. Stop the loop first:

openclaw config set channels.telegram.enabled false --strict-json
openclaw gateway restart

If it still keeps printing after that, the gateway you’re watching is not the one that restarted, or there are two gateways running. Check/stop it:

openclaw gateway status
openclaw gateway stop
openclaw gateway status

Then start it again only after the logs stop:

[versed stream]

openclaw gateway

The underlying Telegram fix is separate: your earlier log showed api.telegram.org/.../getMe timing out. Until getMe succeeds, Telegram can’t initialize, and that queued update will keep retrying. Once you’re ready to fix Telegram, re-enable with a longer timeout and test network:

Test-NetConnection api.telegram.org -Port 443
openclaw config set channels.telegram.timeoutSeconds 30 --strict-json
openclaw config set channels.telegram.enabled true --strict-json
openclaw gateway restart

Also: the logging.consoleLevel warn setting didn’t create the Telegram failure, but rolling it back was still the right move while troubleshooting.

[topaz ridge]

19:03:10 [telegram] [diag] isolated polling ingress started spool=C:\Users\mario test.openclaw\telegram\ingress-spool-default
19:03:10 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
19:03:10 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info object.
19:03:11 [telegram] [diag] spooled update 675045132 handler failed; keeping for retry: Bot not initialized! Either call await bot.init(), or directly set the botInfo option in the Bot constructor to specify a known bot info

[versed stream]

That log gives the exact retry queue path:

C:\Users\mario test\.openclaw\telegram\ingress-spool-default

If you already disabled Telegram and it still starts, either the gateway is using a different config than you edited, or the spooled update is still being replayed on startup.

Do this in PowerShell:

openclaw gateway stop

# Move the Telegram retry spool aside instead of deleting it
Rename-Item 'C:\Users\mario test\.openclaw\telegram\ingress-spool-default' 'ingress-spool-default.disabled'

openclaw config get channels.telegram.enabled --json
openclaw gateway status

[versed stream]

openclaw gateway

If channels.telegram.enabled prints true, turn it off again before starting:

openclaw config set channels.telegram.enabled false --strict-json
openclaw gateway restart

If it prints false but Telegram still starts, run:

openclaw config file
openclaw gateway status

[versed stream]

because then you’re probably editing one config file while the running gateway service is using another. The space in mario test is fine, but keep those paths quoted in PowerShell.

[topaz ridge]

so what is the right thing to use in the powershell

[versed stream]

Use this exact PowerShell to stop the retry loop safely:

$ErrorActionPreference = "Stop"

openclaw gateway stop

openclaw config set channels.telegram.enabled false --strict-json

$spool = "C:\Users\mario test\.openclaw\telegram\ingress-spool-default"
$backup = "$spool.disabled"

if (Test-Path $spool) {
  if (Test-Path $backup) {
    $backup = "$spool.disabled.$(Get-Date -Format yyyyMMddHHmmss)"
  }

[versed stream]

  Move-Item -LiteralPath $spool -Destination $backup
  Write-Host "Moved Telegram spool to: $backup"
}

openclaw config validate
openclaw gateway restart

That disables Telegram and moves the stuck queued update aside instead of deleting it.

After the spam stops, fix Telegram network/token, then turn Telegram back on:

Test-NetConnection api.telegram.org -Port 443
openclaw config set channels.telegram.timeoutSeconds 30 --strict-json

[versed stream]

openclaw config set channels.telegram.enabled true --strict-json
openclaw gateway restart

[topaz ridge]

im finish with openclaw i spend too much time fixing it than working on my business. after every update it get crazy

[versed stream]

That’s fair, Garen. If it’s costing you business time, stepping away is a reasonable call.

For now I’d stop trying to tune it and put it in a quiet/stable state:

openclaw gateway stop

If you decide to come back later, I’d avoid updating immediately and run only a stable setup with the channels you actually need enabled. The repeated breakage you hit here looked like a mix of plugin allowlist config, stale Control UI assets, and Telegram network/spool state, which is exactly the kind of thing that burns hours.

If you want the maintainers to see the update pain, the useful path is a GitHub issue with your version and sanitized logs: https://github.com/openclaw/openclaw/issues

No pressure from me to keep wrestling it tonight.

[fickle vault]

https://discord.com/channels/1456350064065904867/1505325035047620869

[versed stream]

Yep, that linked thread is the plugin allowlist case, and it’s already marked solved for Answer Overflow.

Short version: if plugins.allow exists and is non-empty, only plugin ids in that list can be enabled/loaded. So anthropic, skill-workshop, codex, browser, etc. need to be explicitly present before openclaw plugins enable <id> will work.

Docs:
https://docs.openclaw.ai/cli/plugins
https://docs.openclaw.ai/gateway/configuration-reference

[fickle vault]

Plugins.allow is a very annoying feature.