#openclaw command idle

1 messages · Page 1 of 1 (latest)

rustic berry
#

given openclaw an process and at the bottom it shows connecte | idle, want to see if its broken or not

icy galeBOT
#

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

woven robinBOT
#

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:

rustic berry
#

what is the command that verbose the gateway status like each commad and update openclaw's decision making

woven robinBOT
#

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:

rustic berry
#

connected and writing, but api usage stopped

woven robinBOT
#

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.

rustic berry
#

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

woven robinBOT
#

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:

  1. Retry with one image/page at a time.
  2. Re-export/convert the pages to simpler JPEGs, e.g. around 1600–2048px wide.
  3. 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.

rustic berry
#

but it goes idle, even though i told it not to and to use other methods

woven robinBOT
#

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

rustic berry
#

turning on autoloop

woven robinBOT
#

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.

rustic berry
#

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

woven robinBOT
#

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:

  1. connected | writing/running
  2. model API usage increases
  3. tool calls happen — shell, file reads, image/PDF, browser, etc.
  4. API usage may pause while tools run locally
  5. model runs again with tool results
  6. back to connected | idle when the turn is done
#

In your case it’s more like:

  1. starts task
  2. tries image tool
  3. local optimizer fails
  4. run ends
  5. 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

rustic berry
#

no i have given it an very HEAVY task that involved this process

woven robinBOT
#

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.

rustic berry
#

how do i automate it to keep working on the task and keep trying?

#

autoloop settings, enabling autoloop and its potential risks

woven robinBOT
#

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:

  1. Turn on visibility:
/verbose full
/usage full
/status
/tasks
  1. 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.
  1. 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.

rustic berry
#

it is still stopped. it does not continue working.

woven robinBOT
#

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.

rustic berry
#

increasing watchdog timeout