Lobster Gating
Trust but verify with OpenClaw's Lobster plugin
OpenClaw’s a great tool but I don’t trust agents with critical flows. Like, “cancel my two o’clock tomorrow”, and toss it over the wall. No. I want confidence in the action carried out. Will the agent decide to delete all of my calendar events? Will it decide to cancel some similarly titled Task? No thanks. Whether these are carried out through CLI tools or shell commands, I need to be confident in what the agent does. To get there let’s talk about exec.
Imagine you have a Google CLI tool that lets you retrieve your Google Tasks:
gog task list [task_list_id]
By default, OpenClaw can make that call using exec. Not only can it get tasks but it can also destroy them. Agents being non-deterministic, that scares me. Let’s lock that exec ability down by editing OpenClaw’s openclaw.json config:
...
"agents": {
"list": [
{
"id": "main",
"tools": {
"alsoAllow": ["lobster"],
"deny": ["exec"] // this entry
}
}
]
},
...
"tools": {
"profile": "coding",
"subagents": {
"tools": {
"alsoAllow": ["lobster"],
"deny": ["exec"] // and this entry
}
}
},
...Let’s review this config from the bottom starting with “tools”. This uses the “coding” profile which gives all agents broad operational functionality like exec, file I/O, or browser access. Next, working backwards, is the “agents” declaration. It has its own “tools” configuration. In both of these places we’ve denied access to exec. Once you start a new session, you can confirm this restriction is in place by asking your agent, “Run ‘echo hello’ and give me the output”. It won’t be able to. exec is now locked down.
Okay, so, if agents can’t use exec how do we let them run tools? Enter Lobster, a workflow shell that lets agents run multi-step tool sequences deterministically with explicit approval checkpoints.
Deterministic with approval checkpoints? Sign me up.
In the JSON example above, Lobster is already configured with “alsoAllow” which is additive to the other capabilities provided by the “coding” profile. That means Lobster is added to the abilities which are allowed such as browser usage and file I/O. But enabling Lobster is only half the battle. Now we need workflow files to let agents use tools.
I’m not going to hold your hand through installing Lobster; it’s not installed by default alongside OpenClaw. Once you’ve got it, here’s an example Lobster workflow file for creating a Google Task:
name: tasks-add
description: "Create a task in Google Tasks with approval gate"
args:
title:
description: "Task title"
due:
description: "Due date (YYYY-MM-DD)"
steps:
- id: build
run: echo "gog tasks add MY_TASKLIST_ID --title \"${title}\" --due \"${due}\""
- id: approve
approval:
prompt: "Create this task?"
preview: $build.stdout
- id: execute
run: gog tasks add MY_TASKLIST_ID --title "$LOBSTER_ARG_TITLE" --due "$LOBSTER_ARG_DUE"
condition: $approve.approvedThere are three steps in this flow:
Output the intended command
Ask permission
Execute
Steps 1 and 3 are the determinism Lobster introduces. In this example, it controls access to echo and gog (Google CLI). More specifically, the workflow surfaces the command to be executed, we can choose to approve it, and then the workflow will trigger it. By using Lobster we remove non-deterministic tool calls from the agent’s tool-set. That’s the critical takeaway.
The agent still needs to know when to trigger the workflow. That’s where skills come in. Here’s an example skill for creating Google Tasks:
---
name: open-claw-create-task
description: |-
Creates a Google Task via the Lobster tasks-add workflow.
Use when the user:
- Asks to create or add a task
- Says "remind me to", "add this to my tasks", "put this on my list"
- Wants to capture something they need to do
- Says "make a task for", "add a to-do", "don't let me forget to"
- Mentions a deadline and something they need to get done
- Wants to track an action item with a due date
---
# Create Task
## Process
1. If the user hasn't provided a task title, ask for one.
2. Ask for a due date. Required. Format must be YYYY-MM-DD.
3. Invoke Lobster with the `tasks-add` workflow:
```json
{
"action": "run",
"pipeline": "~/.openclaw/workflows/tasks-add.lobster",
"argsJson": "{\"title\": \"<task title>\", \"due\": \"<YYYY-MM-DD>\"}"
}
```
Lobster handles confirmation before executing. Never call `gog` directly.The skill tells the agent when to reach for the workflow and exactly how to invoke it. Lobster handles the rest.
By using Lobster we remove non-deterministic tool calls from the agent’s tool-set.
That’s it! Deny access to exec, pair a Lobster workflow with a skill, and you can be confident agent-initiated actions creating, editing, or destroying are 100% approved by you 🦞
Other Helpful Links
https://docs.openclaw.ai/tools
https://docs.openclaw.ai/gateway/sandboxing
https://docs.openclaw.ai/gateway/configuration-reference#agents-list-per-agent-overrides
https://docs.openclaw.ai/tools/multi-agent-sandbox-tools
https://docs.openclaw.ai/concepts/architecture

