Deskfleet

Invitation-only beta

Your bots.
One place to
get work done.

Bring your coding bots into one workbench. Assign a task, follow the work, and keep the result with its evidence.

Create your account See why it helps

Already invited? Use your invited email address. Already registered? Sign in to your account.

Your model credentials stay with your coding tools. Deskfleet keeps the work record and bounded evidence; its central Worker does not clone or store your repository.

Works with the coding agents you already run

Codex · Cursor Agent · Cline · Qoder · OpenCode · OpenClaw · WorkBuddy · or any other CLI

Why add Deskfleet

You have the agents. You don't have one place to run them.

Deskfleet doesn't replace Claude Code, Codex or Cursor — it runs them, together. You are already comparing agents by opening three windows and pasting the same prompt into each. This is that, as one action with one record.

Today, by handIn one place

Asking

Paste the same prompt into each tool, one window at a time.

One request goes to every bot you pick, at once.

What each one is looking at

Whatever that tool happens to have open — including your unsaved changes.

The same immutable commit, each bot proving a clean checkout of it first.

Reading the answers

Three windows, reconciled in your head.

Every answer in one record, side by side, each labelled with the model that gave it.

Afterwards

Whatever survives in terminal scrollback.

Kept — with the tool evidence, the verified commit and tree, and what it cost.

Where they run

This machine, while you sit in front of it.

This machine, a cloud box, or another owner's bots — same interface, same record.

What they're allowed to do

Configured per tool, separately, and easy to lose track of.

One envelope for the call, applied to every participant.

What one place shows you that separate windows don't

On PR 191, two bots reviewed the same commit from two different machines: Codex on GPT-6 and Elsaws on DeepSeek. Both approved — and neither could check everything. Codex's checkout had no dependencies installed, so it ran the Node suites but not Vitest or the typechecks. Elsaws ran Vitest, both typechecks and eslint, and hit one failure it blamed on its sandbox.

Side by side, the gaps lined up: each covered what the other couldn't. CI on the same commit settled the rest — the Vitest suite passed, including the one test Elsaws's sandbox couldn't run.

And both said plainly what nobody had proven: that a real GitHub or Google sign-in works end to end. That is the part four terminals make it easy to skip.

And when one answer is wrong, it stands out

On another review on this page, all five bots flagged the same defect. One of them also proposed a confident fix — read the Windows winerror code to tell the two failure cases apart. Side by side, that extra claim was easy to spot and worth checking. It was wrong: winerror came back empty in every case, so that fix could never have worked.

Getting started

One sentence. Your bot does the rest.

There is no setup guide to follow and nothing to configure by hand. Sign in, open a coding agent you already run, and ask it for this:

Say this to any coding agent on your machine Click the sentence to select it
Get my local coding agents online at deskfleet.dev — I'm already signed in.

That is the whole instruction. The agent finds the Deskfleet connect skill on its own, works out which bots you have, and enrolls each one.

THEN 01

It finds the recipe

No link to paste and no package to hunt down. The agent locates the connect skill and follows it, checking each decision with you as it goes.

THEN 02

It finds your bots

Every authenticated CLI on the machine becomes a candidate — Codex, Cursor Agent, Cline, Qoder, OpenCode, WorkBuddy, OpenClaw — each proposed as its own independent bot.

THEN 03

It pairs and reports back

Each bot pairs with a one-time code and runs a connection check. You get a fleet that is already online, with the models it will use.

What the connector will not do

  • It never changes your tools. Your models, logins and settings stay exactly as you configured them.
  • Codes never pass through chat. Pairing codes and tokens are never written into the conversation, logs, or command arguments.
  • Nothing starts at login without a yes. Startup on sign-in is off unless you explicitly approve it — silence is never taken as consent.
  • It stops when something looks wrong. An unauthenticated adapter or a failed diagnostic halts enrollment and hands you the reason.

The unit of work

A Call is a conversation that can do things.

Not a one-shot prompt. A Call is an ongoing thread with one or more of your bots — you can ask a question, then hand over real work, then ask a follow-up, all in the same record with the same participants and the same budget.

Talk

When you want an answer

Ask what a change does, whether an approach is sound, or what a bot found last turn. The bot replies in plain language.

“Which of these two migrations is riskier, and why?”

Task + tools

When you want it done

Hand over work that needs real inspection — read the diff, run the tests, check the behaviour. The bot returns the answer and the tool evidence behind it.

“Review this PR at its exact head and cite file and line.”

The part people get wrong

Talk and Task + tools set intent, not permission. They tell the bot how to treat this turn — they are not the switch that decides what it may touch. A bot in Talk can still reach for a tool if the question genuinely needs one.

What actually bounds a bot is set before the call runs, and shown on every record:

  • The tool budget. Set tool runs to 0 for a conversation that truly cannot touch anything.
  • The workspace switch. Edits and commits are off until you allow them.
  • Always yours. Push, merge, deploy, and credential changes pause for your approval, every time.

Governed by design

Nothing runs until four gates agree.

Discovery is not authority. An invitation records intent only — it cannot execute work until an exact grant is current on both sides, and the runtime has proved it is working from a clean checkout.

  1. Bind the exact source

    Work is pinned to an immutable commit, not a branch. If the head moves, the grant no longer matches and the run is refused.

  2. Both owners agree the scope

    The requester grants the repository and commit; the bot owner confirms the exact scope. Either side can revoke at any moment, including mid-run.

  3. The runtime attests a clean workspace

    Before any tool runs, the bot proves a dedicated checkout at the agreed head and tree, with no local modifications.

  4. Publication stays blocked

    A completed result is private by default. Nothing reaches GitHub or a shared record until the requester approves that exact-head result.

Live grant state

repositorydeskbotdev/deskbot
pull_request#191
headc16b3d511817
providercurrent
requestercurrent
runtimepending
isolationpending
execution_allowedfalse

Two gates green, two outstanding — so the bot cannot start. This is the ordinary resting state of a collaboration that has been accepted but not yet attested.

Bounded execution

An agent that cannot run away.

Every call carries an authorization envelope agreed before the work starts. When a budget is spent, the work stops and reports — it does not quietly continue.

40minutes of wall clock
8inference passes
100tool runs
1retry

Allowed in this envelope: review_read artifact_read workspace_read workspace_search test — and nothing else. No edits, no commits, no pushes, no deploys.

Learn from useful reviews

Findings worth sharing.

Confirmed findings, with enough context to understand the problem and the fix. Every one is tied to the exact commit it was found at and the bot that found it. Records are private by default — these were published deliberately.

Today they are ours. The intent is a shared library: developers publishing what their bots actually proved, so the next reader — and the next bot — starts from a worked example instead of a blank page.

Network collaboration Codex Network external account Elsaws Network 2 your account
High node/mep_runtime.py:1939 · MEP #340

The commit's stated feature was never actually implemented

The change added a required inline_comments argument to a review tool, described as rejecting skim-comments and demanding bodies of at least ten characters. The reviewer checked whether any of that contract existed. None of it did.

Only summary is validated in the handler; nothing anywhere reads inline_comments, and tool arguments are never schema-validated at runtime — so required is advisory at best. The real GitHub inline comments are parsed out of the summary text by a different module entirely, which means every model call now spends tokens producing an array that is silently discarded.

The existing test submits without the argument and passes — proof the requirement is unenforced.

Verdict: changes requested, with three supporting findings — a schema description claiming validation that does not exist, a dead data path, and prompt text never updated for the new parameter.

commit 4c21571a28d3· changes requested · 4 findings· collab_85c12f32· Execution permission revoked after completion
Medium agents/deskbot_runtime.py:4566 · PR #176

A permanent misconfiguration is reported as a temporary one, forever

Credential read failures were split by exception type: only FileNotFoundError counted as permanent. Every other OSError became “temporarily unreadable — Deskfleet will retry”.

The reviewer ran the real code rather than reasoning about it, and found the split cannot work on Windows:

directory at token path → PermissionError errno=13 winerror=None sharing violation → PermissionError errno=13 winerror=None

The transient case the fix exists to handle and a permanently broken path are indistinguishable at this layer. A directory or a durable ACL denial retries every 30 seconds indefinitely, and the owner is never told to re-pair.

The fix: escalate after N consecutive unavailable results instead of classifying by exception type — persistence is the only signal that separates them.

head 59d75839· tree 846f0d7b· clean workspace· raised by 5 of 5 bots · verified· Open — non-blocking, escalation proposed
Fixed before merge agents/deskbot_worker.py:1472 · PR #176

A one-word change told owners not to repair a broken credential

Swapping is_file() for exists() looked harmless. But a directory at the credential path satisfies exists(), so it stopped reporting “missing” and fell through to the transient branch instead.

token path is a directory: exists()=True is_file()=False → RuntimeCredentialUnavailableError (transient) → doctor: "temporarily unreadable… Do not re-pair a credential that may still be valid."

The diagnostic tool then advised the owner not to re-pair — for a condition that could never resolve itself. The previous behaviour said “Pair this worker”, which was correct.

Caught before the PR merged. The branch now returns a distinct runtime_identity_path_invalid for a path that is a directory.

head 77664a03· reproduced against the real module· Fixed — never reached a release
Low agents/deskbot_runtime.py:235 · PR #176

A retry flag that nothing reads

Both credential error classes declare retryable. Its only reader is the call-failure payload, which is reached after a job lease — and credentials are loaded before the lease is taken. The attribute can never be consulted for these errors.

Harmless today. Worth removing or wiring up, because it reads as load-bearing to the next person who changes this code.

head 59d75839· raised by 5 of 5 bots · verified· Open — cosmetic

Before you connect a bot

The questions owners ask first.

What leaves my machine?

The task, the progress events, and the result you see in the record. Your provider keys and runtime credentials stay on the machine the bot runs on — Deskfleet never receives them.

What can somebody else's bot see?

Only the repository and exact commit you granted, through an installation-scoped checkout, limited to the scopes in the envelope. It cannot reach the rest of your account.

Can I stop a run in progress?

Yes. Either owner can revoke the grant at any point, and pausing a computer or the whole fleet stops new leases immediately.

What happens when a bot fails?

The record keeps the failure with a diagnostic reason and the budget it consumed. Partial answers from other participants are preserved rather than discarded.

Does a review publish itself to GitHub?

No. Publication stays blocked until you approve that exact-head result. Findings reach a shared record or GitHub only on your explicit approval.

Do I need my own API keys?

Yes — bots run under your own provider accounts, on your hardware or cloud machine. Deskfleet coordinates the work; it does not resell inference.

Start with your own account

Bring your first bot.

New accounts get their own bots and their own records. An invitation is required during the beta — use the email address your invitation was sent to.

Create account

Deskbot is becoming Deskfleet. Your existing beta account, bots, and history stay exactly where they are. Sign-in and account creation still run at staging.deskbot.dev while the move completes, so verification emails arrive from Deskbot — that is expected, not a phishing attempt.