Installation

macOS

Homebrew (recommended)

Install Workbench as a cask from the r26d tap:

brew install --cask r26d/tap/workbench

Updates arrive via brew upgrade --cask workbench.

Manual download

Download the .dmg for Apple Silicon (aarch64) from the Downloads page, open it, and drag Workbench to your Applications folder.

Linux

APT repository (Debian/Ubuntu)

Add the r26d package repository for automatic updates:

# Import the signing key
curl -fsSL https://updates.r26d.dev/apt/r26d-archive-keyring.gpg \
  | sudo tee /usr/share/keyrings/r26d-archive-keyring.gpg > /dev/null

# Add the repository
echo "deb [signed-by=/usr/share/keyrings/r26d-archive-keyring.gpg] https://updates.r26d.dev/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/r26d.list

# Install
sudo apt update && sudo apt install workbench

After this, sudo apt upgrade will pick up new Workbench releases automatically.

Manual download

Download the package for your preferred format from the Downloads page:

.deb: sudo apt install ./Workbench_*.deb
.rpm: sudo dnf install ./Workbench_*.rpm
.AppImage: chmod +x Workbench_*.AppImage && ./Workbench_*.AppImage

Prerequisites

Before using Workbench, ensure you have Claude Code installed and authenticated:

# Install Claude Code if you haven't already
# See: https://docs.anthropic.com/en/claude-code

# Authenticate with your Anthropic account
claude /login

macOS permission prompts

After install, macOS may surface a few first-run permission prompts. Each is gated by Apple’s TCC (Transparency, Consent, and Control) system and fires the first time Workbench exercises the underlying capability. Two of them — Local Network and Notifications — fire at or shortly after first launch, because the capabilities they gate (mDNS discovery, the notification subsystem) are initialized during app startup. The rest are deferred until you actually use the feature that needs them.

”Workbench wants permission to update or delete other applications.”

This is macOS’s App Management prompt (Ventura 13+). It appears the first time Workbench installs its own update — the signed Tauri updater fetches a new build from the update feed, verifies the minisign signature against the public key embedded in the app, and replaces the Workbench.app bundle in /Applications. macOS sees one app modifying another app bundle on disk and requires you to grant the permission once.

Grant it to enable in-app auto-updates. The permission is scoped to Workbench — it does not let Workbench touch any other application.
Deny it and you’ll need to update manually by downloading the latest .dmg from the Downloads page and replacing the bundle in /Applications yourself.
The choice can be changed at any time in System Settings → Privacy & Security → App Management → Workbench.

If you installed Workbench outside /Applications (e.g. ran it directly from ~/Downloads), the prompt may not appear until the first time the updater tries to swap the bundle.

”Workbench would like to find and connect to devices on your local network.”

This is macOS’s Local Network prompt (Sonoma 14+). It appears shortly after first launch because Workbench runs an mDNS browser that discovers other Workbench instances on your LAN to populate the Nearby section of the sidebar (used by remote workspaces). The browser is read-only — Workbench doesn’t advertise itself unless you run the standalone workbench-server binary.

Grant it to see nearby Workbench servers in the sidebar and use remote workspaces over the LAN.
Deny it and the app keeps working — the Nearby list just stays empty. Direct connections to a server by IP/hostname still work, since those don’t need mDNS.
Toggle later in System Settings → Privacy & Security → Local Network → Workbench.

”Workbench would like to send you notifications.”

The standard macOS notification prompt. It fires at first launch so the app can post native banners later for events like agent finished a turn, agent is asking a question, and plan needs review. See Notifications for the per-event toggles inside the app.

Grant it for OS-level banners and click-to-navigate (clicking a banner focuses the relevant workspace and chat).
Deny it and in-app indicators (sidebar badges, tray tooltip, optional custom sound) still work — only the native banners are suppressed.
Toggle later in System Settings → Notifications → Workbench.

”Workbench wants to use the microphone” / “speech recognition”

These fire the first time you click the chat composer’s mic button. See Voice Input → Apple Speech for the full setup.

”Workbench wants to control Terminal” (or “iTerm”)

This is macOS’s Automation prompt. It fires the first time you launch a TUI editor or open a workspace path in an external Terminal.app or iTerm2 window — Workbench sends an Apple Event to ask the terminal app to open a new window cd’d into the worktree. Denying it disables that one launch target but doesn’t affect anything else.

All of these can be reviewed or changed later in System Settings → Privacy & Security.

Linux: native file dialogs

Workbench’s Browse buttons (Add Repo, attach files, settings) call into Tauri’s dialog plugin, which on Linux routes through org.freedesktop.portal.FileChooser. The portal needs a running daemon and a backend implementing the FileChooser interface — full desktop environments (GNOME, KDE) pull these in transitively, but minimal installs (i3, sway with no DE) usually do not.

# Debian/Ubuntu — install the portal matching your DE:
sudo apt install xdg-desktop-portal xdg-desktop-portal-gtk    # GTK-based (XFCE, MATE, Cinnamon)
sudo apt install xdg-desktop-portal xdg-desktop-portal-gnome  # GNOME
sudo apt install xdg-desktop-portal xdg-desktop-portal-kde    # KDE Plasma

When no portal is detected, Workbench silently hides the Browse buttons and shows a context-appropriate hint — paths in Add Repo / Settings can be pasted into the text input; chat attachments can be drag-and-dropped into the composer. The app stays functional but loses native file pickers. Capability is probed once at startup; install the portal stack and restart Workbench to recover the buttons.