Lob Bot
Lob Bot
A desktop application where bots do real work on your machine, and every action that changes something waits for your approval.
Lob Bot runs on your computer. You give a bot a job, it proposes the steps, and every step that writes a file, runs a command, opens a page or calls a connector stops and shows you the exact call before it runs. The bots, their notes, their permissions and everything they have ever done live in one folder on your disk.
It is the third product in the Lobstack lineup and the only one that is not a service. There is nothing to provision and no machine of ours behind it. Whether it calls a server of ours at all is a choice you make in Settings — see below.
This page used to say, in a warning box, that Lob Bot did not use the Gateway and that nothing about the Gateway’s routing, metering or keys applied to it. That was true when the engine was a launch flag nobody could reach. It is not true now.
Settings offers three engines. GitHub Copilot is the default and needs no Lobstack account at all — it bills against your Copilot subscription, and in that mode the old paragraph still describes what happens. The Lobstack Gateway uses a Lobstack key, and then everything on the Gateway pages does apply: the same routing, the same receipt on every call, and the traffic appears in your Console logs and usage like any other client. Your own key goes straight to OpenAI-compatible or Anthropic endpoints, billed by them, metered by nobody — which is why a cost shown for it is always an estimate and never a charge.
What stays true in all three: Lob Bot is not commanded from the Console. The Console can show you what it spent through the Gateway; it cannot tell a bot to do anything.
The approval gate
This is the product. An agent that can reach your files, your repositories and your browser is only useful if you can see what it is about to do, so the gate sits in front of every tool call rather than in front of a whole session.
| Policy | What it means |
|---|---|
| Ask every time | Every tool call waits, including reads. |
| Ask before writing | Reads run; anything that changes something waits. The default. |
| Unattended | Nothing waits. Chosen per bot, deliberately, and checked before any remembered rule. |
Whether a call counts as read-only comes from the tool itself, never from a guess at its name. Approving a shell command remembers the command as you approved it, not the binary, so allowing git status does not also allow git push. Choosing “allow for this session” keeps the decision in memory, and it is gone when the session ends — it is not written down anywhere.
Connectors
A new workspace can think and write text and nothing else. It cannot read a file, run a command or open a page until you add a connector, and a bot only sees the connectors you give it. Connectors are MCP servers: a folder, a repository, a database, a workspace tool, or any HTTP or stdio MCP server you point it at.
13 name a service and hand you a form for the two or three things it needs. 2 name nothing: one takes a URL, the other a command line, and between them they reach anything with a published MCP server — which is why the list is a floor rather than a ceiling. Each one is described at Connectors.
Credentials go into an encrypted vault, not into the database. The encryption key lives in Windows Credential Manager — Lob Bot is a Windows application today, so that is the only store involved — and the workspace database holds only a reference. Secret values are redacted when they are written rather than when they are shown, and the vault redacts by value, so a password inside a Postgres connection string is caught even though it does not look like a password.
The browser
The browser connector drives a real Chromium with its own persistent profile, addressing the page through its accessibility tree rather than CSS selectors — so a run does not break the next time someone renames a class.
It will only visit domains you list. The list defaults to deny and is enforced three times: before navigation, on every request the page makes, and again when the page arrives, because a server-side redirect does not pass through the first check twice. When a site needs a login, it opens a window you can see and you sign in yourself — the bot never handles the password, and the session persists in the profile afterwards.
Routines and memory
Routines
Turn a finished run into a scheduled job. The routine carries only the tools that actually succeeded during the run, so a repeating job cannot reach further than the run you approved. Routines fire while the application is running — this is a desktop app, not a server, and a closed laptop runs nothing.
Memory
Each bot keeps notes in plain Markdown, alongside notes shared across the workspace. Both are files you can read and edit. There is no vector store and no retrieval step; the notes are prepended to the prompt in a fixed order.
Handoff
A bot can pass a task to another bot in the same channel. The second bot picks it up in its own thread under its own permissions, and handoffs are depth-capped so a pair cannot bounce work between themselves forever.
Durable sessions
Sessions live in a local database. An approval waiting on you is still waiting after a crash or a restart — asserted on every commit by a test that kills the process mid-approval and reattaches to the session.
What leaves your machine
Prompts, instructions, workspace notes and anything a tool reads go to the model provider, because that is what running a model means. Connector traffic goes to that connector’s service. An optional webhook can notify you when a run finishes, carrying a title and one line — never thread content.
Beyond that, nothing. No telemetry, no analytics, no crash reporting, and no Lobstack service for it to call.
Downloading it
Public beta, and downloadable. The published release carries a Windows, a macOS and a Linux installer, and the Lob Bot page serves all three.
It did not, for a while, and the machinery that withheld it is still in place. The first Windows build installed, launched and then sat there: the shell handed the extended-length path form to Node, Node read it as drive-relative, and the daemon never started listening. Its engine also defaulted to a mock, so every reply would have been simulated with a cost line on it and nothing in the interface would have said so.
A download button that works is worse than no button when the file behind it is broken: the visitor concludes the product is broken, and that is the one impression that cannot be taken back. So there is a version floor in src/lib/lob-bot-release.ts, and both the download route and the page read the same lookup. A release below the floor is not served, however green its CI run was. The page asks /api/download/lob-bot/status when it loads and draws whichever surface the answer describes, so a release crossing the floor turns the buttons on by itself, with nothing to redeploy and nobody to remind — and the status route only ever offers a platform the release actually carries an installer for.
Still outstanding: code signing, which is what an unsigned Windows installer needs before it stops warning everyone who runs it, and which requires identity validation rather than work; and uninstall, which does not yet offer to remove your workspace folder or export it. Auto-update is no longer on this list — every build asks /api/lob-bot/update/… whether a newer release exists, and that route answers.
Announcements go out on x.com/lobstack and in the changelog. If you are building against the Gateway today you do not need Lob Bot for anything — mint a key in Console → API Keys and start with the Quickstart.