Skip to content

[Bug] OpenClaw agent fails with 'Task failed (exit code: 1)' when OpenClaw gateway is running (hardcoded --local conflicts with gateway session lock) #19914

Description

@liberalchang

📱 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:

  1. 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).
  2. 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?

  1. On a device (e.g. Mac mini), install OpenClaw, complete onboarding, and run openclaw gateway (keep it running, as OpenClaw is designed to).
  2. In LobeHub, create an agent via Connect External Agents → OpenClaw, bound to that device.
  3. Send any message to the agent.
  4. 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).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions