feat: Add optional lobster plugin tool (typed workflows, approvals/resume) #1152
Conversation
|
can you add a lobster.md in docs that explains this in detail? |
@steipete Done! Added docs/tools/lobster.md — covers the value prop, a concrete email triage example, enable/config, and security model. Let me know if you'd like more detail on any part. Added a skill.md for documentation, but the idea is to make this a clawd skill so it knows that lobster exists (in a follow up PR). Once that exists, no more changes will be needed to core. I can continue developing abilities in the lobster repo. |
|
@steipete Thoughts? I have added an example workflow as well to lobster's readme so it is clear what kind of future I'm thinking of. Once clawd knows lobster exists it can run multistep stuff via just Happy to take this in any direction based on your feedback. |
|
Landed via temp rebase onto main. Thanks @vignesh07! |
This PR adds a new plugin extension
extensions/lobster/that registers a lobster agent tool as an optional (opt‑in) plugin tool. Implemented as an optional plugin tool using the new boundary. If we hit a limitation in practice, happy to propose a minimal boundary extension PR.Lobster lets Clawdbot run deterministic, typed workflows (pipelines) as a single tool call, with resumable approvals for side effects. This reduces token usage and brittleness by moving step-by-step tool orchestration out of the LLM, while keeping Clawdbot core unchanged.
Conceptually, Lobster is “bash pipes for tools”, but typed and safe: tool outputs stay structured, workflows are composable, and any side effect is gated behind an approval token that can be resumed. This is how we can do workflows like “triage email → draft replies → ask approval → send” as one call instead of a long sequence of tool calls.
Why plugin (not core)
• Keeps Clawdbot core slim and avoids adding a new runtime/language until it proves useful.
• Uses the newly added optional plugin tools boundary (commit 6da6582).
• If Lobster earns trust and stabilizes, we can consider deeper integration later, but this keeps the initial footprint minimal and reversible.
Opt-in / Allowlist
This tool is registered with
{ optional: true }and is never enabled automatically.Users must enable it via
agents.list[].tools.allow, e.g.:•
"lobster"(plugin id, enables all tools from this plugin), or•
"group:plugins"(enables all plugin tools)Security / Safety
• Local-only subprocess execution; no new network surface.
• Lobster does not manage OAuth/tokens/secrets.
• Hardening: • lobsterPath must be absolute if provided (reduces PATH hijack risk).
• timeoutMs and maxStdoutBytes caps.
• Strict JSON envelope parsing (rejects invalid output).
• Sandbox safety: • The tool factory returns null when
ctx.sandboxedis true (tool not available in sandboxed contexts).What’s included
• extensions/lobster/ extension plugin
• lobster tool implementation + tests
• README describing enablement + security notes
Tests run
• pnpm vitest run extensions/lobster/src/lobster-tool.test.ts
• pnpm vitest run src/agents/pi-tools.create-clawdbot-coding-tools.adds-claude-style-aliases-schemas-without-dropping-b.test.ts -t "preserves action enums"
AI-assisted
This PR was AI-assisted. I’ve run the tests above and I understand the subprocess/security boundaries.