openclaw - 💡(How to fix) Fix [Bug]: Regression: prompt-launched Lobster workflow hangs on nested /tools/invoke, while curl-launched workflow works

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

A Lobster workflow that calls /tools/invoke from a shell step hangs when the Lobster workflow is launched from an agent prompt/chat.

The same workflow works when launched directly via external curl /tools/invoke, and the same nested invoke script works standalone with the same input.

This appears to be specific to the prompt/agent-launched Lobster execution context.

Steps to reproduce

The Lobster workflow runs initial shell steps successfully, then reaches:

id: draft_email command: sh -c 'node /home/admin/.openclaw/workspace-dba-scout/lobster-scripts/invoke-llm-task.js 2> /home/admin/.openclaw/workspace-dba-scout/debug-draft-email-stderr.txt' stdin: $debug_llm_request.stdout

That script posts to:

http://127.0.0.1:18789/tools/invoke

to invoke llm-task.

Expected behavior

Prompt-launched Lobster should behave like curl-launched Lobster: the nested /tools/invoke request should execute llm-task and return a response, or fail fast with a clear error if nested invokes are unsupported in that context.

Actual behavior

When launched from an agent prompt/chat, the workflow reaches the invoke step and hangs. LM Studio never receives the request.

The stderr from the child process ends here: text stdin bytes: 19327 env snapshot: { "OPENCLAW_SESSION_KEY": null, "OPENCLAW_GATEWAY_URL": null, "OPENCLAW_GATEWAY_PORT": "18789", "LLM_TASK_PROVIDER": null, "LLM_TASK_MODEL": null, "LLM_TASK_THINKING": null, "cwd": "/home/admin" } llm-task args: { "provider": "lmstudio", "model": "lmstudio/qwen/qwen3.6-35b-a3b", "thinking": "off", "timeoutMs": 600000, "maxTokens": 8000, "temperature": 0, "requestTimeoutMs": 900000, "sessionKey": null } payload bytes: 19448 posting to: http://127.0.0.1:18789/tools/invoke has bearer auth: true http request body bytes: 19448 http request writing body http request end called http socket assigned http socket connected http request body flushed

No http response headers received line appears.

The same workflow works when launched directly with curl: bash curl -sS http://127.0.0.1:18789/tools/invoke
-H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN"
-H "Content-Type: application/json"
--data-binary @- <<'JSON' | jq { "tool": "lobster", "action": "json", "args": { "action": "run", "pipeline": "/home/admin/.openclaw/workspace-dba-scout/sql-leads-draft.lobster", "timeoutMs": 1800000, "maxStdoutBytes": 512000 } } JSON

The same invoke script also works standalone:

cd /home/admin/.openclaw/workspace-dba-scout node lobster-scripts/invoke-llm-task.js
< debug-llm-request.json \

debug-draft-email.json
2> debug-draft-email-stderr.txt

OpenClaw version

2026.5.27

Operating system

Unbuntu

Install method

npm

Model

qwen3,6 35B

Provider / routing chain

lmstudio

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

I now have to run lobster workflows from a command prompt, can no longer run by asking agent

Additional information

Notes

Earlier debugging found and fixed a separate LM Studio/Qwen issue: the model was returning output in reasoning_content instead of message.content. Disabling reasoning in LM Studio fixed that. The remaining issue is different: in the failing prompt-launched Lobster path, LM Studio never receives the request at all.

Suspected cause

Possible re-entrant scheduling/queue issue when an agent/prompt-launched Lobster tool call runs a shell step that calls back into the same Gateway /tools/invoke endpoint.

The nested HTTP request connects and flushes its body, but Gateway never returns response headers and the nested llm-task execution does not appear to start.