Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The Lobster tool incorrectly falls back to pipeline parsing when a relative workflow file path cannot be resolved.

For example, passing:

lobster/haiku-ppc64-hidden-alias-autofix-once.lobstercan result in:

Unknown command: lobster/haiku-ppc64-hidden-alias-autofix-once.lobsterThis is misleading. The input is a workflow file path, not a pipeline stage name.

Environment

• OpenClaw version: 2026.4.15 • Platform: macOS 26 • Lobster used through the OpenClaw agent/tool runtime

Steps to reproduce

Call the Lobster tool with a relative workflow file path, for example:

{
  "action": "run",
  "pipeline": "lobster/haiku-ppc64-hidden-alias-autofix-once.lobster",
  "cwd": ".",
  "timeoutMs": 120000,
  "maxStdoutBytes": 20000
}

Expected behavior

If the input looks like a workflow file path, OpenClaw should either:

1. resolve and run the workflow file, or
2. return a clear workflow file/path error

It should not silently reinterpret the input as a Lobster pipeline.

Actual behavior

If workflow-file detection fails, the Lobster wrapper falls back to pipeline parsing, and the file path is treated as a command name. This produces the misleading error:

Unknown command: lobster/haiku-ppc64-hidden-alias-autofix-once.lobster

OpenClaw version

2026.4.15

Operating system

macOS 26.3.1

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> built-in lobster tool wrapper -> local workflow file resolution

Additional provider/model setup details

This does not appear to depend on a specific LLM provider or model. The failure occurs in the OpenClaw Lobster tool wrapper when a relative workflow file path is passed via the tool run request, for example through the "pipeline" field. The relevant local context was cwd="." inside the workspace, with a relative workflow path such as lobster/haiku-ppc64-hidden-alias-autofix-once.lobster.

Logs, screenshots, and evidence

Observed tool error:

lobster failed: Unknown command: lobster/haiku-ppc64-hidden-alias-autofix-once.lobster
raw_params={"action":"run","pipeline":"lobster/haiku-ppc64-hidden-alias-autofix-once.lobster","cwd":".","timeoutMs":120000,"maxStdoutBytes":20000}

Impact and severity

Affected users/systems/channels: Users invoking the Lobster tool with relative workflow file paths in OpenClaw tool/runtime contexts.

Severity: Blocks or misleads workflow execution. It is not a crash, but it causes valid workflow invocations to fail with an incorrect error.

Frequency: Reproducible for the observed relative workflow-file invocation pattern.

Consequence: Valid workflow files can fail to run, and users receive a misleading "Unknown command" error that points them toward command registration or pipeline issues instead of the real workflow-file resolution problem.

Additional information

I have not confirmed whether this is a regression. I did not find an existing issue that clearly matches this exact bug. I found a related but different closed issue about Lobster workflow file shell quoting limitations, but this appears to be a separate behavior bug involving workflow-file detection and incorrect fallback to pipeline parsing.

Proposed fix: If the input clearly looks like a workflow file candidate, for example:

• ends in .lobster, .yaml, .yml, or .json • or contains / or \

then a workflow resolution failure should be surfaced directly as a file/path error.

It should not silently fall back to pipeline parsing.

Verification

This was locally patched and retested.

After the patch:

• valid relative workflow paths are treated as workflow files • nonexistent workflow files produce a clear path error such as ENOENT • normal pipeline commands like commands.list continue to work unchanged

Related note

I found a related but different closed issue:

• #29491 feat(lobster): document workflow file shell quoting limitation + suggest exec helper or JSON format

This seems separate. The current issue is specifically about relative workflow file detection and the incorrect silent fallback to pipeline parsing.

Additional note: I locally verified that after patching this behavior:

• valid relative workflow paths are treated as workflow files
• nonexistent workflow files return a clear path error
• normal pipeline commands still work

OpenClaw made the following fixes.

Upstream fix 1-2

Path: extensions/lobster/src/index.ts

diff --git a/extensions/lobster/src/index.ts b/extensions/lobster/src/index.ts
@@
 async function detectWorkflowFile(candidate: string, cwd: string): Promise<string | null> {
   const trimmed = candidate.trim();
   if (!trimmed || trimmed.includes("|")) return null;
   try {
     return await resolveWorkflowFile(trimmed, cwd);
   } catch (err) {
-    return null;
+    if (looksLikeWorkflowFileCandidate(trimmed)) throw err;
+    return null;
   }
 }
@@
-        const filePath = await detectWorkflowFile(pipeline, params.cwd);
+        const filePath = await detectWorkflowFile(pipeline, ctx.cwd);

Upstream fix 3

Path: extensions/lobster/src/index.ts

diff --git a/extensions/lobster/src/index.ts b/extensions/lobster/src/index.ts
@@
 function resolveLobsterCwd(cwdRaw?: string): string {
-  if (typeof cwdRaw !== "string" || !cwdRaw.trim()) return process.cwd();
+  const base = process.cwd();
+  if (typeof cwdRaw !== "string" || !cwdRaw.trim()) return base;
   const cwd = cwdRaw.trim();
   if (path.isAbsolute(cwd)) throw new Error("cwd must be a relative path");
-  const base = process.cwd();
   const resolved = path.resolve(base, cwd);
   const rel = path.relative(normalizeForCwdSandbox(base), normalizeForCwdSandbox(resolved));
   if (rel === "" || rel === ".") return resolved;

Reviewer note

• The first fix prevents file-like workflow inputs from being silently reparsed as pipeline commands.
• The second fix ensures workflow-file detection uses the effective embedded-tool cwd.
• The third fix keeps cwd resolution internally consistent by using a single base value inside resolveLobsterCwd().
• My local hotfix also included a machine-specific workspace fallback only for immediate recovery, but that part is intentionally omitted here because it is not upstream-safe.