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 — see Welcome credit. A Free organization also gets $1 of credit every week, topped back up each Monday (Weekly credit). Credit that runs out soonest is spent first, so the weekly credit usually goes before the welcome credit.

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.

You can also answer from your phone. Pair one in Settings → Phone approvals. Payments still need the computer, and scheduled runs never ask.

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.

54 name a service. Most connect with a Sign in button that opens the service's own login; the rest take a token you paste, or run on your computer. 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.

Every bot can search the web, read a page and use a browser. There is no connector to add and nothing to download: it drives the browser already on your computer (Edge on Windows, Chrome or Edge elsewhere) with a profile of its own, through the page's accessibility tree rather than CSS selectors.

Searching and reading happen without asking. Clicking, typing or choosing on a site waits for your yes, and a routine running while you're away never does them. Search runs on the Lobstack API when you're signed in; on Copilot or your own key, the bot searches through its browser. When a site needs a login, open the bot's settings, choose Sign in to a website, and sign in yourself in a window you can see. The bot never handles the password.

Share a workspace with your Lobstack team and everyone in it gets the same bots, skills, templates, knowledge page and routines, kept in step through lobstack.ai. Open the workspace switcher and choose Share this workspace…, pick your team, and invite people by email. A teammate sees it under Shared with you and presses Add. It needs Sign in with Lobstack on each computer, and each person uses their own sign-in.

Shared bots’ prompts and skill text are stored on lobstack.ai under your team. Credentials, conversations and memory never are. Each person connects their own GitHub, Linear and so on, and approvals go to whoever runs the bot.

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. If you pair a phone, sealed copies of waiting approval cards pass through lobstack.ai. It can’t read them.

Beyond that, and beyond signing in, one thing on its own and one only when you ask. No telemetry, no analytics and no automatic crash reporting; the only call it makes to us by itself 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.

The one only when you ask is a report. When a run fails, a connector will not start, an update does not install or the app stops, there is a Send report button (and Send a report… in Settings → About & updates). It opens the exact text that would be sent: the app’s version, your system, the engine’s name, what failed with its error, and the last 200 lines of the app’s log, with keys, tokens, email addresses, your home folder and passwords in URLs taken out, plus a note and a reply-to address if you add them. It goes only when you press Send, and you can copy it instead. Nothing is sent automatically, queued, or retried, and it is stored without your IP address.

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 and carries a Windows installer, and it does not work: the app installs and opens, but the background service it talks to never starts, so it sits there. Its engine also defaulted to a simulated one, 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.