#[Bug] 4-7min Startup Freeze + Discord 1006 Crash on message processing (Pterodactyl/Docker)

1 messages Ā· Page 1 of 1 (latest)

sly leaf
#

Describe what you're trying to do and what's happening instead: I am facing two major stability issues after updating to OpenClaw 2026.4.26 on my server.

  1. Massive Startup Freeze: When booting the gateway, logs hang completely on [gateway] starting channels and sidecars... for 4 to 7 minutes before finally showing [gateway] ready.
  2. Crash/Timeout on Every Message: Whenever a message is sent to the bot, it gets stuck in state=processing for 200s+. This blocks the Node event loop, causing Discord heartbeats to fail and crashing the gateway with a 1006 / socket hang up error loop.

Mention your setup:

  • Hosting: Pterodactyl Panel (Docker container)
  • Node Version: v24.14.0
  • Version: OpenClaw 2026.4.26
  • Providers/Plugins used: discord, openrouter, brave and a custom MCP-like memory plugin (memory-openmemory).

What I investigated and tested (without success):

  • Versions: This behavior started precisely after upgrading from version 2026.4.15 (everything > .15 is broken for me).
  • Custom Plugins: Fully disabled my custom memory plugin (memory-openmemory). No improvement.
  • LLMs: Tested swapping primary/fallback models (Gemini vs DeepSeek vs Gemma). No improvement.
  • Cache clearing: Wiped the entire ~/.openclaw directory to ensure no state/runtime-deps pollution. No improvement.
  • Session Bloat: Pruned agents' storage from 150+ bloated JSON sessions down to 15 entries. No improvement.
  • RAG File Scan: Removed massive directories (projects/**/*.md) from the agent's memorySearch.extraPaths. No improvement.
  • IPv6 Blackhole: Attempted forcing IPv4 DNS resolution via NODE_OPTIONS. No improvement.

Relevant logs:

// 1. Startup freeze
11:45:19 [gateway] starting channels and sidecars...
11:52:48 [gateway] ready
// 2. Message crash loop
11:57:45 [diagnostic] stuck session: state=processing age=149s queueDepth=1
11:59:15 [discord] connect error: gateway request timeout for connect
11:59:15 [discord] gateway: Gateway websocket closed: 1006

Relevant openclaw.json:

{
  "gateway": {
    "port": 7009,
    "mode": "local",
    "auth": { "mode": "token", "token": "REDACTED" }
  },
  "plugins": {
    "allow": ["discord", "memory-openmemory", "brave", "openrouter"],
    "slots": { "memory": "memory-openmemory" }
  }
}
dark badgerBOT
#

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

humble sphinxBOT
#

This smells like the bundled plugin runtime-deps / channel startup path, not your custom memory plugin.

The key clue is the hang at:

[gateway] starting channels and sidecars...

On Docker/Pterodactyl, first thing Iā€™d test is moving plugin staging out of ~/.openclaw / the mounted server data dir.

Try a quick proof:

OPENCLAW_PLUGIN_STAGE_DIR=/tmp/openclaw-plugin-runtime-deps \
OPENCLAW_GATEWAY_STARTUP_TRACE=1 \
openclaw gateway run --verbose
#

If startup drops from 4ā€“7 min to normal, make that permanent with a container-local / Docker-volume path, e.g.:

OPENCLAW_PLUGIN_STAGE_DIR=/var/lib/openclaw/plugin-runtime-deps

Then run doctor with the same env:

OPENCLAW_PLUGIN_STAGE_DIR=/var/lib/openclaw/plugin-runtime-deps openclaw doctor --fix

Also isolate channels:

OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway run --verbose
sly leaf
#

Yes I did that, here is some of the .env

OPENCLAW_GATEWAY_TOKEN="KODA_DEV_TOKEN"
OPENCLAW_ALLOW_INSECURE_PRIVATE_WS="1"
OPENCLAW_NO_RESPAWN="1"
OPENCLAW_CONFIG_PATH="openclaw.json"
NODE_COMPILE_CACHE="/home/container/openclaw-compile-cache"
TMPDIR="/home/container/.tmp"
OPENCLAW_PLUGIN_STAGE_DIR="/home/container/openclaw-plugin-stage"

What is the use of OPENCLAW_GATEWAY_STARTUP_TRACE ?

I'll try with OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_GATEWAY_STARTUP_TRACE=1

humble sphinxBOT
#

OPENCLAW_GATEWAY_STARTUP_TRACE=1 is just diagnostics ā€” it doesnā€™t change behavior. It logs phase timings like:

[gateway] startup trace: sidecars.channels 1234.5ms total=...
[gateway] startup trace: channels.discord.start ...

The important bit is eventLoopMax=...ms: if thatā€™s huge, something is blocking Nodeā€™s event loop during startup.

One thing stands out: your stage dir is still under /home/container:

OPENCLAW_PLUGIN_STAGE_DIR="/home/container/openclaw-plugin-stage"
TMPDIR="/home/container/.tmp"
NODE_COMPILE_CACHE="/home/container/openclaw-compile-cache"
#

On Pterodactyl, /home/container is often the persistent mounted server volume. For the test, Iā€™d move all high-churn runtime dirs to container-local storage:

TMPDIR=/tmp \
NODE_COMPILE_CACHE=/tmp/openclaw-compile-cache \
OPENCLAW_PLUGIN_STAGE_DIR=/tmp/openclaw-plugin-stage \
OPENCLAW_GATEWAY_STARTUP_TRACE=1 \
openclaw gateway run --verbose

If thatā€™s fast, make OPENCLAW_PLUGIN_STAGE_DIR a proper Docker/Ptero volume path, not the same mounted home dir.

And yes, also try:

OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_GATEWAY_STARTUP_TRACE=1 openclaw gateway run --verbose
#

If skip-channels is fast, paste the startup trace lines around sidecars.* / channels.*.

Tiny security note: if KODA_DEV_TOKEN is a real gateway token, rotate it since it was posted publicly.

sly leaf
#

Of course not my token is not KODA_DEV_TOKEN, it's just a placeholder :p

Here is the starting log (part 1/2) :

12:39:53 [gateway] startup trace: cli.server-import 13.2ms total=13.4ms
12:39:53 [gateway] loading configurationā€¦
12:39:54 [gateway] startup trace: cli.config-load 112.2ms total=216.3ms
12:39:54 [gateway] startup trace: cli.config-snapshot 118.1ms total=340.1ms
12:39:54 [gateway] resolving authenticationā€¦
12:39:54 [gateway] startup trace: cli.auth-resolve 1.9ms total=359.1ms
12:39:54 [gateway] starting...
12:39:54 [gateway] startup trace: cli.gateway-loop 12.7ms total=371.8ms
12:39:58 [gateway] startup trace: config.snapshot.read.file 0.3ms total=3.9ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read.hash 0.2ms total=12.7ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read.parse 4.0ms total=22.8ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read.recovery-check 3.8ms total=31.1ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read.includes 0.5ms total=38.2ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read.env 1.2ms total=46.2ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read.legacy 15.8ms total=66.9ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read.plugin-install-migration 0.4ms total=71.7ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read.validate 76.8ms total=152.6ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read.materialize 0.2ms total=157.7ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read.observe 2.1ms total=164.0ms eventLoopMax=0.0ms
12:39:58 [gateway] startup trace: config.snapshot.read 167.0ms total=168.1ms eventLoopMax=0.0ms
12:40:00 [gateway] startup trace: config.snapshot.auto-enable 1541.2ms total=1713.8ms eventLoopMax=0.0ms
12:40:00 [gateway] startup trace: config.snapshot 1720.4ms total=1720.7ms eventLoopMax=0.0ms
12:40:06 [gateway] startup trace: config.auth 5876.1ms total=7603.9ms eventLoopMax=0.0ms
12:40:06 [gateway] startup trace: control-ui.seed 0.9ms total=7611.3ms eventLoopMax=0.0ms
12:40:15 [gateway] startup trace: plugins.bootstrap 9169.6ms total=16785.3ms eventLoopMax=0.0ms
12:40:15 [gateway] startup trace: plugins.lookup-table registrySnapshotMs=42.9 manifestRegistryMs=13.4 startupPlanMs=23.5 ownerMapsMs=1.0 totalMs=81.6 indexPlugins=116 manifestPlugins=116 startupPlugins=2 deferredChannelPlugins=0
12:40:15 [gateway] startup trace: runtime.config 5.8ms total=16808.9ms eventLoopMax=0.0ms
12:40:15 [gateway] startup trace: control-ui.root 7.3ms total=16826.0ms eventLoopMax=0.0ms
12:40:15 [gateway] startup trace: tls.runtime 0.8ms total=16834.7ms eventLoopMax=0.0ms
12:40:15 [gateway] starting HTTP server...
#

And part 2/2 :


12:40:15 [canvas] host mounted at http://0.0.0.0:7009/__openclaw__/canvas/ (root /home/container/.openclaw/canvas)
12:40:15 [gateway] āš ļø  Gateway is binding to a non-loopback address. Ensure authentication is configured before exposing to public networks.
12:40:15 [gateway] startup trace: runtime.state 31.5ms total=16882.3ms eventLoopMax=0.0ms
12:40:20 [gateway] startup trace: runtime.early 4590.5ms total=21488.2ms eventLoopMax=0.0ms
12:40:20 [health-monitor] started (interval: 600s, startup-grace: 60s, channel-connect-grace: 120s)
12:40:21 [gateway] startup trace: http.bound 999.2ms total=22487.4ms eventLoopMax=0.0ms
12:40:21 [gateway] startup trace: post-attach.update-sentinel 208.9ms total=22702.4ms eventLoopMax=0.0ms
12:40:21 [gateway] agent model: openrouter/google/gemini-3-flash-preview
12:40:21 [gateway] http server listening (2 plugins: discord, memory-openmemory; 27.2s)
12:40:21 [gateway] log file: /tmp/openclaw/openclaw-2026-04-28.log
12:40:22 [gateway] startup trace: post-attach.log 1327.5ms total=24034.7ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: post-attach.update-check 5.8ms total=24045.6ms eventLoopMax=0.0ms
12:40:22 [gateway] starting channels and sidecars...
12:40:22 [gateway] startup trace: sidecars.session-locks 19.2ms total=24077.4ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: sidecars.gmail-watch 0.2ms total=24082.3ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: sidecars.gmail-model 0.5ms total=24088.2ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: sidecars.internal-hooks 0.3ms total=24093.5ms eventLoopMax=0.0ms
12:40:22 [gateway/channels] skipping channel start (OPENCLAW_SKIP_CHANNELS=1 or OPENCLAW_SKIP_PROVIDERS=1)
12:40:22 [gateway] startup trace: sidecars.channels 5.6ms total=24103.7ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: sidecars.plugin-services 5.8ms total=24118.6ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: sidecars.memory 0.4ms total=24124.2ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: sidecars.restart-sentinel 25.1ms total=24155.3ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: sidecars.subagent-recovery 133.4ms total=24293.9ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: sidecars.main-session-recovery 17.7ms total=24319.8ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: sidecars.total 268.4ms total=24325.3ms eventLoopMax=0.0ms
12:40:22 [gateway] startup trace: sidecars.ready 5.3ms total=24330.6ms eventLoopMax=0.0ms
12:40:22 [gateway] ready
12:40:23 [gateway] startup trace: runtime.post-attach 1854.5ms total=24346.8ms eventLoopMax=0.0ms
12:40:23 [gateway] startup trace: ready 5.8ms total=24352.6ms eventLoopMax=0.0ms
12:40:23 [heartbeat] started
humble sphinxBOT
#

lol fair šŸ˜„

From part 1: this is not yet the scary 4ā€“7 minute freeze. Biggest chunks so far are:

config.auth       5.9s
plugins.bootstrap 9.2s

Thatā€™s slow-ish, but not fatal. Also important: every line has:

eventLoopMax=0.0ms

So in this phase the Node event loop is not blocked ā€” itā€™s mostly waiting on async work / filesystem / plugin bootstrap.

#

The useful part will be part 2, especially after:

[gateway] starting channels and sidecars...

Please paste the lines for:

runtime.post-attach
sidecars.total
sidecars.channels
sidecars.channel-start
channels.discord.start
sidecars.plugin-services
gateway ready
#

Also compare with the OPENCLAW_SKIP_CHANNELS=1 run:

  • if plugins.bootstrap is still ~9s but sidecars.* becomes fast ā†’ Discord/channel startup is the wedge.
  • if plugins.bootstrap drops when you move OPENCLAW_PLUGIN_STAGE_DIR to /tmp ā†’ stage dir/filesystem is still involved.
  • if message processing later shows huge eventLoopMax, thatā€™s separate from startup and weā€™ll chase the run path next.

For this trace so far: no smoking gun yet, but plugins.bootstrap 9169ms is worth keeping an eye on.

#

This run is the clean isolation result: with OPENCLAW_SKIP_CHANNELS=1, sidecars finish in 268ms and ready at 24.3s.

So the 4ā€“7 minute freeze is almost certainly inside channel startup, not config/session/memory:

sidecars.channels 5.6ms
sidecars.total 268.4ms

Next useful run is the same trace without OPENCLAW_SKIP_CHANNELS, ideally with the high-churn dirs on /tmp:

TMPDIR=/tmp \
NODE_COMPILE_CACHE=/tmp/openclaw-compile-cache \
OPENCLAW_PLUGIN_STAGE_DIR=/tmp/openclaw-plugin-stage \
OPENCLAW_GATEWAY_STARTUP_TRACE=1 \
# 
openclaw gateway run --verbose

Then paste the lines around:

starting channels and sidecars
sidecars.channels
sidecars.channel-start
channels.discord.start
sidecars.total
eventLoopMax

If that shows channels.discord.start taking minutes, weā€™ve narrowed it to Discord channel init. If eventLoopMax stays 0.0ms, itā€™s async waiting/I/O. If it spikes hard, something is synchronously blocking Node.

#

Also: the 0.0.0.0 warning is okay only if Pterodactyl/networking keeps it private or gateway auth is definitely enforced. Not the crash cause, just worth not ignoring.

sly leaf
#

Here you go :

12:47:54 [gateway] starting channels and sidecars...
12:47:54 [gateway] startup trace: sidecars.session-locks 18.6ms total=10160.3ms eventLoopMax=9.7ms
12:47:54 [gateway] startup trace: sidecars.gmail-watch 0.2ms total=10164.7ms eventLoopMax=0.0ms
12:47:54 [gateway] startup trace: sidecars.gmail-model 0.5ms total=10170.8ms eventLoopMax=0.0ms
12:47:54 [gateway] startup trace: sidecars.internal-hooks 0.3ms total=10175.9ms eventLoopMax=0.0ms
12:56:45 [gateway] startup trace: sidecars.channels 530638.6ms total=540818.6ms eventLoopMax=329101.9ms
12:56:45 [gateway] startup trace: sidecars.plugin-services 5.0ms total=540833.2ms eventLoopMax=0.0ms
12:56:45 [gateway] startup trace: sidecars.memory 0.3ms total=540837.8ms eventLoopMax=0.0ms
12:56:45 [gateway] startup trace: sidecars.restart-sentinel 295.8ms total=541137.6ms eventLoopMax=0.0ms
12:56:45 [gateway] startup trace: sidecars.subagent-recovery 25.7ms total=541170.8ms eventLoopMax=0.0ms
12:56:45 [gateway] startup trace: sidecars.main-session-recovery 15.6ms total=541191.9ms eventLoopMax=0.0ms
12:56:45 [gateway] startup trace: sidecars.total 531055.9ms total=541196.3ms eventLoopMax=0.0ms
12:56:45 [gateway] startup trace: sidecars.ready 4.9ms total=541201.2ms eventLoopMax=0.0ms
12:56:45 [gateway] ready
12:56:45 [gateway] startup trace: runtime.post-attach 531416.8ms total=541216.2ms eventLoopMax=0.0ms
12:56:45 [gateway] startup trace: ready 5.1ms total=541221.3ms eventLoopMax=0.0ms
12:56:45 [heartbeat] started
12:56:46 [discord] [default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
12:56:46 [discord] [default] starting provider (@Koda)
12:56:48 [discord] channels resolved: 426766430718132224/1471513645174358180 (guild:Sheer āœØ; channel:koda)
12:56:48 [discord] users resolved: 179970066777899008
12:56:50 [discord] client initialized as 1471512487328350433 (Koda); awaiting gateway readiness
container@pterodactyl~ Server marked as running...
12:56:51 [ws] ā‡„ res āœ“ exec.approval.list 985ms conn=ba4acd78ā€¦e9a1 id=42982dc5ā€¦9425
humble sphinxBOT
#

Aha, this is the smoking gun:

sidecars.channels 530638.6ms
eventLoopMax=329101.9ms

That means channel startup blocked the Node event loop for ~5.5 minutes. So the Discord 1006/heartbeat failures are probably a symptom of the same event-loop block.

Also important: Discord only starts logging after gateway ready, so the huge freeze is likely before the Discord provider is actually handed off ā€” channel runtime/bootstrap/preflight, not Discordā€™s websocket itself.

Iā€™d try updating past 2026.4.26 first. I checked the current changelog and there are 2026.4.27 fixes that sound directly related: channel startup now uses lighter runtime contexts so Discord/Telegram/Slack/etc donā€™t block on unrelated channel helper graphs, plus startup work was moved off the critical path.

So recommended next step:

# 
openclaw update --tag 2026.4.27
openclaw doctor --fix

ā€”or however you pin/update in your Pterodactyl image.

Then rerun the same trace. If it still shows sidecars.channels taking minutes, this is GitHub-issue-worthy with exactly this trace attached.

For now: donā€™t chase models/RAG/session bloat. The trace points squarely at channel startup blocking the gateway.

sly leaf
#

2026.4.27 doesn't exist ? I can't see the release on Github

humble sphinxBOT
#

Youā€™re right ā€” my bad. I checked GitHub Releases now: 2026.4.26 is the latest published release, and I donā€™t see a published 2026.4.27 there. (github.com)

I was looking at the main-branch changelog, which already has unreleased/next-release entries. That was sloppy of me.

So: donā€™t try 2026.4.27 unless you intentionally run from main/dev.

Practical next steps:

  1. For uptime: pin back to your known-good 2026.4.15.
  2. For the bug report: this trace is strong evidence:
    sidecars.channels 530638.6ms eventLoopMax=329101.9ms
    plus:
    OPENCLAW_SKIP_CHANNELS=1 ā†’ sidecars.total 268ms
sly leaf
#

Okay and if I just change my openclaw version in the package.json (and npm i ofc) will my config or .26 will break ? I should run a doctor --fix right ?

humble sphinxBOT
#

Yes ā€” that rollback path is reasonable.

If youā€™re using package.json, Iā€™d do it this way rather than only hand-editing:

npm install openclaw@2026.4.15 --save-exact
openclaw --version
openclaw doctor
openclaw doctor --fix

Then restart/rebuild the Pterodactyl server/container.

A few notes:

  • If you use npm ci, make sure package-lock.json changed too. package.json alone wonā€™t matter if the lockfile still pins .26.
  • Your config should mostly survive, but .26 may have written newer metadata/fields. If .15 warns Config was last written by a newer OpenClaw, donā€™t panic ā€” back up openclaw.json and paste the warning if it blocks startup.
#
  • Before rollback, make a quick backup of:
    cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak-2026-4-26
  • Generated runtime dirs like OPENCLAW_PLUGIN_STAGE_DIR can be rebuilt, so if the rollback still acts weird, move that stage dir aside and let doctor --fix recreate it.

Docs rollback section: https://docs.openclaw.ai/install/updating#rollback

#

Bootstrap check: I donā€™t see a recent resume file in this workspace, and the highlights file isnā€™t present, so Iā€™m reconstructing from the thread context only. If there was one important finding from earlier debugging that isnā€™t in the thread, paste it.

On your actual question: yes, rolling back to 2026.4.15 is a reasonable test, and no, I would not jump straight to openclaw doctor --fix.

My recommendation:

  1. Pin the exact older version (2026.4.15), then reinstall.
  2. Verify with:
    openclaw --version
  3. Run:
    openclaw doctor
  4. Restart the gateway.
  5. Only run:
# 
   openclaw doctor --fix

if doctor shows a concrete repair it wants to apply.

Why Iā€™m saying that: doctor --fix is more invasive and can drop unknown config keys on write. That matters more when youā€™re moving from a newer build to an older one.

One more gotcha: newer OpenClaw writes meta.lastTouchedVersion, and an older binary can block restart/start actions if it sees config written by a newer version. If that happens during the rollback, use this only for that one recovery command:

OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway restart

Also, if you have auto-update enabled, set:

# 
OPENCLAW_NO_AUTO_UPDATE=1

so it doesnā€™t quietly bump itself back up while youā€™re testing.

And honestly, your 4ā€“7 minute ā€œstarting channels and sidecarsā€¦ā€ hang smells a lot like the newer bundled plugin runtime-dependency staging path in 2026.4.26, especially on Docker/Pterodactyl if the plugin stage dir isnā€™t persisted. So after rollback, Iā€™d also check whether your container is persisting OPENCLAW_PLUGIN_STAGE_DIR / the plugin runtime deps volume.

Relevant docs:

If you want, next I can help you sanity-check the Pterodactyl volume/env setup for the plugin stage dir ā€” that feels like the most suspicious part here.

sly leaf
#

Okay, its doing it's thing, did someone else had this issue (on here or on github) ? Because it seems major

humble sphinxBOT
#

Yeah, it does seem major ā€” but I donā€™t think Iā€™ve seen this exact signature widely reported yet:

sidecars.channels 530638ms
eventLoopMax=329101ms
OPENCLAW_SKIP_CHANNELS=1 fixes startup

I searched here and GitHub-ish results. I found related ā€œstartup/channelsā€ noise, but not an exact public issue for this .26 + Docker/Pterodactyl + Discord channel startup event-loop block case. One GitHub issue has starting channels and sidecars... in logs, but itā€™s for a different exec-security bug on 2026.4.9, not this freeze. (github.com)

What I have seen recently is the same class of problem: .24/.25/.26 startup/plugin-runtime-deps/channel bootstrap weirdness, especially in Docker or mounted-volume setups. Your trace is cleaner than most because it proves the bad phase.

So Iā€™d treat this as probably not just you, but also not clearly filed yet. If rollback confirms .15 works again, please file the issue ā€” this is exactly the kind of repro maintainers need.

Also worth asking in #users-helping-users for real human ā€œsame here?ā€ datapoints. This thread has the technical evidence; that channel is better for ā€œwho else hit this?ā€ šŸ¦

GitHub
[Bug]: exec tool always uses security=deny regardless of tools.exec...

Bug type Behavior bug (incorrect output/state without crash) Beta release blocker No Summary é—®é¢˜ęčæ° exec å·„å…·ę— č®ŗ配ē½®å¦‚何都čæ”回 security=deny怂 即ä½æ tools.exec.security å·²č®¾ē½®äøŗ "full"ļ¼Œexec 调ē”Ø仍ē„¶ęŠ„错ļ¼š exec deni...

sly leaf
humble sphinxBOT
#

Perfect, thank you ā€” thatā€™s exactly the right move. šŸ¦

While youā€™re waiting, rollback to 2026.4.15 for stability. If .15 comes back clean, add that confirmation to the issue too:

Rollback to 2026.4.15 restored normal startup / no Discord 1006 loop.

That will make the regression window very clear: 2026.4.15 good ā†’ 2026.4.26 bad.