Questions
The things worth asking first.
What Fletch does, what it deliberately does not do, and where the sharp edges are. If something here is unclear or missing, ask on GitHub.
- What is Fletch?#
- A native macOS app for running AI coding agents on real work. It runs Claude Code, Codex, Cursor and others in sealed workspaces, each with its own clone of your repo inside an OS-level sandbox, serves every agent an index of your codebase, and chains them into workflows that plan, build, review and test. You review every diff and approve every merge. Running several agents at once comes with that, but it is not the point.
- Is this another agent wrapper?#
- No, and the test is concrete: Fletch does not proxy your models. It drives the agent CLIs you already installed and pay for, so there are no middleman keys, no markup and no API in between. If Fletch vanished tomorrow, your subscriptions and CLIs would work exactly as they do now. What it adds is the layer those CLIs do not have: isolation per agent, a served index of your codebase, a workflow engine with enforced budgets, one consistent view across harnesses, and review gates before anything merges.
- How do agents find their way around my codebase?#
- They query an index instead of grepping for everything. Fletch indexes your repo's symbols and call graph and serves it to every agent over MCP, so an agent can ask where something is defined and what calls it rather than reading files until it finds out. The index is built in a throwaway mirror clone and copied into each agent's workspace, so nothing is ever written to your repository, and a file watcher keeps it current as the agent edits. Two things worth knowing: it is built on codegraph, which Fletch vendors and drives rather than reimplements, and it is best effort, so if indexing fails an agent falls back to searching files and your task still runs. Indexing is on by default and can be turned off in Settings. Nothing about it leaves your machine.
- How is this different from Conductor, Crystal or Vibe Kanban?#
- Those tools solve running several agents at once, and they solve it well. Fletch starts from the position that parallelism is the ante rather than the product, and that the harder problem is trusting what comes back. Three things follow. Isolation is structural: a full clone per agent inside an OS-level sandbox, so parallel work cannot corrupt shared state even when an agent misbehaves. Agents are given the codebase rather than left to grep it, through a symbol and call-graph index served over MCP. And workflows advance on evidence: a step is done when a verifiable condition holds, such as tests passing, a commit landing or your approval, rather than when a model says it is done. Budgets for turns, iterations, wall-clock time and tokens are enforced by the engine, not requested in a prompt.
- Why not just tmux and a few git worktrees?#
- That is the right instinct, and for one or two agents a worktree and a
shell alias is genuinely enough. It starts to strain around three for two
reasons. Worktrees share one
.git, so shared git state is writable by every agent, and past a handful of agents you become the process scheduler: which agent is in which directory, which branch it was on, two dev servers fighting over the same port, and nowhere to see who is stuck or waiting on you. Fletch gives each agent a full clone that shares git objects, so spawning stays nearly free while the writable.gitstays inside that agent's sandbox. The long version is in worktrees vs clones for AI agents.
- Do agents get access to my working copy?#
- No. Each agent works in its own full clone under
~/.fletch/workspaces/, sealed in an OS-level sandbox that denies writes anywhere else. Your checkout is never writable by an agent, and neither is your repo's.git. See isolated workspaces. - Is the sandbox a real sandbox, or just a folder?#
- It is enforced by the OS, and it is worth being precise about what that does and does not cover. The default engine is macOS Seatbelt, which is write protection: an agent cannot write outside its own workspace, but it runs as your user, so it can still read what you can read and it has network access. It is not a VM. The opt-in Docker engine runs each agent in its own container that sees only what is mounted into it, which closes off reads as well, though the network is still open. Full detail, including the honest threat model, is in security and sandboxing.
- Can an agent push code under my name?#
- Today, yes, and you should know that before you point it at anything sensitive. Your credentials never enter the sandbox: pushes and pull request creation run on the host through a brokered channel, so an agent cannot read your token. But those operations currently run without a confirmation prompt, which means an agent can publish under your identity. Choose tasks and repos accordingly. A confirmation step for publishing actions is a known gap.
- Does Fletch send my code anywhere?#
- No. Your code, prompts and transcripts stay on your machine, and nothing routes through a Fletch server. The agent CLIs talk to their own providers exactly as they do when you run them yourself. See privacy.
- Does it collect telemetry?#
- Anonymous usage analytics are on by default, and you can turn them off in Settings, General, Usage analytics. Events are identified by a random per-install ID and never include your code, file paths, repository names, branches or prompt content. The full list is five events: app opened, app updated, agent spawned, turn completed, and pull request opened. Crash reports are separate and also toggleable. See privacy.
- What do I need to run it?#
- macOS 13 or newer, git, and at least one agent CLI. Onboarding checks all three and can install git or an agent CLI for you, and connect GitHub with a device code. The build is universal for Apple Silicon and Intel, signed, notarized and self-updating. No account is needed to start.
- Which agents are supported?#
- Claude Code, Codex, Cursor Agent and OpenCode are supported. Pi and Antigravity are experimental. You install and authenticate each CLI yourself, or let Fletch install it where that is available, and Fletch detects them on your PATH. Your subscriptions stay yours.
- Do I need Docker?#
- No. Seatbelt is the default engine and needs no setup. Docker is an optional second engine you pick in Settings when you want container-level isolation, and every harness except Antigravity supports it.
- Do I need the GitHub CLI?#
- No. Cloning, creating repos and opening pull requests run on a built-in connection you authorize once with a device code. Opening a local folder, spawning agents, committing and running your project need no GitHub at all.
- Why macOS only? Is Windows or Linux coming?#
- The default isolation engine is macOS
sandbox-exec, which has no direct equivalent on other platforms, so cross-platform support means building a different isolation story rather than porting a UI. Windows and Linux are on the roadmap. - Is it an Electron-style memory hog?#
- It is a native app built on Tauri 2 with a Rust backend, using the system WebView rather than bundling a browser. The download is a fraction of a typical Electron app.
- It is in beta. Why would I trust it with my repo?#
- Fletch is in public beta. The core, meaning sealed workspaces, the code
index, workflows and pull requests, works today and is in daily use. The known
sharp edges are answered on this page rather than buried, and the
changelog shows how quickly things actually ship.
The structural reason to be comfortable: agents never touch your working
copy, so the worst case from a bug is a broken clone under
~/.fletch/workspaces/, not a damaged checkout. - Is it free?#
- Yes. Fletch is free and open source, and because it drives the agent CLIs you already pay for, it adds no subscription of its own.
Already using Fletch? Day-to-day questions live in the docs FAQ: where workspaces are stored, archive versus discard, forking, and what to do when a CLI is not detected.
Download Fletch