Paseo: a self-hosted daemon for driving Claude Code, Codex and friends from any device
Orchestrate multiple coding agents from desktop and mobile
At a glance
- What is it?
- Paseo puts a local daemon between you and five different coding agent CLIs, then exposes that daemon to a desktop app, a phone, a browser and a terminal. The design is coherent and the CLI is scriptable, but the licence is unclassified and plugins run with daemon-level trust.
- Who is it for?
- Adopt Paseo if you already have two or more agent CLIs installed, you want them running on hardware you control, and you are willing to read the plugin trust model before installing anything from a Git source. Do not adopt it if you need a clear OSI-approved licence today, or if your team cannot run a daemon on a machine with your credentials.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Paseo targets: five agent CLIs, five sets of habits
Most engineers who use coding agents seriously end up with more than one installed. The README names the set Paseo supports: Claude Code, Codex, GitHub Copilot, OpenCode and Pi. Each has its own invocation, its own session model and its own idea of where state lives. Switching between them means switching terminals, and checking on a long run means staying at the machine that started it. That is the gap Paseo aims at. It is not a new agent and it does not ship a model. It is an orchestration layer that sits above the CLIs you already have configured, and the README is explicit that you need at least one of them installed with your credentials before anything works. The audience is therefore narrow and specific: developers who already pay for or authenticate against one or more of those CLIs and want a single surface for launching, watching and continuing their work. If you use exactly one agent and never leave your desk, Paseo adds a daemon and a pairing step for very little return.
Daemon, clients, relay: how the pieces connect
The architecture is a hub and spokes. A local server called the daemon manages the coding agents. Clients connect to it: the Electron desktop app, the Expo app for iOS and Android, a web app, and the `paseo` CLI. The repository layout in the README confirms this split, listing `packages/server` as the daemon with agent process orchestration, a WebSocket API and an MCP server, `packages/app` as the Expo client, `packages/cli`, `packages/desktop`, and `packages/relay` for relay transport and encryption. There is also a TypeScript SDK, `@getpaseo/client`, which speaks to the daemon over a WebSocket URL such as `ws://127.0.0.1:6767/ws`. That WebSocket API is the real integration point. The SDK example creates an agent with a provider string like `codex/gpt-5.5` and a working directory, then awaits `agent.waitForFinish()` and reads `result.lastMessage`. Because the daemon is the single owner of agent processes, a run started from the desktop app is visible to the CLI and to the phone. That is the mechanism that makes cross-device handoff work without any cloud component in the default path.
Installing it: three routes with different trade-offs
The desktop route is the one the README recommends. You download from paseo.sh/download or the GitHub releases page, open the app, and the daemon starts automatically. Pairing a phone is done through Settings, then your host, then Pair Device. The headless route is `npm install -g @getpaseo/cli` followed by `paseo`. On first start, the CLI asks whether to enable the end-to-end encrypted relay for device pairing. Declining is a supported choice: the README says you can instead connect directly over TCP, Tailscale, or another VPN, which is the sensible path for a server or a remote machine that already sits on a private network. The Docker route runs the daemon and a self-hosted web UI in one container, publishing port 6767, taking `PASEO_PASSWORD`, and mounting two volumes: one for `/home/paseo` to persist state and credentials, and one for your source at `/workspace`. The README notes that you extend the base image with the agent CLIs you actually use and supply credentials through environment variables or the persistent volume. That last sentence is doing a lot of work. The image does not appear to bundle the agent CLIs, so the Docker path is a build step, not a single command.
The CLI is where Paseo stops being a GUI wrapper
The command surface is small and legible. `paseo run --provider claude/opus-4.6 "implement user authentication"` starts an agent. `paseo ls` lists running agents. `paseo attach abc123` streams live output from one. `paseo send abc123 "also add tests"` pushes a follow-up task into a session that is already going. The `--worktree` flag on `run` is the interesting one, shown as `paseo run --provider codex/gpt-5.5 --worktree feature-x "implement feature X"`, which suggests per-agent Git worktree isolation for parallel runs. The README does not document what that flag does mechanically, so treat the isolation claim as something to confirm in the CLI reference rather than something to assume. Remote execution is covered by `--host workstation.local:6767` combined with `--cwd`, and the README is careful to note that `--cwd` is a path on the remote host, not on your local machine. That distinction is exactly the kind of detail that trips people up when they first point the CLI at another box, and it is good that the documentation states it plainly.
Plugins extend the daemon, and that is the trust boundary
Plugins can add themes, workspace panels, commands, settings screens and coding-agent providers, written in TypeScript and installed with `paseo plugin add <source>` from a local directory or a Git repository. The README's own warning is unambiguous: plugins run with access to your daemon machine and inside connected clients, and you should install only code you trust. Read that as the security model rather than a disclaimer. A plugin is not sandboxed away from your credentials or your filesystem, because the daemon holds both. The plugin documentation is versioned, with a 0.8 beta quickstart pointed at from the README, which implies the plugin API is still moving. If you are evaluating Paseo for a team, the plugin surface is the part that most needs a policy decision before rollout, not the agent orchestration itself.
Where Paseo is the wrong tool
Three cases stand out. First, the licence. The repository metadata reports NOASSERTION, meaning GitHub could not classify it against a known licence. The README does not state licence terms either. For individual use that may not matter, but for a company with a licence review process it is a blocker until someone reads the actual terms in the repository. Second, the daemon model assumes a machine that stays reachable and holds your agent credentials. If your security posture forbids long-lived credentials on a shared host, the Docker deployment becomes an argument rather than a convenience. Third, the release cadence visible in the supplied material is fast: v0.8.0 on 2026-09-10, a beta two days earlier, v0.7.2 on 2026-09-02. A project shipping a minor version roughly every week is one where the plugin API and configuration keys can move under you. The README also does not describe how agent sessions survive a daemon restart, so if your work involves long-running tasks measured in hours, that is an open question rather than a documented guarantee.
How it differs from running the agent CLIs directly
The obvious alternative is not another orchestrator. It is the status quo: run Claude Code or Codex in a terminal, one at a time, on the machine where the code lives. That approach has no daemon, no pairing step, no relay decision and no plugin trust surface. It also has no cross-device visibility, no `paseo ls` to see what is in flight, and no `paseo send` to push a follow-up into a running session from your phone. The difference is not capability per agent; it is state ownership. Direct CLI use scatters session state across terminals and shells. Paseo centralises it in the daemon and then treats every client as a view onto that state. If you have never wanted to check on a build from a phone or hand a task between two different agents, the centralisation buys you nothing and costs you a background process plus an encrypted relay decision. The `/paseo-handoff` skill in the README, which the author describes as planning with Claude and handing off to Codex for implementation, is the clearest illustration of the workflow Paseo is built for. That workflow only exists if a shared layer knows about both agents.
Maintenance cost and what to check before committing
The upgrade surface is the daemon plus whichever clients you install. The desktop app bundles its own daemon start, so a desktop upgrade may move the server version underneath clients you did not upgrade. The Docker image is tagged `ghcr.io/getpaseo/paseo:latest` in the README example, which means a redeploy can change the daemon version without any explicit version pin; pinning a digest or a release tag is the safer pattern if you run it in production. The CLI installs globally from npm, so `npm install -g @getpaseo/cli` will pick up new releases on demand. Because the plugin API has a versioned 0.8 quickstart, plugins written against an older API are the most likely thing to break on upgrade. On licensing, the honest position is that NOASSERTION tells you nothing about your rights, and nothing in the supplied material resolves it. That is a question for whoever reads the repository's licence file, not a question this review can answer.
Editorial conclusion
Adopt Paseo if you already have two or more agent CLIs installed, you want them running on hardware you control, and you are willing to read the plugin trust model before installing anything from a Git source. Do not adopt it if you need a clear OSI-approved licence today, or if your team cannot run a daemon on a machine with your credentials. Verify three things first: the actual licence terms behind the NOASSERTION classifier, whether the end-to-end encrypted relay is acceptable for your network policy, and how the Docker image expects agent CLI credentials to be injected.
Community notes