#SW Development with OpenClaw & Claude-CLI

1 messages · Page 1 of 1 (latest)

barren mason
#

Using OpenClaw with Claude CLI & Discord.. It keeps timing out when I give it "real work" to do.. I've instructed it to use Subagents, and that helps but it still seems to be dropping the callbacks so I get no notification when work is done.. And it keeps getting into a state where it's just "stuck" and I have to abandon the whole thread/session and start over because it won't respond.

Anyone else seeing this? Is there a known way to resolve it?

tiny oceanBOT
#

This does line up with the long-running/ACP/subagent path, yeah. A few things I’d check first:

  1. First sanity check: what does openclaw --version show? There have been fixes around subagent/session delivery recently, so version matters a lot.

  2. If this is Claude CLI through ACP/acpx, check the ACP timeout. The acpx embedded runtime default is 120s, which can be too short for “real work”. You can raise it, then restart the gateway:

openclaw config set plugins.entries.acpx.config.timeoutSeconds 300
openclaw gateway restart

Docs: https://docs.openclaw.ai/tools/acp-agents-setup#runtime-timeout-configuration

  1. For child work, make sure the parent agent is actually using the subagent completion flow, not just spawning and continuing forever. The important bit is: after spawning required child work, it should use sessions_yield so completion events can wake the parent. If your prompt only says “use subagents” but not “yield/wait for completion events”, some models keep talking/polling instead of letting the callback arrive.
    Docs: https://docs.openclaw.ai/tools/subagents

  2. From the stuck thread, try these before abandoning it:

#
/status
/tasks
/subagents list

If something is wedged, /kill all can clear active subagents/runs for that session.

  1. If you’re using Discord thread-bound Claude/ACP sessions, verify thread binding is enabled for Discord, especially channels.discord.threadBindings.enabled and channels.discord.threadBindings.spawnSessions if you expect child threads/sessions.
    Docs: https://docs.openclaw.ai/tools/acp-agents#spawn-bind-and-thread-modes

If you can paste openclaw --version plus the relevant timeout/log lines from openclaw status --all / openclaw logs --follow, we can usually tell whether this is an ACP timeout, a stuck parent run, or a delivery-route issue. And for “anyone else seeing it?” human experience, also worth asking in #users-helping-users.

barren mason
#

Running OpenClaw 2026.5.7 (eeef486)

tiny oceanBOT
#

Thanks — that helps. 2026.5.7 (eeef486) is right before a bunch of subagent/ACP/delivery fixes on main, including fixes around fallback timeout response delivery, subagent orchestration, target precedence, and ACP lifecycle errors.

So I’d treat this as likely known-ish/recently improved, not just your prompt being bad.

What I’d try:

  1. If you can run from source, update to current main and retest the same workflow. If you’re on npm/global release, you may need the next release for those fixes.

  2. Raise ACP timeout if Claude CLI is doing real coding work:

openclaw config set plugins.entries.acpx.config.timeoutSeconds 300
openclaw gateway restart

If jobs can legitimately run longer, use 600.

  1. Add this to the agent’s instruction, not just “use subagents”:
#
For long work, spawn subagents, then call sessions_yield after spawning required child work. Do not poll subagents in a loop waiting for completion. When completion events arrive, summarize them back to the user.

That matters because completion is push-based; if the parent stays busy or wanders off, it can look like callbacks disappeared.

  1. In a stuck thread, run:
/status
/tasks
/subagents list

If it shows active children/runs that won’t finish, clear them with:

/kill all

Then continue in the same thread if it wakes up.

#

If this still reproduces on current main, I’d file it with logs here: https://github.com/openclaw/openclaw/issues
Useful bits: openclaw --version, whether this is /acp spawn or native subagents, openclaw status --all, and the log lines around the timeout/completion delivery.

barren mason
#

Your agent instruction bit helped but it's still happening often that it doesn't use subagents and times out.. Any other things I can try ? I would rather avoid updating to main to introduce other instability problems.

tiny oceanBOT
#

Yeraze, yep — without jumping to main, I’d try these in order:

  1. Confirm the subagent tools are actually available in that Discord thread/session:
    /tools

You want to see sessions_spawn, sessions_yield, and subagents. If they’re missing, the model can’t delegate no matter what your agent instructions say. For a custom/light tool profile, add something like:

tools: {
  alsoAllow: ["sessions_spawn", "sessions_yield", "subagents"]
}

or use a coding/full-ish tool profile for that agent.

  1. If your installed version supports it, make delegation stronger in config:
#
agents: {
  defaults: {
    subagents: {
      delegationMode: "prefer",
      maxConcurrent: 4,
      runTimeoutSeconds: 1800
    }
  }
}

Important caveat: delegationMode: "prefer" is prompt guidance, not a hard scheduler. It nudges the main agent to spawn children for anything non-trivial, but the model can still choose badly.

  1. Raise the parent turn timeout too, because the parent still needs enough time to decide to spawn + yield. Depending on where you invoke it, check agents.defaults.timeoutSeconds, the channel/account timeout, or CLI openclaw agent ... --timeout. If the parent dies before it calls sessions_spawn, no child ever starts.

  2. For especially long tasks, be explicit in the user prompt. Annoying but effective:

#

Spawn subagents first, then yield. Do not do the investigation in the parent session.

That tends to work better than a general standing instruction.

  1. Use /subagents spawn ... manually as the escape hatch for known-long work. That bypasses the model’s “should I delegate?” decision entirely.

Docs: https://docs.openclaw.ai/tools/subagents and https://docs.openclaw.ai/help/faq

Also: can you paste your openclaw --version? Some of the newer subagent knobs are version-sensitive, so I don’t want to accidentally give you a main-only config key. 🦞

barren mason
#

I'm running OpenClaw 2026.5.7 (eeef486)

tiny oceanBOT
#

Ah, thanks — on 2026.5.7 specifically, ignore my delegationMode: "prefer" suggestion. I checked that tag and that knob is not in 2026.5.7; it’s newer/main-side. Sorry, good catch 🦞

For 2026.5.7, the practical things I’d try are:

agents: {
  defaults: {
    timeoutSeconds: 1200,
    subagents: {
      maxConcurrent: 8,
      runTimeoutSeconds: 1800
    }
  }
},
tools: {
  alsoAllow: ["sessions_spawn", "sessions_yield", "subagents"]
#
}

Then in the same Discord thread run:

/tools

and verify those three tools actually appear. If sessions_yield is missing, the agent may spawn but then keep working/polling badly instead of yielding for completion.

The most effective non-main workaround is making the standing instruction more forceful and operational, e.g. in the agent instruction/AGENTS.md:

For any task likely to require more than 2 tool calls, web/code searching, builds/tests, or more than ~60 seconds: spawn one or more subagents first, then call sessions_yield. Do not perform the long investigation in the parent session. The parent should only coordinate and summarize subagent results.
#

Also, for known-long requests, phrase the user ask as:

Spawn subagents first and yield. Do not investigate in the parent session.

That bypasses a lot of model dithering. If it still regularly refuses to delegate even with tools visible, that’s basically model/tool-use behavior rather than a config enforcement issue in 2026.5.7.

barren mason
#

I just upgraded to the new official release (5.12 I think), and my claude instance is no longer using the claude CLI, instead reverting to API. How do I restore CLI usage?

tiny oceanBOT
# barren mason I just upgraded to the new official release (5.12 I think), and my claude instan...

First thing: please check the exact version with openclaw --version since 5.12-ish covers a few builds.

To restore Claude CLI reuse, rerun the CLI auth wiring on the gateway host:

claude auth status --text
openclaw models auth login --provider anthropic --method cli --set-default
openclaw models status

That models auth login ... --method cli --set-default step is the important one: it tells OpenClaw to switch Anthropic model selection to the local claude-cli backend and stores the matching OpenClaw auth profile. If claude is not on the gateway service PATH, either fix PATH or set agents.defaults.cliBackends.claude-cli.command in config to the real Claude binary path.

If this specific agent/thread still uses API after that, check whether it has a per-agent or per-session model override pinned to anthropic/...; CLI-backed models use the claude-cli/... provider prefix.

Docs:
https://docs.openclaw.ai/gateway/authentication
https://docs.openclaw.ai/gateway/cli-backends

barren mason
#

I did that , but it now shows 2 antropic auths: One API and one CLI. How do I remove the API and go full CLI:


Config        : ~/.openclaw/openclaw.json
Agent dir     : ~/.openclaw/agents/main/agent
Default       : anthropic/claude-opus-4-6
Fallbacks (0) : -
Image model   : -
Image fallbacks (0): -
Aliases (2)   : opus -> anthropic/claude-opus-4-7, sonnet -> anthropic/claude-sonnet-4-6
Configured models (6): anthropic/claude-opus-4-7, anthropic/claude-sonnet-4-6, anthropic/claude-opus-4-6, anthropic/claude-opus-4-5, anthropic/claude-sonnet-4-5, anthropic/claude-haiku-4-5

Auth overview
Auth store    : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env     : off
Providers w/ OAuth/tokens (2): anthropic (1), claude-cli (1)
- anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=*** api_key=0) | anthropic:claude-cli=OAuth
- claude-cli effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=*** api_key=0) | anthropic:claude-cli=OAuth | synthetic=plugin-owned | source=Claude CLI native auth
- openai effective=env:sk-svcac...QsbAvtYA | env=sk-svcac...QsbAvtYA | source=env: OPENAI_API_KEY

OAuth/token status
- claude-cli
  - anthropic:claude-cli expiring expires in 4h
tiny oceanBOT
# barren mason I did that , but it now shows 2 antropic auths: One API and one CLI. How do I re...

That output does not show an Anthropic API auth. It’s the same anthropic:claude-cli OAuth profile being surfaced twice:

  • anthropic ... anthropic:claude-cli=OAuth
  • claude-cli ... anthropic:claude-cli=OAuth | synthetic=plugin-owned | source=Claude CLI native auth

The reason it’s still using API is higher up:

Default : anthropic/claude-opus-4-6
Configured models: anthropic/...

For full CLI routing, the default model needs to be claude-cli/..., not anthropic/....

Try: