The Lobstack app

The Lobstack app 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 part of Lobstack that runs on your machine rather than as a service. There is nothing to provision and no machine of ours behind it. By default its model calls go through the Gateway, after one sign-in; the other engines call no server of ours — see below.

The app opens a page on lobstack.ai in your browser and shows a six-character code. You sign in (or create an account), check that the page shows the same code, and press Connect. The app picks up the result by itself a few seconds later. If the codes differ, or you did not just press Sign in, press Cancel: someone may have sent you their link.

What the app receives is an ordinary API key for your organization, named Lobstack app — <your computer>, with the inference and usage:read scopes. It is listed in the Console under API keys, and revoking it there disconnects that copy of the app. The key is created at the moment the app collects it, so it is never stored anywhere waiting to be picked up; lobstack.ai keeps only its hash, like every other key.

The first time an organization connects the app it gets $5 of credit for 30 days, spent only after the month’s plan allowance is used up — see Welcome credit. After that, a Free organization has the Free plan’s $1 of model spend a month.

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.

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.

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 workspace database holds only a reference; the secret itself is AES-256-GCM in a file the vault owns. 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 desktop shell asks the operating system’s own credential store for the key and hands it to the daemon, so the encrypted vault can travel and the key does not. All three platforms are wired: Credential Manager on Windows, Keychain on macOS, Secret Service on Linux. It is one code path over a single keyring binding with all three platform backends compiled in, not a Windows path with two stubs behind it.

It fails soft, on purpose. When the store cannot answer — no Secret Service on a minimal Linux desktop, a locked Keychain, a prompt you declined — the daemon falls back to the owner-only key file the vault used before, beside the vault itself, and starts. A workspace that will not open is worse than one whose key is less well protected, so the shell writes the reason to its own log and starts the daemon anyway.

Two consequences worth knowing. An existing key file is adopted into the credential store rather than replaced or deleted, so moving to the store does not strand connectors you already configured, and downgrading still finds its key. And what the store defends against is a copied home directory, a backup or a synced folder — not another process running as you, which can read the environment the key arrives in exactly as it could read the file.

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.

Prompts, instructions, workspace notes and anything a tool reads go to the model, because that is what running a model means: through the Gateway on the default engine, where they are handled like any other Gateway call, or straight to Copilot or your own provider on the others. 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, and beyond signing in, one thing and no more. No telemetry, no analytics and no crash reporting; the only other call it makes to us is the update check, which asks /api/lob-bot/update/{target}/{arch}/{version} whether a newer release exists. That URL is the whole request: your platform, your architecture and the version you are already running. Nothing about your bots, your connectors or your threads is in it, and the answer is a manifest or an empty 204.

Public beta. What there is to download is not something this page can state, because the site resolves it per request rather than carrying it in source. The app targets three platforms — Windows, macOS and Linux — and the buttons on the download page are whichever of those the newest qualifying release can actually serve. When nothing qualifies, the page says there is nothing to install and offers to tell you when there is, rather than showing a button that would 503. The rule it applies:

All three platforms are named either way, linked where there is a build and named plainly where there is not, so a missing installer reads as missing rather than as a platform that was never planned.

The floor exists because of one release. v0.1.0 is published, carries a Windows installer, and does not work: the shell handed the extended-length path form to Node, Node read it as drive-relative, and the daemon never started listening, so the application installed, launched and then sat there. 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 the floor sits in the lookup both surfaces read rather than in a note somebody has to remember. The page asks /api/download/lob-bot/status when it loads and draws whichever surface the answer describes; the route that streams the file resolves the same lookup again before it streams, and answers 503 rather than serving something the page would not have offered. A release crossing the floor turns the buttons on by itself, with nothing to redeploy and nobody to remind.

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 the app for anything — mint a key in Console → API Keys and start with the Quickstart.