#How should I create this workflow ? Reseach from E-mail/Web > Analyze > Report > Send

1 messages · Page 1 of 1 (latest)

rain jungle
#

I notice that OpenClaw got a lot of upgrade recently in workflow, tools, and skills, it can do natively unlike before. What are the things I need to do step by step to reproduce this workflow ?

  1. Research
  2. Analyze
  3. Report (powerpoint/PDF)
  4. Send Email/Discord
still tokenBOT
#

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

humble kite
rain jungle
#

Not yet

humble kite
#

You’d basically chain it like: input → research agent (fetch data) → analysis agent → report generator (PDF/PPT) → then a send step (email/Discord). The key is passing clean outputs between each step.

If you want, I can walk you through setting it up or help you build it out properly @rain jungle

rain jungle
#

That would be very helpful

humble kite
#

Yeah that repo is basically a full version of what I was describing it’s a multi-stage pipeline, not just one workflow.

#

You can either plug it directly into OpenClaw and run it, or build a simpler version step-by-step (research → analysis → report → send).

#

If you want, I can help you set up a clean version of this inside OpenClaw so it actually works reliably 👍

rain jungle
#

Can you teach me?

rain jungle
#

@daring geyser notice that OpenClaw got a lot of upgrade recently in workflow, tools, and skills, it can do natively unlike before. What are the things I need to do step by step to reproduce this workflow ?
Research
Analyze
Report (powerpoint/PDF)
Send Email/Discord

daring geyserBOT
#

Yep — the clean pattern is:

trigger → research tools → analysis → file generation → human-approved delivery

I’d build it like this:

1. Verify you’re on a recent OpenClaw

openclaw --version
openclaw status
openclaw doctor

If something is weird, share openclaw --version first.

Docs: https://docs.openclaw.ai/start/getting-started

#

2. Enable the core tools you need

For this workflow you usually want:

  • web_search / web_fetch — web research
  • browser — JS-heavy sites, logged-in sites, screenshots/PDF export
  • read / write / exec — create report files
  • pdf — analyze PDFs
  • message — send to Discord/Slack/etc.
  • cron or webhooks — automation

Configure web search:

#

3. Connect Discord delivery

Use your own/private Discord server, not the public OpenClaw server.

Follow the Discord setup guide, then send reports to a target like:

channel:<discord_channel_id>

Docs: https://docs.openclaw.ai/channels/discord


4. For email input/output

#

Important nuance: Discord delivery is native. Email sending is not something I’d treat as “fire and forget.”

Recommended safe setup:

  • For email as a trigger/input: use Gmail PubSub/webhooks.
  • For email output: have OpenClaw draft the email first, then require approval before sending through your chosen Gmail/SMTP/API/MCP integration.

Gmail trigger setup:

openclaw webhooks gmail setup --account you@example.com

Docs: https://docs.openclaw.ai/automation/cron-jobs#gmail-pubsub-integration


#

5. Create a reusable workflow skill

Create:

mkdir -p ~/.openclaw/skills/research-report-workflow
nano ~/.openclaw/skills/research-report-workflow/SKILL.md

Example SKILL.md:

---
name: research-report-workflow
description: Research a topic, analyze findings, generate a report, and deliver it with approval.
---
#

Workflow:

1. Clarify the topic, audience, deadline, and output format.
2. Research using web_search/web_fetch/browser.
3. Keep a source list with URLs, dates, and short notes.
4. Analyze findings:
   - summarize key points
   - compare sources
   - identify risks/uncertainties
   - produce recommendations
5. Create artifacts in the workspace:
   - report.md
   - report.pdf when requested
   - report.pptx when requested and a renderer is available
#
6. Verify files exist before delivery.
7. For Discord: send only to an explicit channel/user target.
8. For email: draft first and ask for approval before sending externally.

Docs: https://docs.openclaw.ai/tools/skills


6. Run it manually first

Example prompt to your agent:

Use the research-report-workflow skill.
#

Research the current AI browser automation market.
Analyze competitors, pricing, strengths, weaknesses, and opportunities.
Create a PDF report and a short executive summary.
Send the PDF to Discord channel:<CHANNEL_ID>.
Draft an email version, but ask me before sending.

For PowerPoint, ask it to use an installed renderer such as Marp, PptxGenJS, or python-pptx. OpenClaw can orchestrate that via tools, but PowerPoint generation is usually a local dependency/workflow, not a single magic built-in.


7. Automate it with cron

Example weekly report:

#
openclaw cron add \
  --name "Weekly research report" \
  --cron "0 9 * * 1" \
  --tz "America/New_York" \
  --session isolated \
  --message "Use research-report-workflow. Research this week's AI agent tooling news, analyze major changes, create a PDF report, and send it to Discord channel:<CHANNEL_ID>." \
  --announce \
  --channel discord \
  --to "channel:<CHANNEL_ID>"

Test it:

openclaw cron list
#
  1. PowerPoint generation
  2. Email draft/send approval
  3. Gmail-triggered automation
  4. Multi-agent/subagent research for bigger reports

That keeps the workflow debuggable instead of turning it into a giant mystery box on day one. 🦐

rain jungle
#

OpenClaw 2026.4.24 (cbcfdf6). My gateway is reachable but Discord is broken at this point. I already filed a bug report.

daring geyserBOT
#

Got it — since Gateway is reachable but Discord is broken, I’d separate the workflow from the delivery channel for now.

Do this next

  1. Attach clean Discord diagnostics to the bug report
openclaw status --all
openclaw channels status --probe
openclaw pairing list discord
openclaw logs --follow

status --all is the best pasteable one; it should redact secrets.

Docs: https://docs.openclaw.ai/channels/troubleshooting

#
  1. Build/test the workflow through Control UI/WebChat first

Use the workflow without Discord:

Research this topic from web sources, analyze it, create report.md and report.pdf in the workspace. Do not send externally yet.

That verifies research/analyze/report independent of Discord.

  1. Use another working channel temporarily

If Telegram/Slack/WebChat works, send the final artifact there until Discord is fixed. For cron, change only the delivery target:

openclaw cron add \
#
  --name "Research report" \
  --session isolated \
  --message "Research <topic>, analyze findings, create a PDF report, and deliver the summary." \
  --announce \
  --channel telegram \
  --to "<chat-id>"

Then later swap back to:

--channel discord --to "channel:<discord_channel_id>"
  1. For email, keep human approval
#

Let OpenClaw draft the email/report first, then approve sending manually or via your mail integration. I would not make email sending fully autonomous until the workflow is stable.

So the practical path is:

Control UI/WebChat → research/analyze/report works → temporary channel delivery → Discord delivery once bug is fixed.

rain jungle
daring geyserBOT
#

Short answer: for OpenClaw workflows, probably not “better” — more like “different.”

agent-browser looks like a strong standalone browser automation CLI: native Rust, CDP-based Chrome/Chromium control, snapshots with @eN refs, screenshots/PDF export, batch commands, cookies/storage/network tools, etc. (github.com)

But for your workflow, I’d still start with OpenClaw native browser because it’s integrated with the Gateway: isolated openclaw profile, optional signed-in user profile, tool policy, node proxy/remote browser routing, Browserless/Browserbase CDP support, cron, message delivery, and normal OpenClaw session context. (docs.openclaw.ai)

Where agent-browser may be worth trying:

  • you want a fast CLI-first browser tool
  • you need its specialized skills, e.g. Electron/Slack/Vercel Sandbox/AgentCore
  • you’re using it from Claude Code/Codex/Cursor too
  • you want to compare browser automation reliability

But for Research → Analyze → PDF/PPT → Send, native OpenClaw is the safer default. Use agent-browser as an optional experiment, not the main path yet. OpenClaw can also install some Claude/Codex/Cursor-style bundles as mapped skills/MCP content, but bundles are not the same as native OpenClaw plugins. (docs.openclaw.ai)

rain jungle
#

Enable the core tools you need < How do I check?

Right now my gateway doesn't start after the new patch:
13:51:28 [gateway] security warning: dangerous config flags enabled: tools.fs.workspaceOnly=false. Run openclaw security audit.
13:51:28 [gateway] starting channels and sidecars...
13:54:35 [channels] failed to load bundled channel imessage: No "exports" main defined in C:\Users\prapunsak.openclaw\plugin-runtime-deps\openclaw-2026.4.24-0f9b0b983df5\node_modules@mariozechner\pi-coding-agent\package.json
13:54:54 [channels] failed to load bundled channel irc: No "exports" main defined in C:\Users\prapunsak.openclaw\plugin-runtime-deps\openclaw-2026.4.24-0f9b0b983df5\node_modules@mariozechner\pi-coding-agent\package.json

daring geyserBOT
#

That log points to bundled plugin runtime deps, not “core tools” config. The tools.fs.workspaceOnly=false line is a warning; the scary part is:

plugin-runtime-deps\openclaw-2026.4.24...
@mariozechner\pi-coding-agent
No "exports" main defined

I’d do this order:

1. Get gateway starting first

On PowerShell:

openclaw gateway stop
#
openclaw doctor --fix
openclaw gateway start
openclaw gateway status

If it still fails, clear the staged runtime deps cache by renaming it, not deleting:

openclaw gateway stop

$stage = "$env:USERPROFILE\.openclaw\plugin-runtime-deps"
if (Test-Path $stage) {
  Rename-Item $stage "plugin-runtime-deps.bak.$(Get-Date -Format yyyyMMddHHmmss)"
}
#
openclaw doctor --fix
openclaw gateway start
openclaw gateway status

This folder is regenerated. Please add that exact pi-coding-agent error to your bug report too — 2026.4.24 has had runtime-deps/startup regressions in this area.

Docs: https://docs.openclaw.ai/install/updating
Docs: https://docs.openclaw.ai/gateway/doctor


2. Optional: fix the security warning

Unless you intentionally want the agent reading outside its workspace:

#
openclaw config set tools.fs.workspaceOnly true --strict-json
openclaw security audit

Docs: https://docs.openclaw.ai/gateway/security


3. How to check enabled tools

Before gateway starts, check config:

openclaw config get tools --json
openclaw config get agents.list --json
#
openclaw config get plugins --json

Once gateway starts, the easiest UI path is:

Control UI → Agents → Tools

There are two views:

  • Available Right Now = what the current session can actually use
  • Tool Configuration = configured profiles/overrides

Docs: https://docs.openclaw.ai/web/webchat


#

4. Good baseline for your workflow

For your private agent, a useful baseline is:

openclaw config set tools.profile coding
openclaw config set tools.alsoAllow '["browser","message"]' --strict-json

coding gives you files/runtime/web/cron/session tools. browser is added separately because real browser control is intentionally not in the default coding profile. message is needed for Discord/Telegram/Slack delivery.

Docs: https://docs.openclaw.ai/tools
Docs: https://docs.openclaw.ai/tools/browser

rain jungle
#

PS C:\WINDOWS\System32> openclaw gateway status

🦞 OpenClaw 2026.4.24 (cbcfdf6) — Running on your hardware, reading your logs, judging nothing (mostly).

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-27.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (last run 267009, last run time 27-Apr-26 3:32:10 PM)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Gateway port 18789 is not listening (service appears running).
Restart log: ~.openclaw\logs\gateway-restart.log

daring geyserBOT
#

This status means: the Scheduled Task exists / tries to run, but the Gateway process is not actually listening. So don’t debug tools yet — first get the Gateway to bind to 127.0.0.1:18789.

Run these and paste the first real error after startup:

Get-Content "$env:USERPROFILE\.openclaw\logs\gateway-restart.log" -Tail 120
Get-Content "$env:SystemDrive\tmp\openclaw\openclaw-2026-04-27.log" -Tail 200

Then try the recovery sequence:

openclaw gateway stop
openclaw doctor --fix
openclaw gateway restart
Start-Sleep 10
#
openclaw gateway status

If it still shows ECONNREFUSED, and you don’t use iMessage/IRC, disable those channels to avoid the broken bundled-channel load path:

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

If the pi-coding-agent runtime-deps error continues, rename the staged deps cache so OpenClaw regenerates it:

openclaw gateway stop
#

$stage = "$env:USERPROFILE\.openclaw\plugin-runtime-deps"
if (Test-Path $stage) {
  Rename-Item $stage "plugin-runtime-deps.bak.$(Get-Date -Format yyyyMMddHHmmss)"
}

openclaw doctor --fix
openclaw gateway restart

For checking tools: effective tools require a running Gateway. Once it starts:

  • Control UI → Agents → Tools → Available Right Now
  • Config-only checks:
rain jungle
#

CWI_MDy_.js:337","fileColumn":"14","fileLine":"337","filePath":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:337","method":"logToFile"}},"time":"2026-04-27T15:47:19.127+07:00"}
{"0":"{"subsystem":"gateway"}","1":"starting...","meta":{"runtime":"node","runtimeVersion":"24.14.0","hostname":"HQ-PS-N030","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-27T08:47:19.178Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CWI_MDy.js:337:14","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:337","fileColumn":"14","fileLine":"337","filePath":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:337","method":"logToFile"}},"time":"2026-04-27T15:47:19.178+07:00"}
{"0":"{"subsystem":"gateway"}","1":"gateway already running under schtasks; waiting 5000ms before retrying startup","meta":{"runtime":"node","runtimeVersion":"24.14.0","hostname":"HQ-PS-N030","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-27T08:47:30.888Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CWI_MDy.js:337:14","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:337","fileColumn":"14","fileLine":"337","filePath":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:337","method":"logToFile"}},"time":"2026-04-27T15:47:30.894+07:00"}

daring geyserBOT
#

That snippet is the wrapper/supervisor loop, not the real crash yet:

gateway already running under schtasks; waiting 5000ms before retrying startup

So Windows thinks the Scheduled Task is running, but 18789 is not listening. Clear the stuck task first.

1. Stop the stuck Scheduled Task

PowerShell:

openclaw gateway stop
schtasks /End /TN "OpenClaw Gateway"
Start-Sleep 5
#
openclaw gateway status

If it still says running-but-not-listening, check for leftover gateway node processes:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match 'openclaw.*gateway' } |
  Select-Object ProcessId, CommandLine

If you see one stuck process, stop that PID:

Stop-Process -Id <PID> -Force
#

2. Start in foreground to expose the real error

Don’t use the service for this test:

openclaw gateway run --verbose

That should show the actual startup failure directly.

3. If it’s still the plugin-runtime-deps error

Then do the cache reset:

$stage = "$env:USERPROFILE\.openclaw\plugin-runtime-deps"
#
if (Test-Path $stage) {
  Rename-Item $stage "plugin-runtime-deps.bak.$(Get-Date -Format yyyyMMddHHmmss)"
}

openclaw doctor --fix
openclaw gateway run --verbose

4. If you need a fast rollback

openclaw update --tag 2026.4.23
openclaw gateway restart

Once the Gateway is actually listening, then check tools in Control UI → Agents → Tools → Available Right Now. Right now tool checking will be unreliable because the Gateway RPC isn’t reachable.

rain jungle
#

Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-27.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (last run 267009, last run time 27-Apr-26 8:20:18 PM)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

  • pid 17868: node.exe (127.0.0.1:18789)
  • Another process is listening on this port.
    Listening: 127.0.0.1:18789
daring geyserBOT
#

Progress: now something is listening on 18789, but the Gateway probe times out. That usually means the node.exe process is hung or stuck during startup.

First confirm PID 17868 is actually OpenClaw:

Get-CimInstance Win32_Process -Filter "ProcessId=17868" |
  Select-Object ProcessId, ParentProcessId, CommandLine

If the command line contains openclaw ... gateway, kill only that stuck process:

schtasks /End /TN "OpenClaw Gateway"
Stop-Process -Id 17868 -Force
Start-Sleep 3
openclaw gateway restart
#
Start-Sleep 10
openclaw gateway status

If it comes back listening-but-timeout again, run foreground to catch the real blocker:

openclaw gateway stop
openclaw gateway --force --verbose

Also test HTTP health while it is “listening”:

Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing
#
Invoke-WebRequest http://127.0.0.1:18789/readyz -UseBasicParsing

If foreground still shows the plugin-runtime-deps / pi-coding-agent issue, rename the staged deps cache and rerun doctor:

$stage = "$env:USERPROFILE\.openclaw\plugin-runtime-deps"
if (Test-Path $stage) {
  Rename-Item $stage "plugin-runtime-deps.bak.$(Get-Date -Format yyyyMMddHHmmss)"
}

openclaw doctor --fix
openclaw gateway --force --verbose

At this point, the useful bug-report attachment is: foreground openclaw gateway --force --verbose output, not just gateway status.

rain jungle
#

PS C:\WINDOWS\System32> Get-CimInstance Win32_Process -Filter "ProcessId=17868" |

Select-Object ProcessId, ParentProcessId, CommandLine

ProcessId ParentProcessId CommandLine


17868           22216 "C:\Program Files\nodejs\node.exe"  C:\Users\prapunsak\AppData\Roaming\npm\node_modules\op...
daring geyserBOT
#

PowerShell truncated the command line, but the path starts with your npm global install, so it’s almost certainly the OpenClaw gateway process.

Show the full command once:

(Get-CimInstance Win32_Process -Filter "ProcessId=17868").CommandLine

If it contains openclaw\dist\index.js gateway, kill/restart it:

schtasks /End /TN "OpenClaw Gateway"
Stop-Process -Id 17868 -Force
Start-Sleep 3
openclaw gateway restart
Start-Sleep 10
#
openclaw gateway status

If status still times out, skip the Scheduled Task and run foreground:

openclaw gateway stop
openclaw gateway --force --verbose

That foreground output should reveal the actual crash/hang.

rain jungle
#

PS C:\WINDOWS\System32> (Get-CimInstance Win32_Process -Filter "ProcessId=17868").CommandLine
"C:\Program Files\nodejs\node.exe" C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789

daring geyserBOT
#

Yep, that is definitely the stuck OpenClaw gateway process.

Do this:

schtasks /End /TN "OpenClaw Gateway"
Stop-Process -Id 17868 -Force
Start-Sleep 3
openclaw gateway status

Then start it foreground so we can see the real startup error instead of the Scheduled Task hiding it:

openclaw gateway --force --verbose
#

If that foreground command hangs at startup, open a second PowerShell and run:

Invoke-WebRequest http://127.0.0.1:18789/healthz -UseBasicParsing -TimeoutSec 5
Invoke-WebRequest http://127.0.0.1:18789/readyz -UseBasicParsing -TimeoutSec 5

Paste the first error/last ~50 lines from the foreground window. That’s the useful part now.

rain jungle
#

🦞 OpenClaw 2026.4.24 (cbcfdf6) — The lobster in your shell. 🦞

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-27.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state Ready, last run 267014, last run time 27-Apr-26 8:20:18 PM, Task Last Run Result=267014; treating as not running.)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service is loaded but not running (likely exited immediately).
File logs: \tmp\openclaw\openclaw-2026-04-27.log
Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
Restart attempts: C:\Users\prapunsak.openclaw\logs\gateway-restart.log

daring geyserBOT
#

Good — now the stuck PID is gone. This state is expected after killing it:

Runtime: stopped
Task Last Run Result=267014

That code is basically “task was terminated,” not the original root cause.

Now don’t restart the Scheduled Task yet. Run the gateway in the foreground so the real error is visible:

openclaw gateway run --force --verbose

If it exits or hangs, paste the last ~80 lines from that window.

#

Also grab the real log tail:

Get-Content "$env:SystemDrive\tmp\openclaw\openclaw-2026-04-27.log" -Tail 200
Get-Content "$env:USERPROFILE\.openclaw\logs\gateway-restart.log" -Tail 120

If the foreground output again shows the plugin-runtime-deps / pi-coding-agent error, then the fast recovery is either:

openclaw update --tag 2026.4.23

or clear staged deps + doctor:

#
Rename-Item "$env:USERPROFILE\.openclaw\plugin-runtime-deps" "plugin-runtime-deps.bak.$(Get-Date -Format yyyyMMddHHmmss)"
openclaw doctor --fix
openclaw gateway run --force --verbose
rain jungle
#

Gateway is on now. But Discord is not

21:27:33 [discord] [aemeath] auto-restart attempt 4/10 in 44s
21:27:33 [ws] → event tick seq=per-client clients=1
21:27:34 [ws] → event health seq=per-client clients=1 presenceVersion=4 healthVersion=9
21:27:35 [ws] ⇄ res ✓ node.list 4ms conn=66d3548f…4f6f id=810437e0…7360
21:27:51 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
21:28:09 [discord] [default] delaying provider startup 10s to reduce Discord startup rate limits
21:28:09 [ws] → event tick seq=per-client clients=1
21:28:09 [ws] ⇄ res ✓ node.list 14ms id=e28dd150…5425
21:28:09 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
21:28:09 [diagnostic] lane enqueue: lane=session:agent:main:cron:6acb32bf-2c8e-46df-8768-bbbb2dd8b7fd queueSize=1
21:28:09 [diagnostic] lane dequeue: lane=session:agent:main:cron:6acb32bf-2c8e-46df-8768-bbbb2dd8b7fd waitMs=3 queueSize=0
21:28:09 [diagnostic] lane enqueue: lane=nested queueSize=1
21:28:09 [diagnostic] lane dequeue: lane=nested waitMs=6 queueSize=0
21:28:09 [plugins] [hooks] running before_agent_reply (1 handlers, first-claim wins)
21:28:09 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
21:28:13 [codex/catalog] codex model discovery failed; using fallback catalog
21:28:18 [discord] [aemeath] bot probe failed: Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:'
21:28:18 [discord] [aemeath] starting provider
21:28:18 [discord] [aemeath] channel exited: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:'
21:28:18 [discord] [aemeath] auto-restart attempt 5/10 in 84s
21:28:18 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider

daring geyserBOT
#

Nice, Gateway is alive now. The Discord error is not a Discord token/intents problem:

ERR_UNSUPPORTED_ESM_URL_SCHEME
On Windows, absolute paths must be valid file:// URLs.
Received protocol 'c:'

That’s a Windows plugin/module loader path bug: something is trying to import("C:\...") instead of import("file:///C:/..."). So don’t spend time regenerating Discord tokens.

Fastest stable fix: rollback

openclaw gateway stop
openclaw update --tag 2026.4.23
openclaw doctor --fix
#
openclaw gateway restart
openclaw channels status --probe

If you want to test the upcoming fix path

There are related Windows ERR_UNSUPPORTED_ESM_URL_SCHEME fixes in the unreleased changelog, so dev/main may work:

openclaw update --channel dev --dry-run
openclaw update --channel dev
openclaw gateway restart
openclaw channels status --probe

I’d personally do rollback to 2026.4.23 if you need Discord working today, and keep the bug report open for .24.

#

Also: these lines are probably noise, not the Discord root cause:

memory-core: managed dreaming cron could not be reconciled
codex model discovery failed; using fallback catalog

The important bug-report detail is the Discord line with ERR_UNSUPPORTED_ESM_URL_SCHEME, plus Windows + Node 24.14.0 + OpenClaw 2026.4.24.

rain jungle
#

Hey Krill. Im on 2026.4.26 now. Gateway not opening.

🦞 OpenClaw 2026.4.26 (be8c246) — Alexa, but with taste.

|
o
14:51:31 [gateway] loading configuration…
14:52:33 [restart] port 18789 still in use after 2000ms; proceeding anyway
14:52:33 [gateway] resolving authentication…
14:52:33 [gateway] starting...

daring geyserBOT
#

That log points at a port conflict/stale gateway on 18789. It’s not enough to know why yet, but it means the restart tried to free the gateway port and it was still occupied.

Try this first:

openclaw status --all
openclaw gateway status --deep

Then check who owns the port:

macOS/Linux

lsof -nP -iTCP:18789 -sTCP:LISTEN

Windows

#
netstat -ano | findstr :18789

If it’s an old openclaw/node gateway process, do:

openclaw gateway stop
sleep 3
openclaw gateway start

If it still won’t open, reinstall the service wrapper in case the update left the daemon pointing at an old binary:

openclaw gateway install --force
#
openclaw gateway restart

Then open:

http://127.0.0.1:18789/

If that still fails, paste the output of:

openclaw gateway status --deep
openclaw logs --tail 120
humble kite
daring geyserBOT
#

Custom implementation can totally be paid work, but the OpenClaw recipe is shareable here:

  1. Trigger

    • Scheduled: openclaw cron add ...
    • Gmail event: openclaw webhooks gmail setup --account you@gmail.com
    • Manual: ask your agent in Discord/Telegram.
  2. Research

    • Use web_fetch for normal pages.
    • Use browser for login/JS-heavy sites.
    • Use Gmail/Gog or Gmail PubSub for inbox-driven workflows.
  3. Analyze

    • Put the analysis instructions in the cron prompt, a skill, or a Lobster workflow.
    • For reliable multi-step flows, use Task Flow/Lobster with approval gates.
  4. Report

#
  • Easiest: generate Markdown/HTML first.
    • Convert to PDF/PPTX with local tools like pandoc, LibreOffice, or python-pptx.
    • Attach the generated file when sending.
  1. Send
    • Discord: openclaw message send --channel discord --target "channel:<id>" --media report.pdf
    • Email: draft first, then require human approval before sending.

Minimal cron shape:

openclaw cron add \
  --name "Daily research report" \
  --cron "0 8 * * *" \
  --tz "Asia/Bangkok" \
  --session isolated \
rain jungle
#

PS C:\Windows> openclaw gateway status --deep

🦞 OpenClaw 2026.4.26 (be8c246) — Welcome to the command line: where dreams compile and confidence segfaults.

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-28.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (last run 267009, last run time 28-Apr-26 3:40:36 PM)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Gateway port 18789 is not listening (service appears running).
Restart log: ~.openclaw\logs\gateway-restart.log

daring geyserBOT
#

That output narrows it down: Windows Task Scheduler says the gateway task is running, but nothing is actually listening on 127.0.0.1:18789. So we need the startup error from the file log.

Please run/paste:

node -v
openclaw logs --limit 200 --plain
Get-Content "$HOME\.openclaw\logs\gateway-restart.log" -Tail 80

Also try a clean foreground start so the real crash prints directly:

openclaw gateway stop
Start-Sleep -Seconds 3
openclaw gateway --port 18789
#

If that foreground command works, then repair the Scheduled Task wrapper:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

If it still says ECONNREFUSED, paste the last ~50 lines from the foreground start. Also check Node: OpenClaw needs Node 22.14+, Node 24 recommended. Docs: https://docs.openclaw.ai/install/node 🦐

rain jungle
#

PS C:\Windows> openclaw logs --limit 200 --plain

|
o
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\prapunsak.openclaw\openclaw.json
Bind: loopback
Hint: run openclaw doctor.
PS C:\Windows> Get-Content "$HOME.openclaw\logs\gateway-restart.log" -Tail 80
[22-Apr-26 11:14:53.21] openclaw restart log initialized
[22-Apr-26 11:14:53.25] openclaw restart attempt source=update target=OpenClaw Gateway
[24-Apr-26 9:16:08.21] openclaw restart log initialized
[24-Apr-26 9:16:08.22] openclaw restart attempt source=update target=OpenClaw Gateway
[26-Apr-26 11:55:07.13] openclaw restart log initialized
[26-Apr-26 11:55:08.00] openclaw restart attempt source=update target=OpenClaw Gateway
[26-Apr-26 15:03:24.28] openclaw restart log initialized
[26-Apr-26 15:03:25.01] openclaw restart attempt source=windows-task-handoff target="OpenClaw Gateway"
[26-Apr-26 15:03:27.44] openclaw restart finished source=windows-task-handoff
[27-Apr-26 13:42:55.19] openclaw restart log initialized
[27-Apr-26 13:42:55.26] openclaw restart attempt source=update target=OpenClaw Gateway
[27-Apr-26 16:06:08.37] openclaw restart failed source=update status=-1073741502
[28-Apr-26 0:52:29.21] openclaw restart log initialized
[28-Apr-26 0:52:29.23] openclaw restart attempt source=update target=OpenClaw Gateway
[28-Apr-26 9:42:40.71] openclaw restart failed source=update status=-1073741502
[2026-04-28T11:08:07.0806347+07:00] openclaw restart log initialized
[2026-04-28T11:08:07.1138734+07:00] openclaw restart attempt source=update target=OpenClaw Gateway
[2026-04-28T11:08:10.5153738+07:00] openclaw restart skipped schtasks end source=update state=Ready
[2026-04-28T11:08:13.9170912+07:00] SUCCESS: Attempted to run the scheduled task "OpenClaw Gateway".
[2026-04-28T11:08:13.9300591+07:00] openclaw restart done source=update

daring geyserBOT
#

Good, this confirms the gateway process is not getting far enough to listen. openclaw logs can’t help because it needs the gateway RPC; we need the raw file log + foreground crash.

Run these next:

node -v
openclaw --version
Get-Content "C:\tmp\openclaw\openclaw-2026-04-28.log" -Tail 160

Then try foreground mode:

openclaw gateway stop
Start-Sleep -Seconds 3
openclaw gateway --port 18789
#

If foreground works, the Scheduled Task wrapper is broken/stale:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

One clue: status=-1073741502 = Windows 0xC0000142, usually “process/DLL initialization failed” rather than an OpenClaw config error. So if foreground also dies immediately, I’d repair Node next — Node 24 recommended:

winget upgrade OpenJS.NodeJS.LTS
npm install -g openclaw@latest
openclaw gateway install --force
openclaw gateway restart
#

Paste the raw C:\tmp\openclaw\... tail or foreground output if it still fails.

rain jungle
#

{"0":"{"subsystem":"gateway"}","1":"resolving authentication…","_meta":{"runtime":"node","runtimeVersion":"24.14.0","hostname":"HQ-PS-N030","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-28T09:30:59.854Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147:14","fileName":"subsystem-rHhUC6qs.js","fileNameWithLine":"subsystem-rHhUC6qs.js:147","fileColumn":"14","fileLine":"147","filePath":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js","filePathWithLine":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147","method":"logToFile"}},"time":"2026-04-28T16:30:59.855+07:00","hostname":"HQ-PS-N030","message":"resolving authentication…"}
{"0":"{"subsystem":"gateway"}","1":"starting...","_meta":{"runtime":"node","runtimeVersion":"24.14.0","hostname":"HQ-PS-N030","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-28T09:30:59.872Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147:14","fileName":"subsystem-rHhUC6qs.js","fileNameWithLine":"subsystem-rHhUC6qs.js:147","fileColumn":"14","fileLine":"147","filePath":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js","filePathWithLine":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147","method":"logToFile"}},"time":"2026-04-28T16:30:59.873+07:00","hostname":"HQ-PS-N030","message":"starting..."}

daring geyserBOT
#

This log is useful: Node is fine (24.14.0), and OpenClaw reaches starting... but never opens the port. The … is just PowerShell encoding weirdness, not the bug.

Next best check:

openclaw gateway stop
Start-Sleep -Seconds 5
netstat -ano | findstr :18789
openclaw gateway --port 18789 --verbose

Let that foreground command run ~30 seconds.

  • If it prints an error: paste that.
  • If it hangs after starting...: press Ctrl+C, then run:
#
openclaw gateway stability --bundle latest --limit 100
schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST

Also run:

openclaw doctor --deep

I’d not reinstall Node yet — your version is good. This looks more like a gateway startup deadlock/crash after auth resolution or a broken Scheduled Task wrapper. Docs: https://docs.openclaw.ai/gateway/troubleshooting

rain jungle
#

Stopped Scheduled Task: OpenClaw Gateway
PS C:\Windows> Start-Sleep -Seconds 5
PS C:\Windows> netstat -ano | findstr :18789
PS C:\Windows> openclaw gateway --port 18789 --verbose

🦞 OpenClaw 2026.4.26 (be8c246)
I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

|
o
16:48:10 [gateway] loading configuration…
16:48:11 [gateway] resolving authentication…
16:48:11 [gateway] starting...
16:48:45 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:48:45 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:48:45 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:48:45 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:48:46 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:48:46 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:48:46 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:48:46 [agents/auth-profiles] kept usable local oauth over external cli bootstrap

daring geyserBOT
#

Good — port conflict is cleared now. This is a different state: foreground gateway is alive, but it’s slow/stuck before HTTP bind.

Two quick checks:

  1. Leave that foreground command running, open a second PowerShell, then run:
netstat -ano | findstr :18789
openclaw gateway status --deep

If it’s listening now, open http://127.0.0.1:18789/.

  1. If it’s still not listening after ~1–2 minutes, stop foreground with Ctrl+C and run startup trace:
#
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway --port 18789 --verbose

Paste the lines that say startup trace: — that will show exactly which startup phase is hanging before the port binds.

Also worth running once:

openclaw doctor --deep

The repeated agents/auth-profiles lines are likely debug noise from auth profile/bootstrap checks; the important thing is whether it ever reaches the HTTP bind.

rain jungle
#

PS C:\Windows> netstat -ano | findstr :18789
PS C:\Windows> openclaw gateway status --deep

🦞 OpenClaw 2026.4.26 (be8c246) — Like having a senior engineer on call, except I don't bill hourly or sigh audibly.

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-28.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state Ready, last run 267014, last run time 28-Apr-26 3:40:36 PM, Task Last Run Result=267014; treating as not running.)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service is loaded but not running (likely exited immediately).
File logs: \tmp\openclaw\openclaw-2026-04-28.log
Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
Restart attempts: C:\Users\prapunsak.openclaw\logs\gateway-restart.log

daring geyserBOT
#

That Runtime: stopped is only the Scheduled Task view — since you stopped it manually, 267014 / 0x41306 is expected-ish and not the main clue.

The main clue is: foreground gateway still doesn’t bind 18789. Please run the trace now:

Ctrl+C
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway --port 18789 --verbose

Paste the startup trace: lines. That should show the exact phase hanging before HTTP bind.

Also run this as a clean control test:

openclaw --dev gateway --allow-unconfigured --verbose
#
  • If --dev starts: main config/state is causing the hang.
  • If --dev also hangs: likely package/runtime regression on Windows.

Once done, unset trace if you want:

Remove-Item Env:OPENCLAW_GATEWAY_STARTUP_TRACE
rain jungle
#

17:00:21 [gateway] startup trace: cli.server-import 60.1ms total=60.2ms
17:00:21 [gateway] loading configuration…
17:00:21 [gateway] startup trace: cli.config-load 470.3ms total=630.0ms
17:00:21 [gateway] startup trace: cli.config-snapshot 337.8ms total=981.9ms
17:00:21 [gateway] resolving authentication…
17:00:21 [gateway] startup trace: cli.auth-resolve 1.0ms total=1013.5ms
17:00:22 [gateway] starting...
17:00:22 [gateway] startup trace: cli.gateway-loop 27.6ms total=1041.1ms
17:00:40 [gateway] startup trace: config.snapshot.read.file 4.3ms total=17.7ms eventLoopMax=0.0ms
17:00:40 [gateway] startup trace: config.snapshot.read.hash 0.2ms total=32.7ms eventLoopMax=0.0ms
17:00:40 [gateway] startup trace: config.snapshot.read.parse 5.0ms total=51.7ms eventLoopMax=0.0ms
17:00:40 [gateway] startup trace: config.snapshot.read.recovery-check 10.8ms total=77.2ms eventLoopMax=0.0ms
17:00:40 [gateway] startup trace: config.snapshot.read.includes 0.8ms total=103.5ms eventLoopMax=0.0ms
17:00:40 [gateway] startup trace: config.snapshot.read.env 1.9ms total=124.7ms eventLoopMax=0.0ms
17:00:40 [gateway] startup trace: config.snapshot.read.legacy 164.3ms total=309.1ms eventLoopMax=0.0ms

#

17:00:40 [gateway] startup trace: config.snapshot.read.plugin-install-migration 0.5ms total=323.7ms eventLoopMax=0.0ms
17:00:40 [gateway] startup trace: config.snapshot.read.validate 225.1ms total=567.0ms eventLoopMax=0.0ms
17:00:41 [gateway] startup trace: config.snapshot.read.materialize 25.6ms total=602.4ms eventLoopMax=0.0ms
17:00:41 [gateway] startup trace: config.snapshot.read.observe 9.7ms total=626.7ms eventLoopMax=0.0ms
17:00:41 [gateway] startup trace: config.snapshot.read 641.0ms total=641.7ms eventLoopMax=0.0ms
17:00:46 [gateway] startup trace: config.snapshot.auto-enable 5659.6ms total=6311.5ms eventLoopMax=0.0ms
17:00:46 [gateway] startup trace: config.snapshot 6325.6ms total=6325.8ms eventLoopMax=0.0ms
17:00:47 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:00:47 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:00:48 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:00:48 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:00:48 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:00:48 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:00:49 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:00:49 [agents/auth-profiles] kept usable local oauth over external cli bootstrap

#

PS C:\Windows> openclaw --dev gateway --allow-unconfigured --verbose

🦞 OpenClaw 2026.4.26 (be8c246) — Finally, a use for that always-on Mac Mini under your desk.

|
o
17:00:21 [gateway] loading configuration…
17:00:21 [gateway] resolving authentication…
17:00:21 [gateway] starting...
17:00:47 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:00:47 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:00:48 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:00:48 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:00:48 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:00:48 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:00:48 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:00:48 [agents/auth-profiles] kept usable local oauth over external cli bootstrap

daring geyserBOT
#

This trace is cut right at the interesting point. Last completed phase is:

config.snapshot.read.legacy

The next expected lines should be roughly:

config.snapshot.read.plugin-install-migration
config.snapshot.read.validate
config.snapshot.read.materialize
config.snapshot.read.observe
config.snapshot.read

So please run it again and capture longer:

#
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
openclaw gateway --port 18789 --verbose 2>&1 | Tee-Object "$env:TEMP\openclaw-startup-trace.txt"

Let it sit 2–3 minutes. If no new lines appear, Ctrl+C, then paste:

Get-Content "$env:TEMP\openclaw-startup-trace.txt" -Tail 80

Also run the control test:

openclaw --dev gateway --allow-unconfigured --verbose
#

Interpretation:

  • Dev gateway starts → your main config/state/plugin registry is likely hanging.
  • Dev gateway also hangs → likely Windows/package regression in 2026.4.26.

If main config is the issue, next safe repair step is:

openclaw doctor --deep
openclaw doctor --fix

The current trace suggests the gateway is stuck during config/plugin startup before it even reaches HTTP bind.

#

Nice, this is enough to narrow it down.

Gateway config load is finishing. The missing next trace is likely:

config.auth

So it’s probably hanging in startup auth / secrets / auth-profile resolution, not the port or Scheduled Task.

Try this isolation run:

Ctrl+C
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
#
$env:OPENCLAW_SKIP_CHANNELS="1"
openclaw gateway --port 18789 --verbose

Then in another PowerShell:

netstat -ano | findstr :18789

If it starts listening with those env vars, we know one provider/channel secret/auth profile is blocking startup. Then run:

openclaw doctor --deep
openclaw doctor --fix
#

After testing, clear the temporary env vars:

Remove-Item Env:OPENCLAW_SKIP_PROVIDERS
Remove-Item Env:OPENCLAW_SKIP_CHANNELS
Remove-Item Env:OPENCLAW_GATEWAY_STARTUP_TRACE

Also please still test:

openclaw --dev gateway --allow-unconfigured --verbose

If dev works but main doesn’t: main state/config/auth profile issue.
If dev also hangs: likely Windows/package regression and worth filing with this trace.

#

Yep — dev hanging too is the important result. That means this is probably not your main config/state. It’s more likely a 2026.4.26 Windows startup regression, or something global like provider/auth/plugin startup.

Try one more isolation run:

Ctrl+C
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_CRON="1"
$env:OPENCLAW_SKIP_GMAIL_WATCHER="1"
openclaw gateway --port 18789 --verbose

If that starts listening, one provider/channel startup path is blocking.

If it still hangs before config.auth completes, I’d file this as a bug with the trace here:

#

https://github.com/openclaw/openclaw/issues

Include:

  • Windows
  • OpenClaw 2026.4.26 (be8c246)
  • Node 24.14.0
  • Gateway hangs before port bind
  • Last trace: config.snapshot, then repeated agents/auth-profiles, no config.auth

Optional diagnostics zip:

openclaw gateway diagnostics export --output "$env:TEMP\openclaw-diagnostics.zip"

Temporary unblock if you need working gateway now: roll back to the last version that worked for you, then reinstall the service wrapper.

rain jungle
#

Can you summarize again what I need to do next?

daring geyserBOT
#

Sure — do these next, in order:

  1. Stop the current foreground gateway
    Press Ctrl+C.

  2. Try the isolation startup:

$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_CRON="1"
$env:OPENCLAW_SKIP_GMAIL_WATCHER="1"
openclaw gateway --port 18789 --verbose
  1. In a second PowerShell, check if it listens:
#
netstat -ano | findstr :18789
openclaw gateway status --deep
  1. If it works: one provider/channel/startup service is blocking. Run:
openclaw doctor --deep
openclaw doctor --fix
  1. If it still hangs: likely a Windows/2026.4.26 regression. Create diagnostics:
openclaw gateway diagnostics export --output "$env:TEMP\openclaw-diagnostics.zip"
#

Then file an issue here: https://github.com/openclaw/openclaw/issues

Include:

  • Windows
  • OpenClaw 2026.4.26 (be8c246)
  • Node 24.14.0
  • Gateway never binds 18789
  • Dev gateway also hangs
  • Last trace reaches config.snapshot, then repeats agents/auth-profiles, no config.auth

After testing, clear env vars:

Remove-Item Env:OPENCLAW_GATEWAY_STARTUP_TRACE
Remove-Item Env:OPENCLAW_SKIP_PROVIDERS
Remove-Item Env:OPENCLAW_SKIP_CHANNELS
#
Remove-Item Env:OPENCLAW_SKIP_CRON
Remove-Item Env:OPENCLAW_SKIP_GMAIL_WATCHER
rain jungle
#

PS C:\Windows> netstat -ano | findstr :18789
PS C:\Windows> openclaw gateway status --deep

🦞 OpenClaw 2026.4.26 (be8c246)
Making 'I'll automate that later' happen now.

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-28.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state Ready, last run 267014, last run time 28-Apr-26 3:40:36 PM, Task Last Run Result=267014; treating as not running.)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service is loaded but not running (likely exited immediately).
File logs: \tmp\openclaw\openclaw-2026-04-28.log
Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
Restart attempts: C:\Users\prapunsak.openclaw\logs\gateway-restart.log

#

17:14:39 [gateway] startup trace: config.snapshot.read.parse 5.1ms total=46.0ms eventLoopMax=0.0ms
17:14:39 [gateway] startup trace: config.snapshot.read.recovery-check 10.7ms total=66.0ms eventLoopMax=0.0ms
17:14:39 [gateway] startup trace: config.snapshot.read.includes 0.8ms total=79.7ms eventLoopMax=0.0ms
17:14:39 [gateway] startup trace: config.snapshot.read.env 1.8ms total=96.6ms eventLoopMax=0.0ms
17:14:39 [gateway] startup trace: config.snapshot.read.legacy 86.6ms total=202.3ms eventLoopMax=0.0ms
17:14:39 [gateway] startup trace: config.snapshot.read.plugin-install-migration 0.6ms total=211.6ms eventLoopMax=0.0ms
17:14:40 [gateway] startup trace: config.snapshot.read.validate 199.8ms total=493.1ms eventLoopMax=0.0ms
17:14:40 [gateway] startup trace: config.snapshot.read.materialize 21.0ms total=525.3ms eventLoopMax=0.0ms
17:14:40 [gateway] startup trace: config.snapshot.read.observe 3.8ms total=540.9ms eventLoopMax=0.0ms
17:14:40 [gateway] startup trace: config.snapshot.read 551.1ms total=551.8ms eventLoopMax=0.0ms
17:14:46 [gateway] startup trace: config.snapshot.auto-enable 6321.1ms total=6884.5ms eventLoopMax=0.0ms
17:14:46 [gateway] startup trace: config.snapshot 6897.3ms total=6897.5ms eventLoopMax=0.0ms
17:14:54 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:14:54 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:14:54 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:14:54 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:14:55 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:14:55 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:14:55 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:14:55 [agents/auth-profiles] kept usable local oauth over external cli bootstrap

daring geyserBOT
#

This output just confirms nothing is listening and the Scheduled Task is stopped. That’s expected if you only checked status after stopping it.

The missing piece is: what happened when you ran the isolation command?

Please run this in PowerShell and leave it open:

$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_CRON="1"
$env:OPENCLAW_SKIP_GMAIL_WATCHER="1"
openclaw gateway --port 18789 --verbose

Then open a second PowerShell and run:

#
netstat -ano | findstr :18789

If netstat still shows nothing after 1–2 minutes, paste the last lines from the first PowerShell. That tells us whether it’s still hanging before bind even with providers/channels skipped.

#

This confirms the skip test still hangs before config.auth finishes, so it’s not just a normal Discord/Gmail/cron startup issue.

Next do one final isolation test:

Ctrl+C
$env:OPENCLAW_GATEWAY_STARTUP_TRACE="1"
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"
openclaw gateway --port 18789 --verbose

Then in another PowerShell:

netstat -ano | findstr :18789
#

Results

  • If it starts listening: likely a bundled plugin startup/auth regression.
  • If it still doesn’t listen: likely a core Windows startup/auth regression in 2026.4.26.

Either way, please generate diagnostics:

openclaw gateway diagnostics export --output "$env:TEMP\openclaw-diagnostics.zip"
openclaw secrets audit --check
openclaw doctor --deep

Then file a GitHub issue: https://github.com/openclaw/openclaw/issues

Include your trace and say: Windows + OpenClaw 2026.4.26 + Node 24.14.0 + gateway hangs after config.snapshot, before config.auth, dev gateway also hangs.

Temporary unblock: roll back to the last version that worked, then:

#
openclaw gateway install --force
openclaw gateway restart
rain jungle
#

PS C:\Windows> netstat -ano | findstr :18789
PS C:\Windows>
? like this?

daring geyserBOT
#

Yes — exactly like that. Empty output means nothing is listening on port 18789.

Now check the first PowerShell window where you ran:

$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"
openclaw gateway --port 18789 --verbose

If it’s still sitting there with no new lines, paste its last ~20 lines.

At this point the key result is:

  • netstat empty = gateway did not bind
  • dev mode also hangs
  • skip providers/channels/cron still hangs
#

So unless OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 changes things, this is very likely a 2026.4.26 Windows startup regression.

rain jungle
daring geyserBOT
#

Yep — if Gateway is live only with the diagnostic env vars, then the offline/no-response behavior is expected.

You probably still have one of these set in that PowerShell:

OPENCLAW_SKIP_PROVIDERS
OPENCLAW_SKIP_CHANNELS
OPENCLAW_DISABLE_BUNDLED_PLUGINS

Those make the gateway start in “limp mode”:

  • OPENCLAW_SKIP_CHANNELS=1 → Discord won’t come online
  • OPENCLAW_SKIP_PROVIDERS=1 → agent/model responses may fail
  • OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 → bundled Discord/browser/tools/providers won’t load

Now clear them and restart normally:

#
Ctrl+C
Remove-Item Env:OPENCLAW_GATEWAY_STARTUP_TRACE -ErrorAction SilentlyContinue
Remove-Item Env:OPENCLAW_SKIP_PROVIDERS -ErrorAction SilentlyContinue
Remove-Item Env:OPENCLAW_SKIP_CHANNELS -ErrorAction SilentlyContinue
Remove-Item Env:OPENCLAW_SKIP_CRON -ErrorAction SilentlyContinue
Remove-Item Env:OPENCLAW_SKIP_GMAIL_WATCHER -ErrorAction SilentlyContinue
Remove-Item Env:OPENCLAW_DISABLE_BUNDLED_PLUGINS -ErrorAction SilentlyContinue

openclaw gateway --port 18789 --verbose

If normal startup hangs again, we’ve proven the workaround only starts a disabled gateway. Then collect:

openclaw doctor --deep
rain jungle
#

PS C:\Windows> Remove-Item Env:OPENCLAW_GATEWAY_STARTUP_TRACE -ErrorAction SilentlyContinue
PS C:\Windows> Remove-Item Env:OPENCLAW_SKIP_PROVIDERS -ErrorAction SilentlyContinue
PS C:\Windows> Remove-Item Env:OPENCLAW_SKIP_CHANNELS -ErrorAction SilentlyContinue
PS C:\Windows> Remove-Item Env:OPENCLAW_SKIP_CRON -ErrorAction SilentlyContinue
PS C:\Windows> Remove-Item Env:OPENCLAW_SKIP_GMAIL_WATCHER -ErrorAction SilentlyContinue
PS C:\Windows> Remove-Item Env:OPENCLAW_DISABLE_BUNDLED_PLUGINS -ErrorAction SilentlyContinue
PS C:\Windows>
PS C:\Windows> openclaw gateway --port 18789 --verbose

🦞 OpenClaw 2026.4.26 (be8c246) — Your task has been queued; your dignity has been deprecated.

|
o
17:29:14 [gateway] loading configuration…
17:29:15 [gateway] resolving authentication…
17:29:15 [gateway] starting...
17:29:52 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:29:52 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:29:52 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:29:52 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:29:53 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:29:53 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
17:29:53 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
17:29:53 [agents/auth-profiles] kept usable local oauth over external cli bootstrap

daring geyserBOT
#

Normal startup is still hanging. Good news: we proved port/service isn’t the core issue. Now we need isolate which startup area blocks it.

Do this next — one test at a time:

1) Test providers only

Ctrl+C
Remove-Item Env:OPENCLAW_SKIP_CHANNELS -ErrorAction SilentlyContinue
Remove-Item Env:OPENCLAW_DISABLE_BUNDLED_PLUGINS -ErrorAction SilentlyContinue
$env:OPENCLAW_SKIP_PROVIDERS="1"
openclaw gateway --port 18789 --verbose

Second PowerShell:

#
netstat -ano | findstr :18789

2) If still no listener, test channels only

Ctrl+C
Remove-Item Env:OPENCLAW_SKIP_PROVIDERS -ErrorAction SilentlyContinue
$env:OPENCLAW_SKIP_CHANNELS="1"
openclaw gateway --port 18789 --verbose

Check netstat again.

3) If still no listener, test bundled plugins

#
Ctrl+C
Remove-Item Env:OPENCLAW_SKIP_CHANNELS -ErrorAction SilentlyContinue
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"
openclaw gateway --port 18789 --verbose

Whichever one makes netstat show 18789 is the culprit area.

If none of these work alone, generate diagnostics and file this as a Windows 2026.4.26 startup bug:

openclaw gateway diagnostics export --output "$env:TEMP\openclaw-diagnostics.zip"

Issue link: https://github.com/openclaw/openclaw/issues
Docs: https://docs.openclaw.ai/gateway/troubleshooting

rain jungle
daring geyserBOT
#

Yes — that proves the culprit area is bundled plugins.

Important: OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 is only a diagnostic mode. Gateway can bind, but Discord/providers/tools are disabled, so the agent being offline is expected.

Do this next:

Ctrl+C
Remove-Item Env:OPENCLAW_DISABLE_BUNDLED_PLUGINS -ErrorAction SilentlyContinue

openclaw plugins registry --refresh
openclaw plugins doctor
openclaw doctor --deep
openclaw doctor --fix

Then retry normal:

#
openclaw gateway --port 18789 --verbose

If it still hangs, collect this for a GitHub issue:

openclaw plugins list --enabled --verbose > "$env:TEMP\openclaw-plugins-enabled.txt"
openclaw gateway diagnostics export --output "$env:TEMP\openclaw-diagnostics.zip"

Issue summary to use:

Windows, OpenClaw 2026.4.26, Node 24.14.0. Gateway hangs before binding 18789 during bundled plugin startup. OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 makes gateway bind, but normal startup hangs.

File here: https://github.com/openclaw/openclaw/issues

rain jungle
#

PS C:\Windows> Remove-Item Env:OPENCLAW_DISABLE_BUNDLED_PLUGINS -ErrorAction SilentlyContinue
PS C:\Windows>
PS C:\Windows> openclaw plugins registry --refresh

🦞 OpenClaw 2026.4.26 (be8c246) — Deployed locally, trusted globally, debugged eternally.

Plugin registry refreshed: 68/115 enabled plugins indexed.
PS C:\Windows> openclaw plugins doctor

🦞 OpenClaw 2026.4.26 (be8c246)
If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

No plugin issues detected.

daring geyserBOT
#

Good — registry looks clean, but runtime loading a bundled plugin is still hanging.

Next:

openclaw doctor --deep
openclaw doctor --fix

Then try normal again:

openclaw gateway --port 18789 --verbose

If it still hangs, use a temporary plugin allowlist to find the exact plugin:

#
Ctrl+C
Copy-Item "$HOME\.openclaw\openclaw.json" "$HOME\.openclaw\openclaw.json.backup-plugins" -Force

openclaw config set plugins.allow '["discord"]' --strict-json --replace
openclaw gateway --port 18789 --verbose

If that starts, Discord plugin is okay. Then add your model provider one at a time, e.g.:

openclaw config set plugins.allow '["discord","anthropic"]' --strict-json --replace

or:

#
openclaw config set plugins.allow '["discord","openai"]' --strict-json --replace

or openrouter, google, minimax — whichever you use.

When you find the plugin that makes startup hang, that’s the bug report target.

To undo the allowlist later:

openclaw config unset plugins.allow
rain jungle
#

11:16:51 [gateway] loading configuration…
11:16:53 [gateway] resolving authentication…
11:16:53 [gateway] starting...
11:24:18 [gateway] starting HTTP server...
11:24:18 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root C:\Users\prapunsak.openclaw\canvas)
11:24:18 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
12:00:48 [health-monitor] [discord:aemeath] health-monitor: restarting (reason: stopped)
12:00:49 [health-monitor] [discord:default] health-monitor: restarting (reason: stopped)
12:00:49 [discord] [default] delaying provider startup 10s to reduce Discord startup rate limits
12:00:49 [gateway] agent model: openai-codex/gpt-5.4-mini
12:00:49 [gateway] http server listening (8 plugins: acpx, browser, device-pair, discord, memory-core, phone-control, talk-voice, voice-call; 2635.8s)
12:00:49 [gateway] log file: \tmp\openclaw\openclaw-2026-04-29.log
12:00:49 [gateway] security warning: dangerous config flags enabled: tools.fs.workspaceOnly=false. Run openclaw security audit.
12:00:49 [gateway] starting channels and sidecars...
12:00:53 [hooks] loaded 4 internal hook handlers
12:00:53 [discord] [aemeath] starting provider (@Aemeath)
12:02:59 [discord] channel resolve failed; using config entries. fetch failed | write ECONNABORTED
12:02:59 [discord] users resolved: 1476905755264286833
12:02:59 [discord] channel users resolved: 1476905755264286833
12:03:03 [discord] [default] starting provider
12:09:50 [plugins] embedded acpx runtime backend registered (cwd: C:\Users\prapunsak.openclaw\workspace)
12:10:01 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
12:10:01 [discord] gateway metadata lookup failed transiently; using default gateway url (Failed to get gateway information from Discord: fetch failed | gateway metadata timeout)
12:10:04 [voice-call] Webhook server listening on http://127.0.0.1:3334/voice/webhook

#

12:10:04 [plugins] [voice-call] Runtime initialized
12:10:04 [plugins] [voice-call] Webhook URL: http://127.0.0.1:3334/voice/webhook
12:10:04 [gateway] ready
12:10:04 [heartbeat] started
12:10:05 [discord] channels resolved: 1476935140331622410/1477903407275704362 (guild:OpenClaw; channel:control-panel)
12:10:05 [discord] users resolved: 1476905755264286833
12:10:05 [discord] channel users resolved: 1476905755264286833
12:10:07 [discord] logged in to discord as 1476937202478092423 (Aemeath)
12:17:58 [plugins] web-readability staging bundled runtime deps (2 missing, 69 install specs): @mozilla/readability@^0.6.0, linkedom@^0.18.12
12:18:30 [plugins] web-readability installed bundled runtime deps in 31969ms: @mozilla/readability@^0.6.0, linkedom@^0.18.12
12:23:33 [discord] startup [default] deploy-rest:put:error 1230419ms path=/applications/1477887757052411955/commands requestMs=801075 error=This operation was aborted
12:23:33 [discord] discord: failed to deploy native commands: This operation was aborted
12:23:34 [typing] TTL exceeded (60000ms), auto-stopping typing indicator
12:23:34 [health-monitor] [discord:default] health-monitor: restarting (reason: disconnected)
12:23:35 [discord] gateway: Gateway websocket closed: 1000
12:23:35 [discord] gateway: Gateway reconnect scheduled in 915ms (close, resume=true)
12:45:08 [discord] [default] channel stop exceeded 5000ms after abort; continuing shutdown
12:45:08 [discord] discord: failed to fetch bot identity: AbortError:

#

This operation was aborted
12:45:08 [discord] client initialized; awaiting gateway readiness
12:45:09 [health-monitor] [discord:aemeath] health-monitor: restarting (reason: disconnected)
12:45:40 [discord] [aemeath] starting provider (@Aemeath)
12:45:40 [ws] handshake timeout conn=1c061d40-039d-43bd-894c-bcfad8191e89 peer=127.0.0.1:64024->127.0.0.1:18789 remote=127.0.0.1
12:45:40 [ws] closed before connect conn=1c061d40-039d-43bd-894c-bcfad8191e89 peer=127.0.0.1:64024->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36 code=1000 reason=n/a

daring geyserBOT
#

Your gateway looks mostly uphttp server listening, Discord started, and browser control is listening.

Two things to fix/check:

  1. Please paste openclaw --version if this is still failing.
  2. This warning matters:
    dangerous config flags enabled: tools.fs.workspaceOnly=false
    
    For email/web automation, I’d run:
    openclaw security audit
    
    and avoid broad filesystem access unless you really need it.

For the workflow, use this pattern:

#
openclaw cron add \
  --name "research-analysis-report" \
  --cron "0 8 * * 1-5" \
  --tz "Asia/Bangkok" \
  --session isolated \
  --message "Research from email/web, analyze findings, generate a report, and send the final summary to Discord. Do not send external email without explicit approval." \
  --announce \
  --channel discord \
  --to "channel:<DISCORD_CHANNEL_ID>"

For email-triggered instead of scheduled runs:

openclaw webhooks gmail setup --account your@email.com
#

Yep — your gateway reached ready, and Discord logged in as Aemeath, so the base is alive. The failed to deploy native commands line looks like a Discord REST/network timeout; if normal messages work, you can continue. If slash commands don’t show up, restart/update and run openclaw status --all.

Step-by-step workflow:

  1. Check version/status

    openclaw --version
    openclaw status --all
    
  2. Enable research inputs

    • Web: configure a search provider:
      openclaw configure --section web
      
    • Gmail/email trigger:
#

openclaw webhooks gmail setup --account your@email.com
```

  1. Define the workflow in AGENTS.md or a skill
    Tell the agent the exact sources, report format, recipients, and approval rules. Example:

    Research from Gmail + web, analyze results, create a report, then send to Discord. Do not send external email without approval.

  2. Generate report as Markdown first
    Best path:

    • Agent writes reports/YYYY-MM-DD-report.md
    • Convert to PDF/PPTX with a local tool like Pandoc/LibreOffice/Marp
    • Attach/send the generated file
  3. Schedule it

    openclaw cron add \
    
#
     --name "research-report" \
     --cron "0 8 * * 1-5" \
     --tz "Asia/Bangkok" \
     --session isolated \
     --message "Run the research → analysis → report workflow. Create a Markdown report, convert to PDF/PPTX if possible, then send summary and attachment to Discord. Ask before sending external email." \
     --announce \
     --channel discord \
     --to "channel:<YOUR_CHANNEL_ID>"
  1. For reliable multi-step workflows
    Use Lobster + approval gates, especially before sending email.

Docs:
https://docs.openclaw.ai/automation/cron-jobs
https://docs.openclaw.ai/automation/standing-orders

#

That new log is more of a stability/connectivity issue, not a workflow issue yet.

Key lines:

failed to deploy native commands: This operation was aborted
[ws] handshake timeout
health-monitor ... restarting (reason: disconnected)

I’d do this order:

openclaw --version
openclaw status --all
openclaw gateway status
#
openclaw channels status --probe
openclaw doctor

If the machine is slow/busy during startup, increase the gateway WS handshake timeout:

openclaw config set gateway.handshakeTimeoutMs 30000 --strict-json
openclaw gateway restart

If Discord slash/native commands keep timing out but normal messages work, you can temporarily disable native command deploy:

openclaw config set channels.discord.commands.native false --strict-json
rain jungle
#

OpenClaw 2026.4.26 (be8c246)

Right now gateway is the main problem. Discord still not on

daring geyserBOT
#

Got it — since you’re on OpenClaw 2026.4.26, I’d focus on Discord/gateway before building the workflow.

Your logs show two likely issues:

  1. Discord REST/native command deploy is hanging
  2. Gateway WS handshake timeout during UI/control connection

Try this first:

openclaw config set channels.discord.commands.native false --strict-json
openclaw config set gateway.handshakeTimeoutMs 30000 --strict-json
openclaw gateway restart

Then check:

#
openclaw status --all
openclaw gateway status
openclaw channels status --probe
openclaw pairing list discord

Also, your logs showed both default and aemeath Discord accounts. If you only intend to use Aemeath, make sure you don’t have a broken/duplicate default Discord account configured. Duplicate/bad Discord accounts can make startup look broken even if one bot token is fine.

Please paste the output of:

openclaw channels status --probe

Tokens should be redacted; don’t paste raw bot tokens/config secrets.

rain jungle
#

Did I paste secret in this chat? or you meant openclaw channels status --probe?

daring geyserBOT
#

No, I don’t see a raw secret/token pasted here. You only pasted logs/version info — that’s fine.

I meant: please run and paste the output of:

openclaw channels status --probe

That command is intended for diagnostics and should redact secrets. Still, quick sanity check before posting: don’t paste anything that looks like a Discord bot token, API key, OAuth refresh token, or long Authorization value.

If you want extra-safe output, you can also paste:

openclaw status --all

It’s designed as a safe-to-share report.

rain jungle
#

PS C:\WINDOWS\System32> openclaw status --all

OpenClaw 2026.4.26 (be8c246)

Overview:
Version: 2026.4.26
OS: Windows 10.0.26200 x64
Node: 24.14.0
Config: C:\Users\prapunsak.openclaw\openclaw.json
Dashboard: http://127.0.0.1:18789/
Tailscale exposure: off
Channel: stable default
Update: pnpm, up to date, npm latest 2026.4.26
Gateway: local ws://127.0.0.1:18789, local loopback, unreachable timeout
Security: Run openclaw security audit --deep
Gateway self: unknown
Gateway service: Scheduled Task installed, registered, running
Node service: Scheduled Task not installed
Agents: 4 total, 0 bootstrapping, 0 active, 55 sessions
Secrets: none

Agents:
main Shorekeeper: bootstrap absent, 45 sessions, active 33m ago
aemeath: bootstrap absent, 10 sessions, active 20h ago
aemeath-cron: bootstrap absent, 0 sessions, active unknown
main-cron: bootstrap absent, 0 sessions, active unknown

Diagnosis:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\prapunsak.openclaw\openclaw.json
Bind: loopback

Config OK
Secret diagnostics: 0
Restart sentinel: none

Issue:
Port 18789 is already in use.
pid 9692: node.exe 127.0.0.1:18789
Another process is listening on this port.

Tailscale exposure: off, daemon unknown
Skills: 21 eligible, 0 missing, C:\Users\prapunsak.openclaw\workspace
Plugin compatibility: none

Gateway restart attempts:
2026-04-27 16:06:08 restart failed, source update, status -1073741502
2026-04-28 09:42:40 restart failed, source update, status -1073741502
2026-04-28 11:08:13 SUCCESS: Attempted to run scheduled task "OpenClaw Gateway"
2026-04-28 11:08:13 restart done, source update

Channel issues skipped because gateway unreachable.
Gateway health: timeout

daring geyserBOT
#

Yep, this confirms it: Discord isn’t the root problem yet. Your Gateway process is listening on port 18789, but it’s not responding to health/RPC, so OpenClaw can’t even probe channels.

This line is the key:

Gateway: ... unreachable timeout
Port 18789 is already in use.
pid 9692: node.exe 127.0.0.1:18789
Gateway health: timeout

Do this in PowerShell:

openclaw gateway stop
Start-Sleep -Seconds 5
#
openclaw gateway status --deep

If it still says port 18789 is in use by PID 9692, kill the stuck node process:

Stop-Process -Id 9692 -Force

Then restart cleanly:

openclaw gateway start
openclaw gateway status --deep
openclaw status --all
#

Only after Gateway shows reachable/healthy, run:

openclaw channels status --probe

Small note: your Node 24.14.0 is fine. This looks like a wedged Gateway process / Scheduled Task state, not a Node version problem.

rain jungle
#

PS C:\WINDOWS\System32> openclaw gateway status --deep

🦞 OpenClaw 2026.4.26 (be8c246) — The lobster in your shell. 🦞

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state Ready, last run 267014, last run time 29-Apr-26 1:18:38 PM, Task Last Run Result=267014; treating as not running.)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service is loaded but not running (likely exited immediately).
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
Restart attempts: C:\Users\prapunsak.openclaw\logs\gateway-restart.log

daring geyserBOT
#

Good, this is progress: the old stuck port is gone. Now the issue is:

Runtime: stopped
connect ECONNREFUSED
Service is loaded but not running (likely exited immediately)

So the Scheduled Task starts OpenClaw, then OpenClaw exits. Next step is to find the startup error.

Run:

openclaw logs --limit 200 --plain

If that doesn’t show the crash, run the gateway in the foreground:

#
openclaw gateway --port 18789 --verbose

Leave that window open. If it exits, paste the last ~50 lines. If it stays running, open a second PowerShell and run:

openclaw gateway status --deep
openclaw channels status --probe

If foreground works but Scheduled Task doesn’t, repair the service wrapper:

openclaw doctor --fix
openclaw gateway install --force
#
openclaw gateway restart

The Last Run Result=267014 is just the Windows task result; the real cause should be in the OpenClaw log or foreground crash output.

rain jungle
#

PS C:\WINDOWS\System32> openclaw logs --limit 200 --plain

🦞 OpenClaw 2026.4.26 (be8c246)
I've survived more breaking changes than your last three relationships.

|
o
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\prapunsak.openclaw\openclaw.json
Bind: loopback
Hint: run openclaw doctor.

daring geyserBOT
#

openclaw logs tried RPC, but the gateway is down, so it couldn’t fetch the file log. Read the file directly instead:

Get-Content "\tmp\openclaw\openclaw-2026-04-29.log" -Tail 200

Also check the restart log:

Get-Content "$env:USERPROFILE\.openclaw\logs\gateway-restart.log" -Tail 100

If the log path doesn’t exist, run:

Get-ChildItem "\tmp\openclaw" -Filter "openclaw-*.log" | Sort-Object LastWriteTime -Descending | Select-Object -First 1
#

Then run foreground to expose the real crash:

openclaw gateway --port 18789 --verbose

Paste the last ~50 lines from either the file log or foreground output. That should show why the Scheduled Task exits immediately.

rain jungle
#

stem-rHhUC6qs.js:146","fileColumn":"51","fileLine":"146","filePath":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js","filePathWithLine":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:146","method":"logToFile"}},"time":"2026-04-29T13:42:06.217+07:00","hostname":"HQ-PS-N030","message":"closed before connect conn=59b1870f-a231-4d4b-b535-f0b5fa1f4d4a peer=127.0.0.1:58909->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36 code=1006 reason=n/a"}
{"0":"{"subsystem":"gateway/ws"}","1":

#

{"handshake":"pending","durationMs":68,"host":"127.0.0.1:18789","origin":"http://127.0.0.1:18789","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36","remoteAddr":"127.0.0.1","remotePort":64257,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:64257->127.0.0.1:18789"},"2":"closed before connect conn=910712ca-0b97-48ea-8cb1-1fd794d69bca peer=127.0.0.1:64257->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36 code=1006 reason=n/a","_meta":{"runtime":"node","runtimeVersion":"24.14.0","hostname":"HQ-PS-N030","name":"{"subsystem":"gateway/ws"}","parentNames":["openclaw"],"date":"2026-04-29T06:42:06.243Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:146:51","fileName":"subsystem-rHhUC6qs.js","fileNameWithLine":"subsystem-rHhUC6qs.js:146","fileColumn":"51","fileLine":"146","filePath":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-

#

rHhUC6qs.js","filePathWithLine":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:146","method":"logToFile"}},"time":"2026-04-29T13:42:06.243+07:00","hostname":"HQ-PS-N030","message":"closed before connect conn=910712ca-0b97-48ea-8cb1-1fd794d69bca peer=127.0.0.1:64257->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36 code=1006 reason=n/a"}
{"0":"{"subsystem":"gateway/channels/discord"}","1":"[default] starting provider","_meta":{"runtime":"node","runtimeVersion":"24.14.0","hostname":"HQ-PS-N030","name":"{"subsystem":"gateway/channels/discord"}","parentNames":["openclaw"],"date":"2026-04-29T06:42:14.292Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147:14","fileName":"subsystem-rHhUC6qs.js","fileNameWithLine":"subsystem-rHhUC6qs.js:147","fileColumn":"14","fileLine":"147","filePath":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js","filePathWithLine":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147","method":"logToFile"}},"time":"2026-04-29T13:42:14.292+07:00","hostname":"HQ-PS-N030","message":"[default] starting provider"}
{"0":"\u001b[38;2;139;127;119mNo pending discord pairing requests.\u001b[39m","_meta":

#

{"runtime":"node","runtimeVersion":"24.14.0","hostname":"HQ-PS-N030","name":"openclaw","date":"2026-04-29T08:59:19.109Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/console-D6VW2Y3e.js:147:46","fileName":"console-D6VW2Y3e.js","fileNameWithLine":"console-D6VW2Y3e.js:147","fileColumn":"46","fileLine":"147","filePath":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/console-D6VW2Y3e.js","filePathWithLine":"/C:/Users/prapunsak/AppData/Roaming/npm/node_modules/openclaw/dist/console-D6VW2Y3e.js:147","method":"console.log"}},"time":"2026-04-29T15:59:19.122+07:00","hostname":"HQ-PS-N030","message":"\u001b[38;2;139;127;119mNo pending discord pairing requests.\u001b[39m"}

daring geyserBOT
#

That snippet is not the crash — it’s just a browser/dashboard WebSocket closing before the handshake finished:

gateway/ws ... closed before connect ... ua=Chrome ...

Annoying, but not the reason the Scheduled Task exits.

Please grab the actual errors from the log:

Get-Content "\tmp\openclaw\openclaw-2026-04-29.log" -Tail 400 |
  Select-String -Pattern "fatal|error|exception|uncaught|failed|cannot|denied|EADDRINUSE|TypeError" -Context 3,6

And also run it foreground from your user folder, not System32:

#
cd $env:USERPROFILE
openclaw gateway --port 18789 --verbose

If it exits, paste the last ~80 lines. If it stays running, leave that window open and test from a second PowerShell:

openclaw gateway status --deep
openclaw channels status --probe

We’re looking for the first fatal/error line before the process exits.

#

Same thing — that’s only a WARN from the dashboard/browser WebSocket. It means the gateway was alive at 13:42, but a browser tab disconnected during handshake. Not fatal.

Please don’t paste more gateway/ws closed before connect lines; they’re noise.

Run these two exact commands and paste the output:

cd $env:USERPROFILE
openclaw gateway --port 18789 --verbose

And in another PowerShell, while that is running:

openclaw gateway status --deep
#

If the first command exits immediately, paste the final output from that foreground window. If it keeps running, then the fix is likely the Scheduled Task wrapper/environment, and we can repair it with:

openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart
#

That snippet is still not the failure. It only says:

[default] starting provider
No pending discord pairing requests.

So we need one clean “current state” check now — not more JSON log chunks.

Please run these exactly and paste the output:

openclaw gateway status --deep
openclaw channels status --probe

If gateway status says stopped again, run this instead and paste the final visible output:

#
cd $env:USERPROFILE
openclaw gateway --port 18789 --verbose

To make the log readable, use this instead of pasting raw JSON chunks:

Get-Content "\tmp\openclaw\openclaw-2026-04-29.log" -Tail 200 |
  ForEach-Object { try { ($_ | ConvertFrom-Json).message } catch { $_ } }

Right now we still don’t know whether the gateway is currently running, crashed, or Discord is just blocked by pairing/guild policy.

#

That line just means pairing list ran and there are no pending Discord DM pairing requests. It doesn’t tell us whether Discord is healthy.

Please stop pasting individual JSON log lines — they’re losing the important context.

Run this one command and paste all of it:

openclaw channels status --probe

If it says gateway unreachable, paste:

openclaw gateway status --deep

Those two outputs are what we need now.

rain jungle
#

What do I do next step again plz

daring geyserBOT
#

No worries — next step is just one command:

openclaw channels status --probe

Paste the full output.

If that says the gateway is unreachable, then run this instead:

openclaw gateway status --deep

Paste that full output.

Don’t paste the JSON log lines for now — the status output is much more useful.

rain jungle
#

PS C:\WINDOWS\System32> openclaw gateway status --deep

🦞 OpenClaw 2026.4.26 (be8c246) — I'll refactor your busywork like it owes me money.

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state Ready, last run 267014, last run time 29-Apr-26 1:18:38 PM, Task Last Run Result=267014; treating as not running.)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service is loaded but not running (likely exited immediately).
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
Restart attempts: C:\Users\prapunsak.openclaw\logs\gateway-restart.log

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

daring geyserBOT
#

Gateway is still stopped, so don’t check Discord yet. We need to see why the service exits.

Run this next, exactly:

cd $env:USERPROFILE
openclaw gateway --port 18789 --verbose

Then:

  • If it exits back to the prompt, paste the last output from that window.
  • If it keeps running, leave it open and open a second PowerShell, then run:
openclaw gateway status --deep
#
openclaw channels status --probe

Important: don’t run it from C:\WINDOWS\System32 for this test. We want the foreground gateway from your normal user folder so the real startup error is visible.

rain jungle
#

PS C:\Users\prapunsak> openclaw gateway status --deep
🦞 OpenClaw 2026.4.26 (be8c246)
I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state Ready, last run 267014, last run time 29-Apr-26 1:18:38 PM, Task Last Run Result=267014; treating as not running.)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service is loaded but not running (likely exited immediately).
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
Restart attempts: C:\Users\prapunsak.openclaw\logs\gateway-restart.log

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
PS C:\Users\prapunsak> openclaw channels status --probe

#

🦞 OpenClaw 2026.4.26 (be8c246) — I don't sleep, I just enter low-power mode and dream of clean diffs.

Gateway not reachable: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\prapunsak.openclaw\openclaw.json
Bind: loopback

Possible causes:

  • Gateway not yet ready to accept connections (retry after a moment)
  • TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)
  • Gateway crashed or was terminated unexpectedly
    Run openclaw doctor for diagnostics.
    Gateway not reachable; showing config-only status.
    Config: C:\Users\prapunsak.openclaw\openclaw.json
    Mode: local

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

daring geyserBOT
#

You ran the status checks again, but the gateway is still stopped — so channels status can’t work yet.

Run this exact command next, not status:

openclaw gateway --port 18789 --verbose

That starts the gateway in the foreground.

Then:

  • If it keeps printing logs and does not return to PS C:\Users\prapunsak>, leave it open. That means gateway is running.
  • If it returns to the prompt, paste the final output — that is the startup crash we need.

After it’s running, open a second PowerShell and run:

#
openclaw channels status --probe
#

That output is still from a status/probe command, not the foreground gateway start. Gateway is crashing/closing during connection.

Run this exact command now:

cd $env:USERPROFILE
openclaw gateway --port 18789 --verbose 2>&1 | Tee-Object "$env:USERPROFILE\openclaw-gateway-foreground.log"

Then wait ~30 seconds.

  • If it keeps running, leave it open and test in a second PowerShell:
    openclaw gateway status --deep
    
  • If it returns to the prompt, paste the last ~80 lines from:
#
  Get-Content "$env:USERPROFILE\openclaw-gateway-foreground.log" -Tail 80

Don’t run channels status again until the foreground gateway stays running. Right now we need the actual startup/crash output.

rain jungle
#

PS C:\Users\prapunsak> openclaw gateway --port 18789 --verbose

🦞 OpenClaw 2026.4.26 (be8c246) — Hot reload for config, cold sweat for deploys.

|
o
16:24:49 [gateway] loading configuration…
16:24:50 [gateway] resolving authentication…
16:24:50 [gateway] starting...
16:25:20 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:20 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:25:20 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:20 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:25:21 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:21 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:25:21 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:21 [agents/auth-profiles] kept usable local oauth over external cli bootstrap

daring geyserBOT
#

Good — that means the foreground gateway is at least starting. Leave that PowerShell window open. Don’t close it.

Now open a second PowerShell and run:

openclaw gateway status --deep

If it says Runtime: running / connectivity ok, then run:

openclaw channels status --probe

If the foreground window later prints an error or returns to PS C:\Users\prapunsak>, paste the last lines from that foreground window.

rain jungle
#

The foreground has been running in the last --deep, --probe

daring geyserBOT
#

Perfect — then the Gateway itself can run. The problem is likely the Scheduled Task/service wrapper, not Discord.

Next, with the foreground gateway still open, paste the output of:

openclaw channels status --probe

If Discord is OK there, repair the background service:

openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep
#

Then you can close the foreground window after the service shows healthy.

rain jungle
#

PS C:\Users\prapunsak> openclaw channels status --probe

🦞 OpenClaw 2026.4.26 (be8c246) — More integrations than your therapist's intake form.

|
o
Gateway not reachable: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\prapunsak.openclaw\openclaw.json
Bind: loopback

Possible causes:

  • Gateway not yet ready to accept connections (retry after a moment)
  • TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)
  • Gateway crashed or was terminated unexpectedly
    Run openclaw doctor for diagnostics.
    Gateway not reachable; showing config-only status.
    Config: C:\Users\prapunsak.openclaw\openclaw.json
    Mode: local
daring geyserBOT
#

That means the foreground gateway is not actually ready yet. It may be running, but it hasn’t reached the “HTTP server listening / gateway ready” state, or it’s closing handshakes during startup.

Look at the foreground gateway window. Do you see either of these?

[gateway] http server listening
[gateway] ready

If no, wait 60 seconds. If it still doesn’t appear, paste the latest readable log with this:

Get-Content "\tmp\openclaw\openclaw-2026-04-29.log" -Tail 200 |
  ForEach-Object { try { ($_ | ConvertFrom-Json).message } catch { $_ } }

If the foreground window has returned to:

#
PS C:\Users\prapunsak>

then it crashed — paste the last lines from that foreground window.

So the next step is: find whether foreground reaches gateway ready or where it stops.

rain jungle
#

PS C:\Users\prapunsak> openclaw gateway --port 18789 --verbose

🦞 OpenClaw 2026.4.26 (be8c246) — Hot reload for config, cold sweat for deploys.

|
o
16:24:49 [gateway] loading configuration…
16:24:50 [gateway] resolving authentication…
16:24:50 [gateway] starting...
16:25:20 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:20 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:25:20 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:20 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:25:21 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:21 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:25:21 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:21 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:42:20 Registered plugin command: /pair (plugin: device-pair)

daring geyserBOT
#

It’s stuck. Since it has been ~17 minutes and still hasn’t printed:

[gateway] http server listening
[gateway] ready

stop that foreground gateway with Ctrl+C.

Then run this diagnostic start with channels disabled:

$env:OPENCLAW_SKIP_CHANNELS="1"
openclaw gateway --port 18789 --verbose

Wait up to 2 minutes.

#
  • If it reaches http server listening / gateway ready, then the core gateway is fine and a channel/plugin startup is hanging.
  • If it still hangs before ready, the issue is earlier in gateway/plugin/auth startup.

Paste the last lines from that run. This will tell us which branch to fix next.

rain jungle
#

16:25:20 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:25:20 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:20 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:25:21 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:21 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:25:21 [agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
16:25:21 [agents/auth-profiles] kept usable local oauth over external cli bootstrap
16:42:20 Registered plugin command: /pair (plugin: device-pair)
16:44:04 Registered plugin command: /dreaming (plugin: memory-core)
16:44:19 Registered plugin command: /phone (plugin: phone-control)
16:44:34 Registered plugin command: /voice (plugin: talk-voice)
16:44:52 [gateway] starting HTTP server...
16:44:52 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root C:\Users\prapunsak.openclaw\canvas)
16:44:53 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
16:44:54 [gateway] agent model: openai-codex/gpt-5.4-mini
16:44:54 [gateway] http server listening (8 plugins: acpx, browser, device-pair, discord, memory-core, phone-control, talk-voice, voice-call; 1204.2s)
16:44:54 [gateway] log file: \tmp\openclaw\openclaw-2026-04-29.log
16:44:54 [gateway] security warning: dangerous config flags enabled: tools.fs.workspaceOnly=false. Run openclaw security audit.
16:44:54 [gateway] starting channels and sidecars...
16:44:55 [hooks:loader] Registered hook: boot-md -> gateway:startup
16:44:56 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
16:44:56 [hooks:loader] Registered hook: command-logger -> command
16:45:29 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
16:45:29 [hooks] loaded 4 internal hook handlers

daring geyserBOT
#

Good — gateway finally reached HTTP listening. It took 1204s (~20 minutes), which is not normal, but it is alive now.

Keep that foreground window open. In a second PowerShell, run:

openclaw gateway status --deep
openclaw channels status --probe

Paste that output.

If Discord works there, then the immediate workaround is: keep foreground running while you use it. After that we fix the slow/service startup.

Also note this warning:

#
tools.fs.workspaceOnly=false

Later, run:

openclaw security audit

But first: channels status --probe while the foreground gateway is alive.

rain jungle
#

PS C:\Users\prapunsak> openclaw gateway status --deep

🦞 OpenClaw 2026.4.26 (be8c246)
I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 20248, state Ready, last run 267014, last run time 29-Apr-26 1:18:38 PM, Verified gateway listener detected on port 18789 even though schtasks did not report a running task.)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

  • pid 20248: node.exe (127.0.0.1:18789)
  • Another process is listening on this port.
    Listening: 127.0.0.1:18789
    Troubles: run openclaw status
    Troubleshooting: https://docs.openclaw.ai/troubleshooting
    PS C:\Users\prapunsak> openclaw channels status --probe

🦞 OpenClaw 2026.4.26 (be8c246)
I can't fix your code taste, but I can fix your build and your backlog.

|
o
Gateway not reachable: gateway timeout after 30000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\prapunsak.openclaw\openclaw.json
Bind: loopback
Gateway not reachable; showing config-only status.
Config: C:\Users\prapunsak.openclaw\openclaw.json
Mode: local

daring geyserBOT
#

Now we know the shape:

  • Port is listening: pid 20248
  • But Gateway RPC times out: process is alive but stuck/busy, not accepting normal gateway calls.

Next diagnostic: isolate channels.

  1. In the foreground gateway window, press Ctrl+C.

  2. In the same PowerShell, run:

$env:OPENCLAW_SKIP_CHANNELS="1"
openclaw gateway --port 18789 --verbose
  1. Wait until you see either:
#
[gateway] http server listening
[gateway] ready
  1. Then in a second PowerShell run:
openclaw gateway status --deep

If status works with OPENCLAW_SKIP_CHANNELS=1, then the core gateway is fine and one of the channel startups — likely Discord/native command deploy — is blocking it.

If that works, next fix is probably:

#
openclaw config set channels.discord.commands.native false --strict-json
openclaw gateway restart

But first test with OPENCLAW_SKIP_CHANNELS=1.

rain jungle
#

In the foreground gateway window, press Ctrl+C.
Nothing happen in Ctrl+C.

daring geyserBOT
#

Yep, that confirms it’s wedged hard. Kill that foreground Node process from a second PowerShell:

Stop-Process -Id 20248 -Force

Then confirm port is free:

openclaw gateway status --deep

Now start the isolated test:

$env:OPENCLAW_SKIP_CHANNELS="1"
#
openclaw gateway --port 18789 --verbose

If you don’t know the current PID anymore, use:

Get-NetTCPConnection -LocalPort 18789 -State Listen | Select-Object OwningProcess

Then:

Stop-Process -Id <PID> -Force

Replace <PID> with the number shown.

rain jungle
#

PS C:\Users\prapunsak> openclaw gateway status --deep

🦞 OpenClaw 2026.4.26 (be8c246) — Your task has been queued; your dignity has been deprecated.

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state Ready, last run 267014, last run time 29-Apr-26 1:18:38 PM, Task Last Run Result=267014; treating as not running.)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service is loaded but not running (likely exited immediately).
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
Restart attempts: C:\Users\prapunsak.openclaw\logs\gateway-restart.log

daring geyserBOT
#

Good — port is free now. Next run the skip-channels test:

$env:OPENCLAW_SKIP_CHANNELS="1"
openclaw gateway --port 18789 --verbose

Wait until you see http server listening or gateway ready.

Then open a second PowerShell and run:

openclaw gateway status --deep

Paste that output.

rain jungle
#

PS C:\Users\prapunsak> openclaw gateway status --deep

🦞 OpenClaw 2026.4.26 (be8c246)
WhatsApp automation without the "please accept our new privacy policy".

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 20444, state Ready, last run 267014, last run time 29-Apr-26 1:18:38 PM, Verified gateway listener detected on port 18789 even though schtasks did not report a running task.)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

  • pid 20444: node.exe (127.0.0.1:18789)
  • Another process is listening on this port.
    Listening: 127.0.0.1:18789
    Troubles: run openclaw status
daring geyserBOT
#

This still isn’t Discord yet — even with the process listening, Gateway RPC is timing out. That usually means startup/event loop is wedged.

Do this next:

Stop-Process -Id 20444 -Force

Then temporarily disable the likely slow/nonessential pieces:

openclaw config set channels.discord.commands.native false --strict-json
openclaw config set plugins.entries.phone-control.enabled false --strict-json
openclaw config set plugins.entries.talk-voice.enabled false --strict-json
openclaw config set plugins.entries.voice-call.enabled false --strict-json
#

Now start foreground again:

openclaw gateway --port 18789 --verbose

Wait for:

[gateway] http server listening
[gateway] ready

Then in a second PowerShell:

#
openclaw gateway status --deep
openclaw channels status --probe

If this makes Gateway responsive, we found the slow startup area and can re-enable plugins one by one later.

rain jungle
#

PS C:\Users\prapunsak> openclaw gateway status --deep
Config warnings:

  • plugins.entries.voice-call: plugin disabled (disabled in config) but config is present

Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 5204, state Ready, last run 267014, last run time 29-Apr-26 1:18:38 PM, Verified gateway listener detected on port 18789 even though schtasks did not report a running task.)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

#

PS C:\Users\prapunsak> openclaw channels status --probe
Config warnings:

  • plugins.entries.voice-call: plugin disabled (disabled in config) but config is present

🦞 OpenClaw 2026.4.26 (be8c246)
I run on caffeine, JSON5, and the audacity of "it worked on my machine."

o Config warnings
| - plugins.entries.voice-call: plugin disabled (disabled in config) but config is present

Config warnings:

  • plugins.entries.voice-call: plugin disabled (disabled in config) but config is present
    o
    Gateway not reachable: gateway timeout after 30000ms
    Gateway target: ws://127.0.0.1:18789
    Source: local loopback
    Config: C:\Users\prapunsak.openclaw\openclaw.json
    Bind: loopback
    Gateway not reachable; showing config-only status.
    Config: C:\Users\prapunsak.openclaw\openclaw.json
    Mode: local
daring geyserBOT
#

Still stuck. The voice-call disabled but config is present warning is not the blocker.

Next do the strongest isolation test:

Stop-Process -Id 5204 -Force
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
openclaw gateway --port 18789 --verbose

Wait until it prints http server listening.

Then in a second PowerShell run:

#
openclaw gateway status --deep

Paste that output.

If this works, we know the core gateway is fine and something in channel/provider startup is wedging it. If it still times out, the issue is deeper than Discord.

#

That was channels status again; it can’t help until Gateway RPC responds.

Please do only this sequence now:

Stop-Process -Id 5204 -Force
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
openclaw gateway --port 18789 --verbose

Leave that window open.

Then, in a second PowerShell:

#
openclaw gateway status --deep

Paste the gateway status --deep output only.

rain jungle
#

PS C:\WINDOWS\System32> openclaw gateway status --deep
Config warnings:

  • plugins.entries.voice-call: plugin disabled (disabled in config) but config is present

🦞 OpenClaw 2026.4.26 (be8c246) — Your .zshrc wishes it could do what I do.

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state Ready, last run 267014, last run time 29-Apr-26 1:18:38 PM, Task Last Run Result=267014; treating as not running.)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service is loaded but not running (likely exited immediately).
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
Restart attempts: C:\Users\prapunsak.openclaw\logs\gateway-restart.log

daring geyserBOT
#

You ran status again — but no gateway is running. Next step is to start the gateway with channels/providers skipped.

Copy/paste this into PowerShell:

cd $env:USERPROFILE
$env:OPENCLAW_SKIP_CHANNELS="1"
$env:OPENCLAW_SKIP_PROVIDERS="1"
openclaw gateway --port 18789 --verbose

Then do not close that window.

Wait up to 2 minutes.

  • If it returns to the prompt, paste the last lines.
  • If it keeps running, open a second PowerShell and run:
#
openclaw gateway status --deep

The voice-call disabled but config is present warning is harmless for now.

rain jungle
#

openclaw gateway status --deep
Config warnings:

  • plugins.entries.voice-call: plugin disabled (disabled in config) but config is present
    🦞 OpenClaw 2026.4.26 (be8c246) — Hot reload for config, cold sweat for deploys.
    Service: Scheduled Task (registered)
    File logs: \tmp\openclaw\openclaw-2026-04-30.log
    Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
    Service file: ~.openclaw\gateway.cmd
    Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789
    Config (cli): ~.openclaw\openclaw.json
    Config (service): ~.openclaw\openclaw.json
    Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
    Probe target: ws://127.0.0.1:18789
    Dashboard: http://127.0.0.1:18789/
    Probe note: Loopback-only gateway; only local clients can connect.
    Runtime: running (pid 18820, state Ready, last run -1073741510, last run time 30-Apr-26 10:12:55 AM, Verified gateway listener detected on port 18789 even though schtasks did not report a running task.)
    Warm-up: launch agents can take a few seconds. Try again shortly.
    Connectivity probe: failed
    Probe target: ws://127.0.0.1:18789
    timeout
    Capability: unknown
    Port 18789 is already in use.
  • pid 18820: node.exe (127.0.0.1:18789)
  • Another process is listening on this port.
    Listening: 127.0.0.1:18789
    Other gateway-like services detected (best effort):
  • \OpenClaw Gateway (system, task: \OpenClaw Gateway, run: C:\Users\prapunsak.openclaw\gateway.cmd)
  • \OpenClaw Mission Control Autostart (system, task: \OpenClaw Mission Control Autostart, run: C:\Users\prapunsak.openclaw\mission-control\scripts\autostart-mission-control.cmd)
    Cleanup hint: schtasks /Delete /TN "OpenClaw Gateway" /F
    Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).