Summary

The @openclaw/lobster plugin tool appears to misroute ordinary run / resume calls into the managed TaskFlow parameter path when the OpenClaw tool schema injects default flow fields.

This makes the documented minimal tool calls fail unless the wrapper treats schema default values as absent.

Environment

• OpenClaw Gateway: 2026.7.7
• Plugin: @openclaw/lobster 2026.6.11
• Runtime dependency: @clawdbot/lobster 2026.5.22
• Install route: openclaw plugins install clawhub:@openclaw/lobster
• Plugin inspect source: ~/.openclaw/extensions/lobster/dist/index.js

Docs expectation

The docs show ordinary embedded tool use as:

{
  "action": "run",
  "pipeline": "workflows/example.lobster",
  "argsJson": "{...}",
  "cwd": "...",
  "timeoutMs": 30000
}

And resume as:

{
  "action": "resume",
  "token": "...",
  "approve": true
}

No flowId or flowExpectedRevision is required for these ordinary Lobster approval workflows.

Actual behavior

Calling the lobster tool through OpenClaw with a normal run failed with:

run action does not accept flowId or flowExpectedRevision

After patching run, calling ordinary resume failed similarly because the schema default flowExpectedRevision=0 caused the wrapper to parse it as a managed flow resume.

The standalone Lobster CLI worked for the same workflow and correctly produced needs_approval / resumeToken, so the issue appears to be in the OpenClaw plugin wrapper/tool-schema interaction rather than in the Lobster core runtime.

Minimal reproduction shape

1. Install/enable @openclaw/lobster.
2. Run a workflow file with an approval step using the OpenClaw lobster tool.
3. Observe ordinary run rejected because flowExpectedRevision is present even though the caller did not intend TaskFlow mode.
4. If run is patched, ordinary resume can hit the same issue.

A workflow file with a standard approval step is enough:

name: approval-smoke
steps:
  - id: prepare
    command: echo '{"ok":true}'
  - id: approve
    command: echo '{"requiresApproval":{"prompt":"Continue?","items":[]}}'
    stdin: $prepare.stdout
    approval: required
  - id: done
    command: echo '{"ok":true,"done":true}'
    condition: $approve.approved

Local workaround tested

I locally patched ~/.openclaw/extensions/lobster/dist/index.js so that schema default/empty flow fields are treated as absent for ordinary run / resume calls.

The essence of the workaround:

• parseOptionalFlowStateJson("") and parseOptionalFlowStateJson("{}") return undefined.
• In parseRunFlowParams, ignore flowExpectedRevision unless flowId is present.
• In parseResumeFlowParams, ignore flowExpectedRevision unless flowId is present.
• Parse flowStateJson consistently before deciding whether it was really provided.

After this local patch and a real gateway process restart:

• Tool-level run successfully returned status: "needs_approval".
• Tool-level resume approve successfully continued the workflow.

Expected fix

The plugin wrapper should distinguish between:

1. real managed TaskFlow arguments intentionally provided by the caller; and
2. OpenClaw tool schema defaults / empty values that are injected into the tool call payload.

Ordinary Lobster run / resume should not be rejected simply because flowExpectedRevision appears with a default value such as 0 while flowId is absent.

Notes

This is especially easy to hit from agent tool calls because the tool schema includes flow fields for both modes in one tool surface.