Local-first by design

Watchfire integrates
with what you already use.

Name: Watchfire
Author: Watchfire

Watchfire runs the agent you trust against the repo you already have, in the editor and shell you already use. Here’s what works today.

Agents

From Claude Code to Cursor.

First-class integrations

Built-in and tested.

Categories covered

Editors, agents, CI, secrets, version control.

Agents

These are the agent backends Watchfire runs. Pick the one you already use — Watchfire wraps it in a worktree, a sandbox, and a clean transcript.

First-class

Claude Code

Anthropic's CLI coding agent — the original Watchfire backend.

Claude Code is Anthropic's official command-line coding agent. It runs locally, reads and writes files in your project, and pairs with Claude models for long-running engineering work. It is the backend Watchfire was originally built around.

First-class

Codex

OpenAI's Codex CLI — long-running coding sessions with isolated homes.

OpenAI Codex CLI is OpenAI's command-line coding agent. It runs locally, drives long agentic engineering sessions, and reuses your existing OpenAI login and config from `~/.codex/`.

First-class

opencode

Open-source coding agent — bring your own provider.

opencode is an open-source CLI coding agent. You configure it against the model provider you want, sign in once, and it stores config and data under `~/.config/opencode/`.

First-class

Gemini CLI

Google's Gemini coding agent on the command line.

Gemini CLI is Google's command-line coding agent backed by Gemini models. It uses a shared global setup at `~/.gemini/` for auth and configuration, then accepts a per-invocation system prompt.

First-class

GitHub Copilot CLI

GitHub Copilot from the command line, running in yolo mode behind the sandbox.

GitHub Copilot CLI is GitHub's command-line Copilot agent. It signs in via `gh` or its own flow and stores config, MCP setup, and session history under `~/.copilot/`.

First-class

Cursor Agent

Cursor's headless agent CLI — distinct from the in-editor agent.

Cursor Agent CLI is the headless command-line companion to the Cursor editor. It runs autonomously via `cursor-agent --workspace ... --print` and reuses auth and config from `~/.cursor/`. It is distinct from the interactive agent inside the Cursor editor.

Version control

Watchfire is a git tool first. The host you push to is up to you — it stays out of your remote's way.

First-class

Git

The hard dependency. Every task is a branch, every branch is a worktree.

Watchfire is a git tool. Each task gets a dedicated branch (watchfire/<n>) and its own worktree at .watchfire/worktrees/<n>/. The daemon creates, merges, and cleans up branches for you — Git is what holds the whole model together.

Works

GitHub

The most common home for Watchfire repos — and the only host with first-party glue.

Watchfire pushes nothing on its own, but a few Watchfire features speak GitHub specifically — the auto-PR adapter, the GitHub PR-merge inbound handler that marks a task done, the badge embed, and the "edit on GitHub" link in the docs. Everything else is host-agnostic.

Works

GitLab

Self-hosted or SaaS — Watchfire pushes branches, you review them in GitLab.

Watchfire works against any git remote, so GitLab projects are first-class as a git host. The GitHub-specific bits (auto-PR adapter, PR-merge webhook) don't have GitLab equivalents yet — you open and merge MRs in GitLab itself, the same way you would without Watchfire in the loop.

Works

Bitbucket

A git host like any other — Watchfire's branch-and-merge flow doesn't care.

Bitbucket is a git host, and Watchfire's worktree model is built on git, so the two cooperate by being out of each other's way. Open the pull request in Bitbucket as you would for any other change — Watchfire's job stops at the merged branch.

Works

Forgejo / Gitea

Self-hosted git forges work the same as anything else.

Forgejo and Gitea-family forges are git hosts, so Watchfire's branch-per-task workflow drops in without changes. Watchfire's GitHub-specific webhook handler doesn't have a Forgejo equivalent yet, so the round-trip from "PR merged" to "task marked done" stays manual on these hosts.

Editors

Watchfire is not an editor plugin. Each task runs in a git worktree your editor can open, so anything that opens a folder works.

Works

VS Code

Open the worktree folder and review the diff like any other branch.

Watchfire is a CLI / TUI / GUI, not a VS Code extension. Each task runs in its own git worktree at .watchfire/worktrees/<n>/ — point VS Code at that folder when you want to inspect a task in flight, or at your main checkout to review the merged result.

Works

JetBrains IDEs

IntelliJ, GoLand, WebStorm and friends — open the worktree, review the branch.

Same model as VS Code: Watchfire works on git worktrees, and any JetBrains IDE that opens a folder can open one. Watchfire isn't installed inside the IDE — the IDE is just the place you read the code, including the merged result.

Works

Neovim / Vim

Watchfire runs in your other terminal pane.

Watchfire is a terminal-first tool, which makes it a natural fit for a Neovim/Vim workflow. Open the worktree folder in your editor, run the TUI in a split pane, and you can watch tasks land branch by branch without leaving the terminal.

Works

Cursor (the editor)

Distinct from Cursor Agent, the CLI. The IDE just opens the worktree.

Cursor the editor is a separate product from Cursor Agent, the headless CLI Watchfire runs as a backend. The editor cooperates with Watchfire the same way VS Code does — open the worktree folder, review the diff. The CLI is the agent in the loop, not the IDE.

Sandbox

Watchfire fences every agent inside a platform sandbox. The agent has full autonomy inside; the sandbox decides what "inside" means.

First-class

macOS Seatbelt

Kernel-level sandboxing on macOS — the default on every Mac.

On macOS, Watchfire wraps each agent in sandbox-exec with a generated Seatbelt profile. The profile blocks ~/.ssh, ~/.aws, ~/.gnupg, and .env files by default, restricts writes outside the worktree, and inherits into any child process the agent spawns.

First-class

Linux Landlock

The preferred Linux backend — zero external dependencies on kernel 5.13+.

On Linux kernels 5.13 and newer, Watchfire applies Landlock filesystem restrictions in a re-exec'd helper process before launching the agent. Landlock is a kernel LSM, so the agent process can't escape the rules — and there's nothing to install beyond the kernel itself.

First-class

Linux Bubblewrap

Fallback Linux backend when Landlock isn't available.

On older Linux kernels (pre-5.13) or in environments where Landlock isn't usable, Watchfire falls back to Bubblewrap. It's the same blast-radius contract — restricted filesystem, blocked sensitive paths — via user-space namespaces rather than the kernel LSM.

Secrets

Watchfire reads secrets from its own instructions file and from the environment your shell already provides. It does not replace your secret manager.

Works

OS keyring (macOS Keychain, libsecret)

Where Watchfire stores its own outbound adapter credentials.

Watchfire persists its own integration secrets — outbound webhook signing keys, Slack and Discord bot tokens, GitHub auto-PR credentials — in the OS keyring, with a file-store fallback when none is available. Saved through the gRPC surface, never read back over the wire.

Works

1Password / Bitwarden / pass

Use your shell's secret tooling — Watchfire reads from the environment.

Watchfire doesn't replace your secret manager. Source your secrets the way you already do — 1Password CLI, Bitwarden CLI, pass, direnv, anything that exports environment variables — and Watchfire's secrets-instructions file tells the agent how to use them.

Works

.env files

Blocked by the sandbox on purpose — describe them in the instructions file instead.

The Watchfire sandbox blocks .env files from the agent on purpose, so credentials don't leak into transcripts. Tell the agent what's in the file via .watchfire/secrets/instructions.md — the prompt-time instructions stay inside Watchfire, the actual values stay outside the agent's reach.

CI

Watchfire runs on your machine. Your CI keeps running against the merged branch — exactly as it did before Watchfire showed up.

Works

GitHub Actions

Watchfire merges the branch. Actions runs your tests on it as normal.

Watchfire is local-first — it doesn't run your tests in the cloud. When a Watchfire branch lands, GitHub Actions picks it up like any other commit and runs the workflows you already have. Watchfire's role stops at the merge; the CI run is your existing pipeline doing its job.

Works

Any CI provider

CircleCI, GitLab CI, Buildkite, Jenkins — Watchfire is local-first.

Whatever your CI runs against the merged branch on your remote will run when Watchfire lands a branch, too. There's no Watchfire-side runner, no hosted execution, no extra step in the pipeline — your CI keeps doing what it already did, just on commits that happen to have been written by an agent.

Shell

The CLI is a static Go binary. Any POSIX shell works — Watchfire does not care what prompt you use.

Works

bash / zsh / fish

A static Go binary — works in any POSIX shell you already have.

The watchfire CLI is a single Go binary. Tab completion ships for bash, zsh, and fish; everything else is plain executables and flags. If your shell can run a binary on $PATH, it can run Watchfire.

What “integration” actually means here.

Watchfire is local-first. It doesn’t replace your editor, your CI, or your secret manager — it stays out of their way.Works means Watchfire cooperates by being a well-behaved CLI; first-class means there’s explicit, tested support.

Don’t see yours?

The list above is what cooperates today. Open a thread in GitHub Discussions with the tool you’re missing and how you’d like it to fit — the categories that grow next are the ones people ask for.

Ready to go

Get started with Watchfire

Install in seconds. Define tasks. Let agents ship code for you.

Download for macOS

Available for macOS, Linux, and Windows

install

# Install via Homebrew (macOS)

$brew tap watchfire-io/tap

$brew install --cask watchfire-io/tap/watchfire

# Set up your project and go

$watchfire init

$watchfire task add "Build the login page"

$watchfire start --all

Includes GUI, CLI, and daemon. Also available via Homebrew.

View on GitHub Read the Docs

Watchfire integrateswith what you already use.

Agents

Claude Code

Codex

opencode

Gemini CLI

GitHub Copilot CLI

Cursor Agent

Version control

Git

GitHub

GitLab

Bitbucket

Forgejo / Gitea

Editors

VS Code

JetBrains IDEs

Neovim / Vim

Cursor (the editor)

Sandbox

macOS Seatbelt

Linux Landlock

Linux Bubblewrap

Secrets

OS keyring (macOS Keychain, libsecret)

1Password / Bitwarden / pass

.env files

CI

GitHub Actions

Any CI provider

Shell

bash / zsh / fish

What “integration” actually means here.

Don’t see yours?

Get started with Watchfire

Watchfire integrates
with what you already use.