Best way to test/manually run lobster? | Friends of the Crustacean 🦞🤝 | Page 1

steady hamlet Apr 29, 2026, 1:32 AM

#

It used to be easy to run lobster manually against a .lobster workflow file for testing, graphing, etc. In one of the recent releases, the lobster script (executable?) was removed from the .bin folder.

What is the best way to either test or manually run a .lobster file? Trying to build some complex pipelines for development/dark factory use cases.

barren crescentBOT Apr 29, 2026, 1:32 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

hollow ivyBOT Apr 29, 2026, 1:33 AM

#

The short version: the missing .bin/lobster from OpenClaw is expected now. OpenClaw’s Lobster integration runs in-process via the optional lobster plugin tool, not by shelling out to a bundled CLI. For agent/runtime testing, enable the tool and run the .lobster file through the tool. For local dev/graphing/CI-style testing, use the standalone Lobster CLI. (docs.openclaw.ai)

Inside OpenClaw:

{
  "tools": {
    "alsoAllow": ["lobster"]
  }
}

Then ask the agent to run the workflow, or call the tool shape like:

#

  "action": "run",
  "pipeline": "/path/to/workflow.lobster",
  "argsJson": "{\"tag\":\"family\"}",
  "timeoutMs": 30000
}

pipeline can be a .lobster file path, and argsJson is the workflow args string. (docs.openclaw.ai)

For manual testing / graphing:

Install/use the standalone package/repo so the lobster binary is on PATH. The package exposes lobster, openclaw.invoke, and clawd.invoke bins. (raw.githubusercontent.com)

Typical commands:

#

lobster run path/to/workflow.lobster
lobster run --file path/to/workflow.lobster --args-json '{"tag":"family"}'

lobster graph --file path/to/workflow.lobster
lobster graph --file path/to/workflow.lobster --format mermaid
lobster graph --file path/to/workflow.lobster --format dot
lobster graph --file path/to/workflow.lobster --format ascii

That’s the split I’d use: standalone CLI for authoring/graphing/CI, OpenClaw lobster tool for real gateway/agent execution. If it’s not showing up after config, paste openclaw --version and the relevant tools config block.

steady hamlet Apr 29, 2026, 1:40 AM

#

To be explicit, is this the correct way to run the workflow?
openclaw gateway call agent.tool.lobster --params '{"action": "run", "pipeline": "debug-workflow.lobster"}'
The gateway is timing out after 10 seconds (10000ms) after attempting this.

My tools config section:

"tools": {
    "web": {
      "search": {
        "enabled": true
      },  
      "fetch": {
        "enabled": true
      } 
    },
    "alsoAllow": [ "lobster", "llm-task" ]
  },

hollow ivyBOT Apr 29, 2026, 1:41 AM

#

Not quite — I wouldn’t use openclaw gateway call agent.tool.lobster as the canonical path here.

For direct/manual tool execution, use the Gateway HTTP tool endpoint:

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "tool": "lobster",
    "args": {
      "action": "run",
      "pipeline": "/absolute/path/to/debug-workflow.lobster",
      "timeoutMs": 60000
    }
  }'

#

Two timeout knobs matter:

Client/Gateway request timeout — e.g. openclaw gateway call --timeout 60000 ...
Lobster runtime timeout — the tool arg: "timeoutMs": 60000

Also: debug-workflow.lobster as a relative path resolves relative to the Gateway process cwd, not necessarily the shell directory you ran the command from. For testing, use an absolute path first.

Your tools.alsoAllow: ["lobster", "llm-task"] looks right. If you also have a restrictive plugins.allow, make sure lobster is included there too, then restart the gateway.

Can you paste:

openclaw --version

and, if it still times out, the matching gateway log line from:

#

openclaw logs --follow

steady hamlet Apr 29, 2026, 1:53 AM

#

Knowing that I needed to make the call through the API was key.

I'm getting another error now related to the update that removed some of the tools in the .bin folder:
{"subsystem":"tools-invoke"} tool execution failed: Error: workflow command failed (127): /bin/sh: openclaw.invoke: command not found

What is the right way to call llm-task now from within a lobster workflow?

hollow ivyBOT Apr 29, 2026, 1:56 AM

#

Yep — that error means openclaw.invoke is being run as a shell command.

In .lobster workflow files:

command: / run: → /bin/sh ...
pipeline: → Lobster built-in commands like openclaw.invoke, llm_task.invoke, llm.invoke

So change the step to pipeline::

steps:
  - id: classify
    pipeline: >-
      openclaw.invoke
      --tool llm-task
      --action json

#

      --args-json '{"prompt":"Classify this input and return JSON.","thinking":"low","schema":{"type":"object","properties":{"summary":{"type":"string"}},"required":["summary"],"additionalProperties":false}}'

If you want to pass prior step output into llm-task:

  - id: classify
    stdin: $fetch.json
    pipeline: >-
      openclaw.invoke
      --tool llm-task
      --action json
      --each
      --item-key input
      --args-json '{"prompt":"Classify this item and return JSON.","thinking":"low","schema":{"type":"object","properties":{"summary":{"type":"string"}},"required":["summary"],"additionalProperties":false}}'

#

Also make sure the workflow has access to the Gateway HTTP endpoint:

env:
  OPENCLAW_URL: "http://127.0.0.1:18789"

And if auth is enabled, the Gateway process needs OPENCLAW_TOKEN or CLAWD_TOKEN in its env. Don’t hardcode the token into the .lobster file if you can avoid it.

Cleaner LLM-only form is also possible:

pipeline: >-
  llm_task.invoke
  --prompt "Classify this and return JSON."
  --output-schema '{"type":"object","required":["summary"],"properties":{"summary":{"type":"string"}}}'

#

…but for calling the actual OpenClaw llm-task tool with its normal params, pipeline: openclaw.invoke ... is the closest replacement.

Docs: https://docs.openclaw.ai/tools/lobster and https://docs.openclaw.ai/tools/llm-task

steady hamlet Apr 29, 2026, 2:32 AM

#

Should I expect this error based on the tools config I shared?

{"subsystem":"diagnostic"} lane task error: lane=session:agent:main:explicit:llm-task-1777429341921 durationMs=306 error="Error: No callable tools remain after resolving explicit tool allowlist (tools.allow: *, lobster, llm-task; agents.main.tools.allow: *, lobster, llm-task); tools are disabled for this run. Fix the allowlist or enable the plugin that registers the requested tool."

hollow ivyBOT Apr 29, 2026, 2:34 AM

#

No — I’d call this a bug/rough edge, not a “your config is wrong” situation.

What’s happening:

llm-task intentionally starts an embedded model run with tools disabled.
Your tools.alsoAllow: ["lobster", "llm-task"] gets represented internally like an allowlist: ["*", "lobster", "llm-task"].
The guard then says: “there’s an explicit allowlist, but zero callable tools remain” — because llm-task disabled tools on purpose.

So that error is explainable, but it shouldn’t block a JSON-only llm-task run.

Best workaround for now: don’t put lobster / llm-task in global or main tool policy. Put them on a dedicated workflow agent and route /tools/invoke there:

{
  "agents": {
    "list": [

#

      {
        "id": "workflow",
        "tools": {
          "alsoAllow": ["lobster", "llm-task"]
        }
      }
    ]
  }
}

Then call:

#

  "sessionKey": "agent:workflow:main",
  "tool": "lobster",
  "args": {
    "action": "run",
    "pipeline": "/path/to/debug-workflow.lobster"
  }
}

And inside the .lobster file:

pipeline: >-
  openclaw.invoke
  --session-key agent:workflow:main

#

  --tool llm-task
  --action json
  --args-json '{"prompt":"Return JSON.","schema":{"type":"object"}}'

Restart the gateway after changing config.

If that still fails, I’d file this as a GitHub issue with your openclaw --version and that exact diagnostic line: https://github.com/openclaw/openclaw/issues

steady hamlet Apr 29, 2026, 2:48 AM

#

Is there a way to do this without moving away from my main agent? This would work for a debug or a test case, but if I wanted to work with files within the agent's workspace, it could get messy.

hollow ivyBOT Apr 29, 2026, 2:49 AM

#

For Lobster only, yes, main is fine.

For Lobster → llm-task on main with tools.alsoAllow, I think you’re hitting a current bug/edge case. llm-task runs an embedded model call with tools intentionally disabled, but main’s explicit tool policy still gets checked and trips the “no callable tools remain” guard.

Best practical workaround without workspace mess:

{
  "agents": {
    "list": [
      {
        "id": "workflow",
        "workspace": "/same/path/as/main/workspace",
        "tools": {
          "alsoAllow": ["lobster", "llm-task"]
        }

#

      }
    ]
  }
}

Then invoke with:

"sessionKey": "agent:workflow:main"

That changes the tool-policy/session lane, not where your files live. If both agents point at the same workspace, your .lobster files and outputs stay in the same place.

So: clean config-only way on main? probably not with llm-task right now. Same workspace via a workflow agent is the least messy workaround until this guard is fixed.

steady hamlet Apr 29, 2026, 2:51 AM

#

Is there already a bug opened for this that I can follow? If not, can you help write up what should go into the bug report?

hollow ivyBOT Apr 29, 2026, 2:52 AM

#

I don’t see an exact open issue for Lobster → llm-task failing because the embedded JSON-only run disables tools while tools.alsoAllow creates an explicit allowlist. I found related tool-surface / allowlist issues, but not this specific signature. (github.com)

I’d file a new bug. Copy/paste draft:

Title:
Lobster workflow calling llm-task fails with “No callable tools remain” when tools.alsoAllow includes lobster/llm-task

Version:
- OpenClaw: <output of openclaw --version>
- Install method: <npm/source/docker/etc>
- OS: <macOS/Linux/etc>

Summary:
Running a .lobster workflow through `/tools/invoke` works until the workflow calls `llm-task`.
`llm-task` appears to start an embedded model run with tools intentionally disabled, but the explicit tool allowlist from `tools.alsoAllow` / `agents.main.tools.alsoAllow` is still checked and causes the run to fail.

GitHub

Spawned subagents don't receive browser/web tools despite allowlist...

Summary Spawned subagents created via sessions_spawn(runtime="subagent") do not receive browser / web_search / web_fetch capabilities in practice, even when: the agent config explicitly a...

#


Config:
```json
"tools": {
  "alsoAllow": ["lobster", "llm-task"]
}

If agent-level config is present:

"agents": {
  "list": [
    {
      "id": "main",
      "tools": {
        "alsoAllow": ["lobster", "llm-task"]

#

}
}
]
}


Workflow:
```yaml
name: debug-workflow
steps:
  - id: classify
    pipeline: >-
      openclaw.invoke
      --tool llm-task
      --action json
      --args-json '{"prompt":"Return JSON.","schema":{"type":"object"}}'

#


How I invoked it:
```bash
curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "tool": "lobster",
    "args": {
      "action": "run",
      "pipeline": "/absolute/path/to/debug-workflow.lobster"
    }
  }'

#

Observed error:
```text
{"subsystem":"diagnostic"} lane task error: lane=session:agent:main:explicit:llm-task-... durationMs=306 error="Error: No callable tools remain after resolving explicit tool allowlist (tools.allow: *, lobster, llm-task; agents.main.tools.allow: *, lobster, llm-task); tools are disabled for this run. Fix the allowlist or enable the plugin that registers the requested tool."

Expected:
llm-task should be able to run its JSON-only embedded model call with tools disabled, without the explicit tool allowlist guard treating that as a configuration failure.

Why this matters:
This blocks using Lobster workflows with llm-task from the main agent/workspace. A separate workflow agent can work around it, but that is awkward when workflows need to operate in the main agent workspace/session context.

Workaround:
Create a dedicated workflow agent pointing at the same workspace and invoke Lobster with sessionKey: "agent:workflow:main".


File it here: <https://github.com/openclaw/openclaw/issues>

#Best way to test/manually run lobster?