📱 Client Type
Desktop App (Electron)
💻 Operating System
macOS (execution device: Mac mini, Apple Silicon), Windows (chat client)
📦 Deployment Platform
Official Cloud
📌 Version
Desktop 2.2.18, lh CLI 0.0.55
🐛 What happened?
When chatting with an OpenClaw agent (connected via "Connect External Agents" → bound to a device), sending any message fails immediately with:
Task failed (exit code: 1)
No other error output is shown in the UI.
Root cause (confirmed by manual reproduction on the execution device):
LobeHub spawns OpenClaw with a hardcoded --local flag (apps/cli/src/tools/heteroTask.ts):
const openclawArgs = [
'agent', '--agent', openclawAgent,
'--session-id', sessionKey,
'--message', enrichedPrompt,
'--local',
];
When the OpenClaw gateway is already running on the device (the normal setup for a self-hosted OpenClaw instance — it holds the session store lock), openclaw agent ... --local tries to open the session store directly, conflicts with the gateway's lock, and exits with code 1 immediately.
Reproduced manually on the execution device:
# Fails with exit code 1 while gateway is running:
openclaw agent --agent main --session-id debug-1 --message "hello" --local
# Works fine (talks to the running gateway instead):
openclaw agent --agent main --session-id debug-1 --message "hello"
Two side problems that made this hard to diagnose:
- The child process is spawned with
stdio: 'ignore', so OpenClaw's actual stderr (the real error explaining the session lock conflict) is discarded — the user only sees the bare Task failed (exit code: 1).
- The in-code comment already acknowledges a related failure mode ("a concurrent process holding the session lock will cause the new one to exit with code 1"), but there is no handling for the much more common case: the user's own long-running gateway.
📷 How to reproduce it?
- On a device (e.g. Mac mini), install OpenClaw, complete onboarding, and run
openclaw gateway (keep it running, as OpenClaw is designed to).
- In LobeHub, create an agent via Connect External Agents → OpenClaw, bound to that device.
- Send any message to the agent.
- Observe:
Task failed (exit code: 1).
Expected behavior
LobeHub should work with a running OpenClaw gateway, e.g. by:
- Detecting a running gateway (e.g.
openclaw health / gateway port probe) and omitting --local in that case, or
- Adding a per-agent option "OpenClaw mode: gateway / local", or
- At minimum, capturing the child's stderr (e.g.
--raw-dump-style log) and surfacing the real error message instead of a bare exit code.
Workaround
Stop the gateway (openclaw gateway stop) before using the agent in LobeHub — but this disables OpenClaw's messaging channels and other gateway features. Alternatively, place a wrapper script earlier in PATH that strips the --local flag.
Additional context
- Both devices are connected via LobeHub CLI / desktop app and show online in
lh device list.
- The failure also occurs when chatting from the same machine that runs OpenClaw (i.e. it is not a remote-dispatch problem).
📱 Client Type
Desktop App (Electron)
💻 Operating System
macOS (execution device: Mac mini, Apple Silicon), Windows (chat client)
📦 Deployment Platform
Official Cloud
📌 Version
Desktop 2.2.18, lh CLI 0.0.55
🐛 What happened?
When chatting with an OpenClaw agent (connected via "Connect External Agents" → bound to a device), sending any message fails immediately with:
No other error output is shown in the UI.
Root cause (confirmed by manual reproduction on the execution device):
LobeHub spawns OpenClaw with a hardcoded
--localflag (apps/cli/src/tools/heteroTask.ts):When the OpenClaw gateway is already running on the device (the normal setup for a self-hosted OpenClaw instance — it holds the session store lock),
openclaw agent ... --localtries to open the session store directly, conflicts with the gateway's lock, and exits with code 1 immediately.Reproduced manually on the execution device:
Two side problems that made this hard to diagnose:
stdio: 'ignore', so OpenClaw's actual stderr (the real error explaining the session lock conflict) is discarded — the user only sees the bareTask failed (exit code: 1).📷 How to reproduce it?
openclaw gateway(keep it running, as OpenClaw is designed to).Task failed (exit code: 1).Expected behavior
LobeHub should work with a running OpenClaw gateway, e.g. by:
openclaw health/ gateway port probe) and omitting--localin that case, or--raw-dump-style log) and surfacing the real error message instead of a bare exit code.Workaround
Stop the gateway (
openclaw gateway stop) before using the agent in LobeHub — but this disables OpenClaw's messaging channels and other gateway features. Alternatively, place a wrapper script earlier in PATH that strips the--localflag.Additional context
lh device list.