#openclaw command idle
1 messages · Page 1 of 1 (latest)
connected | idle usually means it’s connected and waiting, not broken.
Quick check:
openclaw --version
openclaw status
openclaw gateway status
Inside the OpenClaw TUI, you can also type:
/status
If you send a simple message like “hi” and it stays idle with no reply/output, then check:
openclaw logs --follow
openclaw models status
openclaw doctor
Docs: https://docs.openclaw.ai/web/tui and https://docs.openclaw.ai/help/faq
Paste openclaw --version + openclaw status if you want me to sanity-check it.
what is the command that verbose the gateway status like each commad and update openclaw's decision making
I think you mean two different things:
To see Gateway status in more detail:
openclaw gateway status --deep
openclaw status --all
openclaw status --deep
To make OpenClaw show the commands/tools it’s using in chat/TUI:
/verbose on
For even more tool output:
/verbose full
Turn it back off with:
/verbose off
Docs: https://docs.openclaw.ai/tools/thinking and https://docs.openclaw.ai/help/faq
connected and writing, but api usage stopped
If it says connected | writing, grab logs while it’s stuck — that’s the best signal.
In the OpenClaw chat/TUI, run:
/status
/usage full
From another terminal:
openclaw --version
openclaw status --usage
openclaw models status
openclaw logs --follow
What to look for:
- No model/provider lines after your message → stuck before the API call.
- HTTP 401/403/429/etc. → auth/rate-limit/provider issue.
- Tool/command lines repeating → it may be busy in a tool, not using API tokens.
- Provider dashboards can lag, so trust
/status,/usage full, and logs first.
Paste openclaw --version + the redacted error part of openclaw logs --follow if you want me to read it. Don’t paste API keys/tokens.
01.png","/home/test/.openclaw/workspace/extracted_plans/plan-02.png","/home/test/.openclaw/workspace/extracted_plans/plan-03.png"]}
01:20:15+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 436ms conn=1589dc1f…6101 id=91be9967…b0e7
01:20:16+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 262ms conn=f8e4d57f…81b4 id=9b10d9b7…ddd0
01:20:50+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 279ms conn=53d483b9…5554 id=5c0cbe4d…18b5
01:21:24+00:00 error [tools] image failed: Failed to optimize image raw_params={"prompt":"Scan these 4 pages. Provide the title of each (Site Plan, Carpark, Floor 1, etc.). Find the parking bays in the Carpark plan and the Grease Interceptor Trap (GIT) in the Site Plan. Mark the page numbers. I am staying active.","images":["/home/test/.openclaw/workspace/lowres_plans/plan-01.jpg","/home/test/.openclaw/workspace/lowres_plans/plan-02.jpg","/home/test/.openclaw/workspace/lowres_plans/plan-03.jpg","/home/test/.openclaw/workspace/lowres_plans/plan-04.jpg"]}
01:21:24+00:00 error [tools] image failed: Failed to optimize image raw_params={"prompt":"Scan these 4 pages. Provide the title of each (Site Plan, Carpark, Floor 1, etc.). Find the parking bays in the Carpark plan and the Grease Interceptor Trap (GIT) in the Site Plan. Mark the page numbers. I am staying active.","images":["/home/test/.openclaw/workspace/lowres_plans/plan-01.jpg","/home/test/.openclaw/workspace/lowres_plans/plan-02.jpg","/home/test/.openclaw/workspace/lowres_plans/plan-03.jpg","/home/test/.openclaw/workspace/lowres_plans/plan-04.jpg"]}
01:21:28+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 58ms conn=8a85aecc…219f id=81f12d02…caf5
01:21:48+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 256ms conn=df1a9f9c…3a8d id=7610d842…1a96
01:23:56+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 398ms conn=1ddea12b…3d6e id=63bd22ec…ddec
Yep — this log points to a tool/image preprocessing failure, not the Gateway being disconnected.
The important line is:
error [tools] image failed: Failed to optimize image
So OpenClaw tried to send those plan images to the image tool, but failed while resizing/optimizing them before the model/API call. That explains why API usage stopped.
Try these quick checks:
openclaw --version
openclaw doctor
ls -lh /home/test/.openclaw/workspace/lowres_plans/
file /home/test/.openclaw/workspace/lowres_plans/plan-*.jpg
Workarounds:
- Retry with one image/page at a time.
- Re-export/convert the pages to simpler JPEGs, e.g. around 1600–2048px wide.
- If you have ImageMagick:
mkdir -p /home/test/.openclaw/workspace/clean_plans
magick '/home/test/.openclaw/workspace/lowres_plans/plan-01.jpg' -strip -resize '1600x1600>' -quality 80 '/home/test/.openclaw/workspace/clean_plans/plan-01.jpg'
Then retry with the cleaned image.
If file says any image is corrupt/weird, that’s probably it. If the images look normal, paste openclaw --version + any extra openclaw doctor output.
but it goes idle, even though i told it not to and to use other methods
That “idle” is probably after the run crashed/bailed, not OpenClaw choosing to stop because it ignored you.
Your log shows the image tool failed during preprocessing:
image failed: Failed to optimize image
Once that tool call fails, the active run can end, so the footer goes back to connected | idle.
Two useful checks:
/verbose full
/tools verbose
/status
/tools verbose matters because “use other methods” only works if the agent actually has other tools enabled, like exec, pdf, etc.
Try prompting very explicitly:
Continue the task, but do not use the image tool. First run read-only shell checks on the files, identify their sizes/types, then propose a fallback. If you need to convert files, ask before writing anything.
If it still silently goes idle after the tool failure, please grab:
openclaw --version
openclaw status --all
openclaw logs --follow
and file it as a GitHub issue if there’s no visible error reply — silent tool-failure → idle is worth reporting: https://github.com/openclaw/openclaw/issues
turning on autoloop
Careful with that — autoloop probably won’t fix this by itself.
If the failure is deterministic:
image failed: Failed to optimize image
then autoloop may just retry the same broken image-tool path over and over.
Safer prompt:
Loop at most 2 times. If the image tool fails again, stop using it. Use read-only shell/file checks instead: inspect file sizes/types, convert or suggest conversion steps, and continue from extracted/cleaned files. Stop and report the exact blocker if the same error repeats.
Also keep:
/verbose full
/status
on while testing, so you can see whether it actually changed strategy or just hit the same tool again.
how to fix it then, after every step, it goes idle and no usage on api as well. what would a normal agentic and processing heavyu process look like. even though it says its not stopping, it is still stopping
The fix is to stop treating “idle” as the problem — idle is just the final state after a step ends. The real problem is that the step is ending early because the local image tool fails before any API call:
image failed: Failed to optimize image
So API usage staying flat makes sense: it’s failing locally before the model sees the images.
A normal heavy agentic run usually looks like:
connected | writing/running- model API usage increases
- tool calls happen — shell, file reads, image/PDF, browser, etc.
- API usage may pause while tools run locally
- model runs again with tool results
- back to
connected | idlewhen the turn is done
In your case it’s more like:
- starts task
- tries image tool
- local optimizer fails
- run ends
- back to idle
To fix that specific loop:
/abort
/new
/verbose full
/usage full
Then retry with a prompt like:
Do not use the image tool yet. First inspect the files with read-only shell commands: file, identify if available, and ls -lh. If images need conversion, tell me the exact conversion command before continuing.
Then convert the images into clean JPEGs and use those:
mkdir -p /home/test/.openclaw/workspace/clean_plans
magick /home/test/.openclaw/workspace/lowres_plans/plan-01.jpg -strip -resize '1600x1600>' -quality 80 /home/test/.openclaw/workspace/clean_plans/plan-01.jpg
Repeat for the other pages, then point OpenClaw at clean_plans.
Also run:
openclaw --version
openclaw doctor
openclaw status --all
If clean JPEGs still fail with Failed to optimize image, that’s likely an OpenClaw image preprocessing bug or local image dependency issue. In that case, file it with the version + log snippet here: https://github.com/openclaw/openclaw/issues
no i have given it an very HEAVY task that involved this process
Got it — but even for a very heavy task, OpenClaw doesn’t continuously burn API usage the whole time.
A heavy run often alternates like this:
model call → tool work → model call → tool work → final answer
During tool work — image conversion, OCR, shell commands, PDF extraction, file processing — API usage can stay flat because it’s local processing. Then it should call the model again afterward.
What’s not normal is: it does one step, hits an error, then returns to idle with no visible explanation. In your log, the step that killed it is still:
image failed: Failed to optimize image
So the heavy task is being interrupted at the image-processing stage.
For a heavy plan-analysis job, I’d run it in phases instead of “do everything”:
Do this in phases. After each phase, report progress and wait for my next "continue".
Phase 1: inspect all source files with shell/file tools only. Do not use the image tool.
Phase 2: convert/extract pages into clean JPEG/PNG files.
Phase 3: analyze one page at a time.
Phase 4: summarize findings across pages.
If a tool fails, switch methods and explain the failure instead of ending silently.
If it still stops after each phase, check whether it’s actually finishing each turn normally. idle after a phase is expected if it’s waiting for your next continue.
Use:
/verbose full
/status
/tasks
and in another terminal:
openclaw logs --follow
If /tasks shows nothing and logs show a tool error right before idle, it’s not “still processing” — it bailed out of that turn.
how do i automate it to keep working on the task and keep trying?
autoloop settings, enabling autoloop and its potential risks
I don’t think there’s a documented OpenClaw setting literally called autoloop. If you mean “make it keep retrying automatically,” I’d do it with bounded automation, not infinite looping.
Safer setup:
- Turn on visibility:
/verbose full
/usage full
/status
/tasks
- Give it bounded retry instructions:
Keep working autonomously, but use a max of 3 attempts per blocker.
After each failure, change strategy.
Do not repeat the same failed tool call.
If image analysis fails, switch to shell/PDF/OCR/conversion methods.
Stop and report the exact blocker after 3 failed attempts.
- Enable loop protection in config:
{
tools: {
loopDetection: {
enabled: true,
warningThreshold: 10,
criticalThreshold: 20,
globalCircuitBreakerThreshold: 30
}
}
}
Then restart gateway.
Risks of autoloop / “keep trying forever”:
- burns API credits/tokens
- repeats the same broken tool call forever
- hits rate limits
- fills disk/logs with junk
- makes bad edits repeatedly if write/exec is enabled
- can hide the real blocker because it keeps retrying instead of reporting
For your case, I’d specifically tell it: “If image failed: Failed to optimize image happens once, do not call image again until files are converted/validated.” That avoids the exact loop you’re hitting.
it is still stopped. it does not continue working.
If it’s back at idle, there is no active run. OpenClaw will not keep working by itself unless you start a background/subagent/cron/heartbeat workflow. “Don’t stop” in a prompt does not create a daemon loop.
Check first:
/status
/tasks
or terminal:
openclaw tasks list --status running
If nothing is running, it already ended/failed.
For “keep trying,” use a bounded recurring cron/custom session pattern:
openclaw cron add \
--name "Continue plan analysis" \
--cron "*/5 * * * *" \
--session "session:plan-analysis" \
--message "Continue the plan-analysis task for one bounded iteration. Read/update a progress file. Do not repeat the same failed image call. If image optimization fails, switch to shell/PDF/OCR/conversion fallback. Stop after one iteration and report progress or blocker."
Then inspect with:
openclaw cron list
openclaw tasks list
openclaw logs --follow
But honestly: for your current issue, I’d first fix the failing image step. If every wake hits Failed to optimize image, automation will just keep waking into the same wall.
increasing watchdog timeout