openclaw - 💡(How to fix) Fix Lobster docs show openclaw.invoke --tool llm-task, but embedded runner lacks gateway URL/auth context [1 comments, 2 participants]

Summary

The shipped docs show openclaw.invoke --tool llm-task as the way to run an llm-task step from a Lobster workflow, but the embedded Lobster runner does not appear to provide the gateway URL/auth context needed for that command to work.

On OpenClaw 2026.4.29 (a448042), the documented Lobster -> openclaw.invoke -> llm-task path fails even though:

• direct llm-task tool calls work
• basic Lobster workflows work
• Lobster managed TaskFlow create/finish works
• Lobster managed TaskFlow approval/wait/resume works

So the failing surface seems specific to the workflow bridge/context for invoking OpenClaw tools from inside Lobster.

Environment

• OpenClaw: 2026.4.29 (a448042)
• Host: macOS / Darwin arm64
• Plugins enabled: lobster, llm-task
• llm-task config uses openai-codex/gpt-5.5

Docs that suggest this should work

docs/tools/lobster.md shows:

openclaw.invoke --tool llm-task --action json --args-json '{ ... }'

docs/tools/llm-task.md also has the same "Example: Lobster workflow step" pattern.

Reproduction

1. Direct llm-task tool call succeeds

Result:

{
  "ok": true,
  "label": "direct-llm-task-smoke"
}

2. Basic Lobster workflow succeeds

Pipeline:

exec --json --shell 'printf "{\"ok\":true,\"label\":\"basic-lobster-smoke\"}"'

Result includes:

{
  "ok": true,
  "status": "ok",
  "output": [{ "ok": true, "label": "basic-lobster-smoke" }]
}

3. Managed Lobster TaskFlow succeeds

Flow id:

9dd240aa-a28c-4a56-8b1a-41700e31fa75

openclaw tasks flow show ... --json shows:

{
  "syncMode": "managed",
  "controllerId": "system-architect/managed-taskflow-smoke",
  "revision": 1,
  "status": "succeeded",
  "currentStep": "run_basic_lobster",
  "waitJson": null
}

4. Managed TaskFlow approval/wait/resume succeeds

Flow id:

e08636fe-4ebc-4f5f-a7b6-bcd8193ba55d

The workflow first entered:

{
  "status": "waiting",
  "currentStep": "await_smoke_approval"
}

After Lobster resume with approval, openclaw tasks flow show ... --json shows:

{
  "syncMode": "managed",
  "controllerId": "system-architect/taskflow-approval-smoke",
  "revision": 3,
  "status": "succeeded",
  "currentStep": "resume_after_approval",
  "waitJson": null
}

5. Lobster -> openclaw.invoke -> llm-task fails

Pipeline equivalent to the documented pattern:

openclaw.invoke --tool llm-task --action json --args-json '{"prompt":"Return only JSON with ok=true and label=\"lobster-llm-task-smoke\".","schema":{"type":"object","required":["ok","label"],"properties":{"ok":{"type":"boolean","const":true},"label":{"type":"string","const":"lobster-llm-task-smoke"}},"additionalProperties":false},"timeoutMs":120000}'

Result:

openclaw.invoke requires --url or OPENCLAW_URL

A diagnostic Lobster workflow shows the runner environment has OPENCLAW_GATEWAY_PORT=18789, but not OPENCLAW_URL.

If --url http://127.0.0.1:18789 is provided manually, the command reaches the gateway but fails with:

openclaw.invoke failed (401): {"error":{"message":"Unauthorized","type":"unauthorized"}}

Expected behavior

One of these should be true:

1. The embedded Lobster runner should inject enough context for documented openclaw.invoke --tool llm-task ... steps to work, e.g. gateway URL plus an appropriate local auth/invocation context; or
2. The docs should show the complete required invocation pattern, including how OPENCLAW_URL and auth are supposed to be provided safely from a Lobster workflow; or
3. If openclaw.invoke is no longer the supported workflow bridge, the Lobster/llm-task docs should point to the supported replacement.

Actual behavior

The documented pattern is not directly runnable from the embedded Lobster runner on 2026.4.29:

• no URL/context: openclaw.invoke requires --url or OPENCLAW_URL
• manual localhost URL: 401 Unauthorized

Why this matters

This blocks the main documented pattern for using llm-task inside deterministic Lobster workflows, e.g.:

fetch input -> schema-validated llm-task classification -> approval/wait/resume -> side effect

The individual components work; only the bridge from Lobster workflow steps to OpenClaw tool invocation appears broken or under-documented.

Related prior issues

These look related but are closed, while the issue is reproducible on the current released 2026.4.29 build:

• #68979
• #50279
• #74019 (different failure mode: explicit tool allowlist / disableTools; direct llm-task now works here after local hotfix, but this issue is specifically about Lobster -> openclaw.invoke URL/auth context)