openclaw - 💡(How to fix) Fix [Bug]: Poor UX for long-running background tasks + silent cron wake failures — abandoning droplet

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Title:

Body:

I've been running OpenClaw on a DigitalOcean 2vCPU/4GB droplet and hit enough friction today that I'm tearing it down. Costs aren't worth it for the experience. Sharing feedback in case it's useful.

Context: Asked agent (Yogui, main session) to install himalaya via cargo. Build took 11m 38s on this hardware. Agent tried to manage the wait gracefully and largely failed.

Issues observed:

  1. Cron self-wake with systemEvent payloads doesn't produce assistant turns. Agent set a recurring main-session cron (every 2 min) with a systemEvent payload to "check on the build and report status." Cron fired 12 times on schedule, each run completed in ~3ms with deliveryStatus: not-requested. No actual assistant turns were produced. Result: total radio silence for the user during the 11-min build. The agent thought it had set up automated check-ins; it had not. Silent failure mode.
  2. No good built-in pattern for "wait on a long background task and report progress." process poll caps at 30s. Spawning a subagent to poll feels heavy. Heartbeat is too coarse and not aware of the running task. The only thing that actually works is the user manually pinging the agent every few minutes to nudge it. That's not great.
  3. Mid-conversation model swaps degrade agentic loop quality. I switched the session model to gemini-2.5-flash mid-task. Gemini Flash failed to escalate a blocked sudo command — the exec returned a clear "password required" error and Flash just stopped sending any message at all rather than telling me. Opus/Sonnet handle this correctly. Flash is fine for Q&A but unreliable for agentic loops. Maybe worth a warning when a user switches to a lighter model mid-agentic-task, or model-specific guidance in the system prompt.
  4. Sudo dead-end UX. Agent has shell access but can't pass sudo prompts. When it hits one, the only recovery is "tell the user to SSH in and run it themselves." Smooth-ish, but feels like a gap. Some form of sudo elevation pass-through (with explicit per-command approval) would help a lot.

Suggested fixes / asks:

  • Fix or document the systemEvent cron wake behavior. If it can't produce real assistant turns in the target session, that's a footgun — either fix it or strip the option from the schema for main-session targets.
  • A first-class "watch this background exec and ping me when it finishes / every N minutes" primitive would solve a real pain point.
  • Surface deliveryStatus: not-requested more loudly so the agent realizes the wake fired silently.
  • Consider a per-channel/per-model capability descriptor so agents know "this model is bad at agentic loops, prefer escalation over silence."

Disposition: Going to delete the droplet — token costs + this friction aren't worth it for my use case right now. Maybe revisit later when these rough edges smooth out. Thanks for building the thing, just isn't there yet for me.

Error Message

command — the exec returned a clear "password required" error and Flash just stopped sending any message

Root Cause

Title:

Body:

I've been running OpenClaw on a DigitalOcean 2vCPU/4GB droplet and hit enough friction today that I'm tearing it down. Costs aren't worth it for the experience. Sharing feedback in case it's useful.

Context: Asked agent (Yogui, main session) to install himalaya via cargo. Build took 11m 38s on this hardware. Agent tried to manage the wait gracefully and largely failed.

Issues observed:

  1. Cron self-wake with systemEvent payloads doesn't produce assistant turns. Agent set a recurring main-session cron (every 2 min) with a systemEvent payload to "check on the build and report status." Cron fired 12 times on schedule, each run completed in ~3ms with deliveryStatus: not-requested. No actual assistant turns were produced. Result: total radio silence for the user during the 11-min build. The agent thought it had set up automated check-ins; it had not. Silent failure mode.
  2. No good built-in pattern for "wait on a long background task and report progress." process poll caps at 30s. Spawning a subagent to poll feels heavy. Heartbeat is too coarse and not aware of the running task. The only thing that actually works is the user manually pinging the agent every few minutes to nudge it. That's not great.
  3. Mid-conversation model swaps degrade agentic loop quality. I switched the session model to gemini-2.5-flash mid-task. Gemini Flash failed to escalate a blocked sudo command — the exec returned a clear "password required" error and Flash just stopped sending any message at all rather than telling me. Opus/Sonnet handle this correctly. Flash is fine for Q&A but unreliable for agentic loops. Maybe worth a warning when a user switches to a lighter model mid-agentic-task, or model-specific guidance in the system prompt.
  4. Sudo dead-end UX. Agent has shell access but can't pass sudo prompts. When it hits one, the only recovery is "tell the user to SSH in and run it themselves." Smooth-ish, but feels like a gap. Some form of sudo elevation pass-through (with explicit per-command approval) would help a lot.

Suggested fixes / asks:

  • Fix or document the systemEvent cron wake behavior. If it can't produce real assistant turns in the target session, that's a footgun — either fix it or strip the option from the schema for main-session targets.
  • A first-class "watch this background exec and ping me when it finishes / every N minutes" primitive would solve a real pain point.
  • Surface deliveryStatus: not-requested more loudly so the agent realizes the wake fired silently.
  • Consider a per-channel/per-model capability descriptor so agents know "this model is bad at agentic loops, prefer escalation over silence."

Disposition: Going to delete the droplet — token costs + this friction aren't worth it for my use case right now. Maybe revisit later when these rough edges smooth out. Thanks for building the thing, just isn't there yet for me.

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Title:

Body:

I've been running OpenClaw on a DigitalOcean 2vCPU/4GB droplet and hit enough friction today that I'm tearing it down. Costs aren't worth it for the experience. Sharing feedback in case it's useful.

Context: Asked agent (Yogui, main session) to install himalaya via cargo. Build took 11m 38s on this hardware. Agent tried to manage the wait gracefully and largely failed.

Issues observed:

  1. Cron self-wake with systemEvent payloads doesn't produce assistant turns. Agent set a recurring main-session cron (every 2 min) with a systemEvent payload to "check on the build and report status." Cron fired 12 times on schedule, each run completed in ~3ms with deliveryStatus: not-requested. No actual assistant turns were produced. Result: total radio silence for the user during the 11-min build. The agent thought it had set up automated check-ins; it had not. Silent failure mode.
  2. No good built-in pattern for "wait on a long background task and report progress." process poll caps at 30s. Spawning a subagent to poll feels heavy. Heartbeat is too coarse and not aware of the running task. The only thing that actually works is the user manually pinging the agent every few minutes to nudge it. That's not great.
  3. Mid-conversation model swaps degrade agentic loop quality. I switched the session model to gemini-2.5-flash mid-task. Gemini Flash failed to escalate a blocked sudo command — the exec returned a clear "password required" error and Flash just stopped sending any message at all rather than telling me. Opus/Sonnet handle this correctly. Flash is fine for Q&A but unreliable for agentic loops. Maybe worth a warning when a user switches to a lighter model mid-agentic-task, or model-specific guidance in the system prompt.
  4. Sudo dead-end UX. Agent has shell access but can't pass sudo prompts. When it hits one, the only recovery is "tell the user to SSH in and run it themselves." Smooth-ish, but feels like a gap. Some form of sudo elevation pass-through (with explicit per-command approval) would help a lot.

Suggested fixes / asks:

  • Fix or document the systemEvent cron wake behavior. If it can't produce real assistant turns in the target session, that's a footgun — either fix it or strip the option from the schema for main-session targets.
  • A first-class "watch this background exec and ping me when it finishes / every N minutes" primitive would solve a real pain point.
  • Surface deliveryStatus: not-requested more loudly so the agent realizes the wake fired silently.
  • Consider a per-channel/per-model capability descriptor so agents know "this model is bad at agentic loops, prefer escalation over silence."

Disposition: Going to delete the droplet — token costs + this friction aren't worth it for my use case right now. Maybe revisit later when these rough edges smooth out. Thanks for building the thing, just isn't there yet for me.

Steps to reproduce

try to install himalaya or in general use for a few days

Expected behavior

actions continue with automatic follow up not just constantly dropping the ball

Actual behavior

Drops the ball and looses context every few minutes

OpenClaw version

OpenClaw 2026.5.12 (commit f066dd2), running on Node v24.15.0.

Operating system

Windows 11

Install method

Follow openclaw instructions

Model

claude opus and tried to use the gemini 2.5 without success

Provider / routing chain

For this current turn: - Channel: webchat (direct conversation) - Session: agent:main:main (main agent session) - Model: anthropic/claude-opus-4-7 (via api-key auth profile, provider: anthropic) - Runtime: OpenClaw Pi Default - Execution: direct, elevated, thinking=medium - Host: ubuntu-s-2vcpu-4gb-nyc3-01 (this DigitalOcean droplet) Routing path: webchat client → OpenClaw gateway (port 18789) → main agent session → Anthropic API (Opus 4.7) → response back through the same chain to webchat. No proxy/router layer between the agent and Anthropic — it's a direct API call with the configured Anthropic key.

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Catastrophic, i am deleting this Open Claw instance

Additional information

No response

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

actions continue with automatic follow up not just constantly dropping the ball

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: Poor UX for long-running background tasks + silent cron wake failures — abandoning droplet