#How should I create this workflow ? Reseach from E-mail/Web > Analyze > Report > Send
1 messages · Page 1 of 1 (latest)
Have you gotten this resolved @rain jungle
Not yet
it’s not really a plug-and-play, you have to structure it properly in the upgrade
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
That would be very helpful
I saw this on the Github seems very interesting
https://github.com/aiming-lab/AutoResearchClaw
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 👍
Can you teach me?
@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
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.
2. Enable the core tools you need
For this workflow you usually want:
web_search/web_fetch— web researchbrowser— JS-heavy sites, logged-in sites, screenshots/PDF exportread/write/exec— create report filespdf— analyze PDFsmessage— send to Discord/Slack/etc.cronor webhooks — automation
Configure web search:
openclaw configure --section web
Check browser:
openclaw browser --browser-profile openclaw doctor
openclaw browser --browser-profile openclaw start
Docs:
https://docs.openclaw.ai/tools
https://docs.openclaw.ai/tools/web
https://docs.openclaw.ai/tools/browser
https://docs.openclaw.ai/tools/pdf
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
openclaw cron run <job-id>
openclaw cron runs --id <job-id>
Docs: https://docs.openclaw.ai/automation/cron-jobs
My recommended first version
Start with:
Web research → Markdown report → PDF → Discord send
Then add:
- PowerPoint generation
- Email draft/send approval
- Gmail-triggered automation
- Multi-agent/subagent research for bigger reports
That keeps the workflow debuggable instead of turning it into a giant mystery box on day one. 🦐
OpenClaw 2026.4.24 (cbcfdf6). My gateway is reachable but Discord is broken at this point. I already filed a bug report.
Got it — since Gateway is reachable but Discord is broken, I’d separate the workflow from the delivery channel for now.
Do this next
- 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.
- 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.
- 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>"
- 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.
Is this better than native ?https://github.com/vercel-labs/agent-browser
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)
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
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
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
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:
openclaw config get tools --json
openclaw config get agents.list --json
If you need to get unstuck fast, rolling back is reasonable:
openclaw update --tag 2026.4.23
openclaw gateway restart
Docs: https://docs.openclaw.ai/gateway/troubleshooting
Docs: https://docs.openclaw.ai/tools
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"}
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.
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
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.
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...
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.
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
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.
🦞 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
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
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
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.
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...
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
Docs for the relevant flow: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting 🦐
Sure but this will a paid service @rain jungle
Custom implementation can totally be paid work, but the OpenClaw recipe is shareable here:
-
Trigger
- Scheduled:
openclaw cron add ... - Gmail event:
openclaw webhooks gmail setup --account you@gmail.com - Manual: ask your agent in Discord/Telegram.
- Scheduled:
-
Research
- Use
web_fetchfor normal pages. - Use
browserfor login/JS-heavy sites. - Use Gmail/Gog or Gmail PubSub for inbox-driven workflows.
- Use
-
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.
-
Report
- Easiest: generate Markdown/HTML first.
- Convert to PDF/PPTX with local tools like
pandoc,LibreOffice, orpython-pptx. - Attach the generated file when sending.
- Convert to PDF/PPTX with local tools like
- Send
- Discord:
openclaw message send --channel discord --target "channel:<id>" --media report.pdf - Email: draft first, then require human approval before sending.
- Discord:
Minimal cron shape:
openclaw cron add \
--name "Daily research report" \
--cron "0 8 * * *" \
--tz "Asia/Bangkok" \
--session isolated \
--message "Research these sources, analyze changes, create a Markdown report, export PDF, then send the summary and attachment to Discord. Ask for approval before external email." \
--announce \
--channel discord \
--to "channel:<discord-channel-id>"
Docs: https://docs.openclaw.ai/automation/cron-jobs, https://docs.openclaw.ai/automation/taskflow, https://docs.openclaw.ai/tools/browser, https://docs.openclaw.ai/tools/web-fetch 🦐
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
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 🦐
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
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.
{"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..."}
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...: pressCtrl+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
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
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:
- 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/.
- If it’s still not listening after ~1–2 minutes, stop foreground with
Ctrl+Cand 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.
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
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
--devstarts: main config/state is causing the hang. - If
--devalso hangs: likely package/runtime regression on Windows.
Once done, unset trace if you want:
Remove-Item Env:OPENCLAW_GATEWAY_STARTUP_TRACE
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
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 repeatedagents/auth-profiles, noconfig.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.
Can you summarize again what I need to do next?
Sure — do these next, in order:
-
Stop the current foreground gateway
PressCtrl+C. -
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
- In a second PowerShell, check if it listens:
netstat -ano | findstr :18789
openclaw gateway status --deep
- If it works: one provider/channel/startup service is blocking. Run:
openclaw doctor --deep
openclaw doctor --fix
- 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 repeatsagents/auth-profiles, noconfig.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
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
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
PS C:\Windows> netstat -ano | findstr :18789
PS C:\Windows>
? like this?
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:
netstatempty = 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.
Gateway is live now but agent can't respond in openclaw and discord still show agent offline.
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 onlineOPENCLAW_SKIP_PROVIDERS=1→ agent/model responses may failOPENCLAW_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
openclaw channels status --probe
openclaw gateway diagnostics export --output "$env:TEMP\openclaw-diagnostics.zip"
Docs ladder: https://docs.openclaw.ai/channels/troubleshooting
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
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
Culprit:
Remove-Item Env:OPENCLAW_SKIP_CHANNELS -ErrorAction SilentlyContinue
$env:OPENCLAW_DISABLE_BUNDLED_PLUGINS="1"
openclaw gateway --port 18789 --verbose
PS C:\Windows> netstat -ano | findstr :18789
TCP 127.0.0.1:18789 0.0.0.0:0 LISTENING 22036
TCP [::1]:18789 [::]:0 LISTENING 22036
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=1makes gateway bind, but normal startup hangs.
File here: https://github.com/openclaw/openclaw/issues
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.
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
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
Your gateway looks mostly up — http server listening, Discord started, and browser control is listening.
Two things to fix/check:
- Please paste
openclaw --versionif this is still failing. - This warning matters:
For email/web automation, I’d run:dangerous config flags enabled: tools.fs.workspaceOnly=false
and avoid broad filesystem access unless you really need it.openclaw security audit
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
Recommended architecture:
- Research:
web_search/ browser / Gmail viagog - Analyze: agent or
llm-task - Report: generate Markdown first; convert to PDF/PPTX with a script/skill
- Send: Discord via
message/cron announce; email only behind approval
Docs:
https://docs.openclaw.ai/automation/cron-jobs
https://docs.openclaw.ai/automation/standing-orders
https://docs.openclaw.ai/tools/lobster
https://docs.openclaw.ai/channels/discord
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:
-
Check version/status
openclaw --version openclaw status --all -
Enable research inputs
- Web: configure a search provider:
openclaw configure --section web - Gmail/email trigger:
- Web: configure a search provider:
openclaw webhooks gmail setup --account your@email.com
```
-
Define the workflow in
AGENTS.mdor 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.
-
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
- Agent writes
-
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>"
- 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
openclaw gateway restart
Then use plain text commands/messages instead.
Also: your earlier log had tools.fs.workspaceOnly=false. For an email/web/report workflow, please run:
openclaw security audit
Once channels status --probe is clean, then set up the workflow with cron/Lobster. Docs:
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/gateway/configuration
https://docs.openclaw.ai/channels/discord
OpenClaw 2026.4.26 (be8c246)
Right now gateway is the main problem. Discord still not on
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:
- Discord REST/native command deploy is hanging
- 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.
Did I paste secret in this chat? or you meant openclaw channels status --probe?
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.
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
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.
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
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.
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.
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.
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"}
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.
What do I do next step again plz
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.
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
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.
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
Runopenclaw doctorfor 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).
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.
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
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.
The foreground has been running in the last --deep, --probe
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.
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
Runopenclaw doctorfor diagnostics.
Gateway not reachable; showing config-only status.
Config: C:\Users\prapunsak.openclaw\openclaw.json
Mode: local
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.
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)
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.
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
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.
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
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.
-
In the foreground gateway window, press Ctrl+C.
-
In the same PowerShell, run:
$env:OPENCLAW_SKIP_CHANNELS="1"
openclaw gateway --port 18789 --verbose
- Wait until you see either:
[gateway] http server listening
[gateway] ready
- 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.
In the foreground gateway window, press Ctrl+C.
Nothing happen in Ctrl+C.
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.
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
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.
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
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.
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.
- pid 5204: 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
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
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.
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
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.
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).