DEV Community: Bees

Why execution stays local

Bees — Tue, 06 Oct 2026 09:37:51 +0000

This post first appeared on the Bees blog.

Most agent platforms ask for your files. Upload the folder, connect the drive, grant the scope — then the work happens on someone else's computer. That is a reasonable trade when the files are a support inbox. It is a bad trade when they are contracts, payroll, patient records, or source code.

Bees draws the line somewhere else. Agent runs happen on your computer, against files in storage you already control. What synchronizes to Bees Cloud is coordination metadata: which process a work item sits in, which status it moved to, which agent picked it up, and relative filenames and paths. Not the file contents.

Why it is a boundary and not a setting

A privacy toggle is a promise about behaviour. A boundary is a statement about where the code runs. If execution happens on your machine, there is no server-side copy to leak, subpoena, or accidentally log — regardless of what any setting says.

That choice has consequences worth knowing before you adopt it:

Your machine does the work. Throughput is bounded by your hardware and your model access, not by a plan tier.
Coordination still needs the network. Teams that never connect still run, but they do not see each other's progress.
Model choice is yours. Run local models, use an existing Codex or Claude Code subscription, or point at a model API. The file contents go wherever you point them — which is exactly why the decision stays with you.

Where this shows up in practice

The clearest case is a regulated team that wants agents but cannot move documents off managed storage. They keep the documents where compliance already approved them, install Bees on the machines that already have access, and get shared status across the team without the files ever becoming someone else's asset.

Start with Getting started, or read why Bees exists for the longer argument.

Your keys and logins stay on your computer

Bees — Tue, 06 Oct 2026 09:36:35 +0000

This post first appeared on the Bees blog.

An AI agent that does real work needs real access. It needs an AI key to think with, your Google account to read your mail or Drive, and a logged-in browser for the sites that have no API.

Most hosted agent products keep all of that on their servers. You paste your key into their web page. You click "Connect Google" and the refresh token (the long-lived pass that lets an app back into your account) goes into their database. Their browser runs in their cloud, holding your cookies.

That works, but it means one company holds a copy of every key and session its users have. One breach, one careless log line or one curious employee reaches all of them at once.

Bees does it the other way. The agents run on your computer, so the keys and logins can stay there too. Here is where each one lives, and what our server sees.

AI keys

When you add a key for OpenAI, Anthropic, OpenRouter or Google, Bees first sends one small test request straight to that provider to check the key works. Only then does it save the key on your computer.

After that, your prompts go straight from your computer to the provider. No Bees server sits in the middle, so we never see the key or the prompts. Google keys go in a request header rather than the web address, because addresses end up in logs far more often than headers do.

The default model runs on your own computer. With it, your prompts are not sent to any AI company.

Google: Gmail, Calendar and Drive

Connecting a Google account happens on your computer. Bees opens Google's consent page in your browser. Google then sends you back to a small listener on your own machine (127.0.0.1), which shuts itself down after a few minutes.

The tokens Google hands back are saved on your computer. The Gmail, Calendar and Drive add-ons read them from there and call Google directly. Our server never receives them.

Signing in to Bees itself with Google is different, and we want to be clear about it. Our server learns your name and email so it can create your Bees account. It does not get access to your mail, calendar or files.

Browser logins

Some work only happens in a browser: a site with no API, or a dashboard behind a login. A hosted agent runs that browser in its own cloud, so your cookies, the things that keep you logged in, live on its machines.

Bees drives the Google Chrome already installed on your Mac, with a separate profile that belongs to Bees. Your everyday Chrome profile is not touched. You log in to a site once inside the Bees profile, and those cookies stay in that profile's folder on your disk. Bees also saves a copy of them to a local file, so you stay logged in after a restart. None of that code talks to our server.

We use your real Chrome instead of a bundled test browser for a practical reason: Google refuses sign-ins from browsers that announce they are automated. For now the agent's browser works on Mac only.

Where the keys are kept

AI keys, Google tokens, add-on keys and your Bees session all go into one credentials file in the Bees folder under your home directory. On Mac and Linux, Bees creates that file so only your user account can read it, and refuses to start if someone loosens that.

The screen where you manage AI keys is only told whether a key is set, never the key itself. When a run's history shows a tool call, values with names like token, password or API key are shown as hidden.

What our server does see

Bees Cloud is optional. It exists so a team can see each other's work. When you use it, the app sends seven kinds of records, each with a fixed list of fields:

the names and settings of your processes, agents and schedules
work item titles, status and who owns them
file names and paths relative to a shared folder, never full paths from your disk and never file contents
a summary of each run, capped at 20,000 characters

It never sends keys, tokens, cookies or file contents. One honest caveat: a run summary is the agent's own words about what it did, so it can mention things from your files.

The app sends no usage analytics and no crash reports. It starts its agent engine with telemetry switched off, and there is no analytics code in it. It does ask our server for its sign-in settings when it starts, even if you never sign in. That request carries no account token and no usage data, but like any request it shows us your IP address. It also asks GitHub whether a new version is out, when it starts and every six hours. That request goes to GitHub, not us. It names only the update tool Bees uses, not you or your Bees version, and your computer compares the versions itself.

What this does not protect you from

A cloud model sees what you send it. If you pick a cloud AI model, the text an agent works on goes to that AI company under its own terms. Use the local model when that matters.
The credentials file is not encrypted. It is protected the way your SSH keys are, by file permissions. That stops other users on the same computer. It does not stop malware running as you.
A run folder is not a full sandbox. Bees gives each run its own folder with only the files it needs. That narrows what an agent can touch, but it is not a wall against hostile code.
Your computer has to be on. Agents run on your computer, so they only work while it is awake.

We think this is the right trade for a desktop app that handles work files and real accounts. If a hosted tool fits you better, that is a fair choice too. Just ask it where your refresh tokens live.

If you want to try Bees on your own machine, download it here.

How Bees runs team work without a central dispatcher

Bees — Tue, 06 Oct 2026 09:36:28 +0000

This post first appeared on the Bees blog.

Most systems that run jobs on many machines have a dispatcher. That is a central server that keeps a queue of jobs, picks a machine for each one and hands the job over. It works well when every machine is the same and any of them can do any job.

Bees computers are not the same. A Bees agent runs on your computer, next to your files, your sign-ins and the add-ons you connected. A report that reads a shared folder and your Gmail can only run on a computer where that folder is linked and the Gmail add-on is connected. A server far away cannot know that as well as the computer itself does.

So in Bees, each computer decides what it can run. Our server, Bees Cloud, does two small jobs. It keeps a lock so two computers do not run the same work, and it keeps a shared record so your team can see where the work is. It never tells a computer to start anything.

The parts

A few words first, because the rest of the post uses them.

A process is a list of stages, like Draft, Review and Done.
A work item is one piece of work moving through a process. One weekly report is one work item.
An agent is an AI worker with its own instructions, model and tools. An agent does each stage.
A schedule creates a new work item at a set time, like every Monday at 9:00.

Each computer runs its own copy of Temporal, an open-source workflow engine. Temporal writes down which stage each work item is at, so an app restart does not lose its place. Bees keeps that record in a file on your disk. There is no shared Temporal server.

What each computer decides

Everything about running the work happens on the computer.

Whether it can run the item at all. Before work starts, the computer checks itself. It needs an enabled agent for the work. The add-ons that agent uses must be connected on this computer. The folders the item reads must be linked to real folders here. If any check fails, the work waits and the computer checks again on its next pass.

Which agent does each stage. The computer picks in this order: the agents named on the work item (except for a review stage), then the agents set for that stage in the process, then the workspace's default agent, then the first enabled agent by name. A review stage never uses the agent that did the work it is reviewing. The computer saves each pick with its reason, so you can see later why an agent got the work.

What happens when an agent is busy. An agent can have a limit on how many runs it does at once. If it is at that limit, the stage waits and checks again every 15 seconds. After 10 minutes it shows as failed, so a person can see it and press Retry.

Moving between stages. When an agent finishes a stage, the item moves to the next one. When a reviewer asks for changes, the item goes back to the stage that did the work. The third time a reviewer asks for changes, the item stops and waits for a person. A stage that fails also waits for a person to press Retry.

Approvals. You can mark a stage to need a person's approval. On that stage the agent cannot send, post, delete or pay through an add-on until someone approves, and the stage cannot finish without it. The agent asks in the Bees app on the computer running the stage, and the run pauses until someone answers it there.

What Bees Cloud holds

The server keeps three things for this.

An owner for each work item that runs. When a computer starts a work item, Bees Cloud records that computer and the person signed in on it as the owner. This lock does not run out and does not need renewing. It stays with that computer until the owner hands the run over. No other computer, yours or a teammate's, can take it in the meantime.
A key for each scheduled time. When a schedule fires, the computer asks for a key made from the schedule and the time. The first to ask gets it. That key never runs out, so the same 9:00 can never run twice for the same person.
The shared record. Every 15 seconds each computer syncs: it sends the stage and status of its work items and a summary of each run, and fetches what the rest of the team sent. The newest version wins, going by the clock on the computer that made the change.

Schedule keys are kept per person, so when two of your computers ask for the same 9:00, only one of them gets it. The owner of a work item is kept per team, so it holds against everyone on the team.

The server only answers yes or no. It has no queue, it never picks a computer and it never moves work anywhere. Computers call it. It never calls them. If you do not use Bees Cloud at all, there is nothing to ask, and your computer skips the lock and runs the work.

Handing a run over

A run only moves when its owner moves it. On the computer that owns the run, the owner presses Relinquish control. Bees stops the run and any work it handed to other agents. It writes a checkpoint file into the run's folder, and tells Bees Cloud the run is free and which stage each piece restarts at.

Then someone presses Continue on this machine on another computer. That can be another of your computers or a teammate's. That computer needs the run's folder, either through a shared folder linked on both computers or as a copy from the owner. It checks that the checkpoint and every file in it arrived unchanged, and runs the same checks as any other start. Only then does it claim the run and start the unfinished stage again, using the saved files. A review stage restarts from the stage that made the work being reviewed.

A real example: Maya's Monday report

Maya has a process called Weekly report with three stages: Draft, Review and Done. She scheduled it for every Monday at 9:00. She uses Bees on a laptop and a desktop, both signed in as her. Sam is on her team.

9:00. Both of Maya's computers fire. The schedule has synced to both. Each one's Temporal fires it at 9:00, and each asks Bees Cloud for the key for this report at Monday 9:00.
The laptop asks first and gets the key. The desktop is told no and skips this Monday. Nothing else happens on the desktop.
The laptop creates the work item and claims it. Right away it sends the new item to Bees Cloud and becomes its owner. Then it starts Draft. It does not need to renew anything.
The desktop sees the item arrive. On its next sync, within 15 seconds, it shows the report as running on Maya's laptop. It never asks to run it.
Sam sees the report in his Bees. His app shows the report at Draft, but his computer never runs it. A team schedule only fires on the computers of the person who owns it, and his app never asks for a run that another computer owns.
9:04. Maya closes the laptop lid. The laptop sleeps in the middle of Draft. Bees Cloud does nothing about it and sends nothing to anyone. The report still belongs to the laptop, so the desktop does not start it.
9:20. Maya opens the laptop. The laptop still owns the report, and Draft carries on there. If the sleep cut the agent off, Draft shows as stopped until Maya presses Retry.
9:30. Maya has to leave and wants the desktop to finish. On the laptop she presses Relinquish control. Bees stops Draft, saves the checkpoint in the run's folder and tells Bees Cloud the report is free.
Maya presses Continue on this machine on the desktop. The run's folder is a shared folder linked on both computers, so the checkpoint and files are already there. The desktop checks them, claims the report and starts Draft again from the top. It picks the agent the same way the laptop did.
The desktop finishes the report. Draft, then Review, then Done. Each move syncs, so Sam watches the report move along. If a stage needs Maya's approval, she answers it in Bees on the desktop, because that is where the stage is running.

At no point did the server choose the desktop. Maya chose it, and the desktop checked itself before it took the run.

What this costs

Work waits for the computer that owns it. Nothing on our side can run your work. A run waits while its computer is asleep or offline, even if another of your computers is free. Only the owning computer can hand it over, so a laptop that is lost or broken keeps its runs. The other computer also has to pass the same checks. If the report reads a folder that is only linked on the laptop, the desktop cannot continue it.
A missed time is skipped. If none of your computers is awake with Bees running at 9:00, or the first one wakes more than a minute late, that Monday's report does not run. It does not catch up later. A laptop opened at noon will not fire a pile of old runs, but you also lose that week's run.
A handover repeats the stage. The new computer starts the unfinished stage from the top, using the files saved in the run's folder. Files never go through our server, so that folder has to reach the other computer through a linked shared folder or a copy. A handover takes at most 1,000 files, 20 MB each and 250 MB in all. If the stage had already sent an email, the new computer may send it again.
Nothing moves on its own. An earlier version handed a run to another computer when the first one went quiet for a minute. That meant two computers could run the same stage at once, after a Wi-Fi drop or a laptop waking up. Now a person has to hand the run over, so a stage never runs in two places, but a sleeping laptop holds its work until it wakes.
The shared record trusts each computer's clock. When two computers change the same item, the change with the later time wins, and that time comes from the computer's own clock. A computer with a wrong clock can win when it should not.
Team schedules need our server at the scheduled time. A computer that cannot reach Bees Cloud at 9:00 cannot get the key. It tries five times and then gives up on that run.
The server still sees some things. Each run owner records a random id for the computer, the computer's name, the person and the work item it covers. A handover also records which stage each piece restarts at. Owners and schedule keys are never deleted, so the server keeps one record for every run and every scheduled time each person has claimed. The shared record holds the names, titles, stages, status and run summaries described in our last post.

A question for you

Making a person hand a run over, and restarting the half-done stage from the top, is the simplest thing that never runs a stage twice at once. It is also the part we are least sure about. If you have run work on machines that sleep, like laptops, what did you do with a step that was half done when the machine went away: move it automatically and accept the duplicates, save checkpoints inside the step, or keep work on one machine? Tell us what held up on Discord.

If you want to try Bees on your own machines, download it here.