OpenClaw's Lobster Runner Is Getting the In-Process Bridge It Should Have Had From the Start

The easiest way to make an embedded workflow call back into its host agent is also the wrong one: hand the workflow a gateway URL, drop a bearer token into its environment, and let nested CLI calls pretend they are first-class integration. It works right up until the workflow runs a shell step, logs its environment, executes untrusted package code, or gets steered into revealing the token. Then the “integration” becomes a credential leak with better documentation.

That is the problem OpenClaw PR #91028 is trying to solve for the embedded Lobster runner. The PR implements an in-process LLM adapter so embedded workflows can call llm.invoke --provider openclaw through a host-provided bridge instead of relying on openclaw.invoke --tool llm-task, which is HTTP-only and requires OPENCLAW_URL plus a bearer token. It is still a draft, and maintainers still need live end-to-end proof, but the design is the right one: capability-scoped composition beats smuggling host credentials into workflow env.

The backstory matters. Issue #76101, filed against OpenClaw 2026.4.29, showed a mismatch between documented and embedded behavior. Direct llm-task calls, basic Lobster workflows, managed TaskFlow, and approval/resume flows worked. But the documented openclaw.invoke --tool llm-task path failed with openclaw.invoke requires --url or OPENCLAW_URL. PR #78736 closed that issue as a docs-only correction: those examples applied to the standalone Lobster CLI, not the embedded runner. Documentation became more honest. Runtime composition remained awkward.

Workflow composition should not require a bearer token

Issue #90909 reframed the missing piece clearly: the embedded runner needs host-provided in-process LLM adapters. PR #91028 wires that idea into lobster-runner.ts, lobster-tool.ts, and lobster-runner.test.ts, adding EmbeddedLlmAdapter and EmbeddedRuntimeBridges. The host runtime populates ctx.llmAdapters.openclaw, backed by api.runtime.agent.runEmbeddedAgent, so the workflow can request an LLM invocation without receiving a gateway token.

That boundary is not theoretical. The PR's security assertion explicitly says ctx.env must not contain OPENCLAW_URL, OPENCLAW_TOKEN, CLAWD_URL, or CLAWD_TOKEN. After review feedback, the author seeded those variables in process.env and asserted they are stripped from the copied workflow environment. That is the kind of test you want for embedded agent systems, because “we probably do not pass secrets through” is not a boundary. A failing assertion is a boundary.

ClawSweeper's review also hit the right concerns: credential leakage through copied env, bare model resolution, and temporary session file cleanup. The author responded by stripping gateway credentials, resolving provider and model separately, and deleting transient session files in a finally. The reported validation is type-clean changed files and 19 of 19 Lobster runner unit tests passing. The remaining gap is live llm.invoke --provider openclaw proof in an environment with configured provider credentials.

The larger architectural point is that embedded workflow runners are not just convenience features. They are where agent platforms turn ad-hoc tool use into repeatable procedures: validation loops, approval gates, structured outputs, file transforms, substeps, and task orchestration. If those workflows need to call models, the platform has to decide whether model access is a host-mediated capability or a token-bearing client relationship. That decision determines the security model.

Passing an HTTP token into workflow env is seductive because it reuses the public API. But embedded workflows are not normal external clients. They are running inside the host's trust envelope, often with shell access or file access, and sometimes with user-authored steps. Giving them an operator-scoped token expands their authority beyond the narrow operation they need. A malicious or compromised workflow does not need to escape the sandbox if the token gives it the host control plane.

An in-process adapter is narrower. The workflow gets an LLM invocation capability; the host decides how to fulfill it. The runtime can preserve policy, attribution, model selection, approvals, and cleanup without exposing the credential that would let workflow code make arbitrary gateway calls. That is a better composition primitive for multi-agent orchestration, especially as Lobster-style workflows start sitting between one-off tool calls and full autonomous subagents.

Practitioners should take two lessons from this. First, if your agent platform has embedded workflows, audit whether those workflows receive host URLs, bearer tokens, provider keys, or other ambient credentials. Second, prefer capability bridges over “just call our HTTP API from inside the workflow” patterns. The latter is simpler until you need to explain why a workflow step had the same authority as the operator.

OpenClaw's Lobster bridge is not shipped proof yet; it is a draft with a promising boundary. But the principle is already worth approving: orchestration should compose capabilities, not leak credentials. If embedded agents are going to become real runtime building blocks, this is the kind of boring architectural hygiene they need from the start.

There is a testing lesson here as well. Unit tests that only prove the adapter exists are not enough; they need to prove what the workflow cannot see. The negative assertions around gateway credentials are as important as the positive assertion that ctx.llmAdapters is populated. In agent runtimes, absence is a feature. The secret that never enters the workflow environment is the easiest secret to keep.

Sources: OpenClaw PR #91028, Issue #90909, Issue #76101, OpenClaw PR #78736