wsp
Run coding agents as threads on your own Mac and ssh-attached Linux boxes, with per-branch worktrees and your setup already there.
- Source repo
- wsp-labs/wsp
- Stars
- ★ 14
- Last updated
- today
- License
- AGPL-3.0
- Primary language
- TypeScript
- FA score
- 39/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A developer already using Claude Code or Codex in a terminal who wants many parallel tasks and multi-branch work in one sidebar.
- Not a fit if
- Teams working only on Windows, or needing Windows machines in the pool
- Teams unwilling to run a local host and manage ssh/root access on their boxes
- Individuals who want a turnkey tool without maintaining remote dev machines
- Source review
- 39/100 · Major gaps
What does this agent do, and when should you use it?
wsp is a local-first desktop app plus CLI that runs coding agents — Claude Code, Codex, OpenCode, Cursor — as threads on computers you own: the Mac in front of you and any Linux box you add over ssh. A thread works inside a project folder the way the agent would in a terminal there; when it needs another branch, wsp creates a git worktree and carries your .env files and installed dependencies across. Per thread you pick the agent, model, reasoning effort and how far it may go without asking, and you answer its questions and permission prompts inside the app. Threads can start child threads on the same or a different agent, and each child's last reply returns to its parent, all visible in one sidebar. The same verbs are exposed over MCP, so other agents can open and reply to threads programmatically. Alongside a thread you get a terminal, its dev server in a browser tab, its changes with commit/push/PR, files, processes, machine load, and the slate — a live panel the agent builds for that thread. A usage page breaks down plan limits and consumption by agent account, project and computer.
wsp keeps a three-level model of computers, projects and threads inside a host process that runs on your Mac. wsp add <folder> registers a local folder as a project; wsp add root@my-box adds a Linux computer over ssh and provisions it. wsp run <project> "<message>" starts an agent thread in that project's folder, and wsp run api --branch fix/flaky makes a git worktree on that branch with .env files and dependencies carried in. While a thread runs you use wsp send for its next message, wsp stop to end the turn, wsp thread read to print what it said, and wsp delete to remove it while keeping the folder. wsp mcp install --agent claude (or codex, gemini, opencode) registers the same verbs as MCP tools, so an agent can open threads, start child threads on another agent beside it, read their replies and message them. In the app, each thread carries a terminal in its folder, its dev server in a browser tab, its changes with commit, push and pull request, its files, its processes, the computer's load, and the slate it builds live. The host and your sign-ins stay on your computers rather than on a vendor cloud.
- A developer already using Claude Code or Codex in a terminal who wants many parallel tasks and multi-branch work in one sidebar.
- Someone with a Mac and spare Linux machines who wants agent threads spread across them without reinstalling toolchains and logins by hand.
- Teams that want agent-to-agent work: one thread telling another agent to review a pull request, write tests or make a frontend change.
- Engineers who want to drive wsp from their own agent pipeline through MCP, creating and reading threads programmatically.
- Tech leads tracking plan limits and consumption per agent account, project and computer.
How do you install or deploy this agent?
On macOS or x64 Linux, run the install script; downloads come from this repo's releases and are checked against the sha256 GitHub publishes:
curl -fsSL https://usewsp.com/install | shOn a Mac this puts wsp.app in Applications and opens it; on Linux it puts the AppImage in ~/Applications. The wsp command lands in ~/.wsp/bin, on PATH in a new terminal. To pin a release:
WSP_VERSION=1.2.3 curl -fsSL https://usewsp.com/install | shWith Node 22 or newer, this installs the command line alone:
npm i -g @wsp-labs/wspThe macOS bundle is not signed yet, so the first open is blocked; dismiss it and choose Open Anyway under Privacy & Security, or run:
xattr -dr com.apple.quarantine /Applications/wsp.appStart the Linux AppImage from a terminal in its download folder:
chmod +x wsp-*.AppImage && ./wsp-*.AppImageHow do you use this agent?
Open the app: it finds the agents on your Mac and serves projects from there. Add a project (any folder, git repo or not) and start a thread from the composer. The same from a terminal:
wsp add ~/code/api
wsp run api "fix the flaky terminal test"
wsp run api --branch fix/flaky "write the failing test first"
wsp threads
wsp send <thread> "next message"
wsp stop <thread>
wsp thread read <thread>Add a Linux box (ssh reachable as root, with systemd and cgroup v2):
wsp add root@my-box
wsp computers
wsp computers set <computer>
wsp remove <computer>Give your agent the wsp tools, then restart it:
wsp mcp install --agent claudeAfter that you can tell the agent: "use wsp to start a Codex thread on api that reviews the open pull request". wsp status reports whether a host serves and where; wsp down stops it.
What are this agent's strengths and limitations?
- Local-first: the host runs on your Mac, not a vendor service, and sign-ins stay on the computers that use them.
- The CLI verbs and the MCP tools are the same set, so agents can open and message threads, including cross-agent child threads, on their own.
- Fine-grained control per thread: agent, model, reasoning effort and how far it may go without asking, with prompts answered in the app.
- Automatic git worktrees per branch that carry .env files and installed dependencies, so parallel branches need no manual environment copying.
- A thread's terminal, dev server, changes with PR flow, files, processes and machine load sit beside it, cutting tool switching.
- Existing Linux machines join over ssh, and wsp deploys your agents, CLI tools, skills, MCP servers, plugins, sign-ins and projects onto them.
- Supports macOS and x64 Linux only; the README names no Windows or arm Linux host support.
- Adding a box requires root ssh plus systemd and cgroup v2, which rules out many locked-down or container-only environments.
- The macOS bundle is unsigned, so the first open needs a Gatekeeper workaround; the Linux AppImage does not start on a double click in Ubuntu's desktop.
- 0.3 renamed core verbs (e.g.
thread_newtorun,wsp placestowsp computers), so existing scripts and MCP tool names must migrate. - You must already have and be signed in to Claude Code, Codex, OpenCode or Cursor, and their model usage is billed by those subscriptions or APIs.
- Aimed at individuals and small self-managed setups; the docs show no multi-tenant team controls, centralized permissions or audit.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| wsp This agent | 39 · Major gaps | Desktop appFree + model costs | ★ 14 | today | TypeScript | Codex · Claude Code |
| Pi Agent Desktop | 52 · Major gaps | — | ★ 321 | 12d ago | TypeScript | OpenAI API |
| Yardlet | 49 · Major gaps | Desktop appFree | ★ 31 | today | Swift | Codex · Claude Code |
| Harness Remote | 69 · Some gaps | Desktop app | ★ 434 | 1d ago | JavaScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
README asserts keys and sign-ins stay on the user's machines and the host runs locally, but this is assertion, not verifiable evidence; install is curl | sh from a remote endpoint, and the README explicitly requires adding Linux boxes over ssh as root with self-installation, a large privilege surface with no least-privilege design described; threads can spawn child threads and be configured to act without asking, with confirmation only mentioned in prose; SECURITY.md gives reporting channels and scope but no data-flow, key-storage, or dependency-audit detail. All scored 1 for documentation presence only, deducted for absent code-level evidence.
The CI workflow is elaborate (sharded tests, flake reruns, type checks, Mac gate), showing engineering discipline, but that describes the repo's own build, not the Agent product's runtime reliability; README and SECURITY.md are in tension over a 'machine provider key' versus 'host runs on your Mac' without reconciling them; failure messages and recovery paths are barely documented. Scored 1.
Audience and scenarios are clear (run Claude Code, Codex, etc. on your own Mac/Linux), scored 2; but capability boundaries (what agents may do, sandboxing) are undefined, trigger precision (when a host auto-starts, when it asks) is unstated, and environment fit covers only macOS and Linux x64, not Windows or non-root ssh, each scored 1.
README information architecture is good, install notes include checksum verification, version pinning, and unsigned-bundle workarounds, examples and a command table are thorough, and the license is full AGPL-3.0 matching package.json, each scored 2; however the 0.3 release performed a large-scale rename, weakening naming stability; there is no CHANGELOG file, only an inline rename table; known limitations are scattered and incomplete; maintenance responsibility points only to GitHub issues and an unverified publisher, each scored 1.
The product positioning is clear and command examples are directly actionable, giving some output usability, but no actual run artifacts or end-to-end example outputs appear in the repo; the marginal value over running agents in a terminal (worktrees, multi-machine, MCP) is plausible but unevidenced; cost-benefit involves root privileges and a remote install script whose risk is unquantified. All scored 1.
Most README claims (keys never leave, sha256-verified installs, CI-gated landings) have partial in-repo counterparts (CI workflow, SECURITY.md), but key security claims lack code support; cross-source corroboration is limited to README and SECURITY.md echoing each other; fact and inference are mixed in the docs (e.g. 'your keys stay on your computers' is an assertion). Each scored 1.
- Install runs curl | sh from a remote endpoint, and the README requires adding Linux boxes over ssh as root with self-installation; the privilege surface is significant, so audit the install script in an isolated environment first.
- The claim that keys stay local is in tension with SECURITY.md's statement that wsp talks to a machine provider with your key; actual key flow is not described in the repo.
- Threads can spawn child threads and be configured to act without asking; user-confirmation and rollback mechanisms lack code-level evidence.
- Publisher identity is unverified by the FollowAgents registry; maintenance responsibility and update path point only to GitHub issues, so assess supply-chain risk yourself.
- The 0.3 release renamed many commands and MCP tools, which may break existing scripts and automation.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v0.3.9 wsp 0.3.9
Release notes excerpt
What changed since v0.3.8 wsp now calls Boat at boat.dev/api/v1. Boat set 31 October 2026 as the sunset of the address older versions call, ascii.dev/api/box/v1, so if you use Boat, update wsp before then. Renamed in 0.3 A thread runs in your project's folder on one of your computers, and wsp --help names computers, projects and threads. A verb takes a project or a thread right after it. Nothing answers to the old lines, so here they are, once. | was | is | | --- | --- | | wsp thread new --in <workspace> "<task>" | wsp run <project> "<message>" | …View on GitHub ↗ -
v0.3.8 wsp 0.3.8
Release notes excerpt
What changed since v0.3.7 wsp now calls Boat at boat.dev/api/v1. Boat set 31 October 2026 as the sunset of the address older versions call, ascii.dev/api/box/v1, so if you use Boat, update wsp before then. Renamed in 0.3 A thread runs in your project's folder on one of your computers, and wsp --help names computers, projects and threads. A verb takes a project or a thread right after it. Nothing answers to the old lines, so here they are, once. | was | is | | --- | --- | | wsp thread new --in <workspace> "<task>" | wsp run <project> "<message>" | …View on GitHub ↗ -
v0.3.7 wsp 0.3.7
Release notes excerpt
What changed since v0.3.6 Renamed in 0.3 A thread runs in your project's folder on one of your computers, and wsp --help names computers, projects and threads. A verb takes a project or a thread right after it. Nothing answers to the old lines, so here they are, once. | was | is | | --- | --- | | wsp thread new --in <workspace> "<task>" | wsp run <project> "<message>" | | the MCP tool thread_new | the MCP tool run | | wsp threads --in <workspace> | wsp threads <project> | …View on GitHub ↗
FAQ
Does wsp itself cost anything?
Does my code or do my keys leave my machines?
What does a Linux box need to join?
What breaks when upgrading from the pre-0.3 naming?
wsp thread new --in becomes wsp run, the MCP tool thread_new becomes run, wsp places becomes wsp computers, and wsp pair becomes wsp host pair. Old lines no longer answer, so scripts must be updated; agents on the machine get the new skill the first time the new host starts.Can one agent really dispatch another?
wsp mcp install --agent claude (or codex, gemini, opencode) and an agent restart, the agent gains the same verbs as MCP tools: it can start threads, start a child on another agent beside it in the same folder, read the child's replies and send it messages, with children shown in the sidebar.