Berry Wiki

Paseo

Properties2
tagsai, tooling
aliasesPaseo

7 min read

Paseo

Summary

Paseo is an open-source control center for running coding agents on your own computers and controlling them from desktop, web, mobile, or command line. It supports parallel sessions, worktrees, diffs, terminals, browser previews, pull-request workflows, schedules, and agent-to-agent orchestration.

  • Repository: getpaseo/paseo
  • License: AGPL-3.0
  • Latest release: v0.1.107
  • Checked: 2026-07-14

Problem

Developers often run several agent command-line tools across multiple projects and machines. Paseo gives them one interface and lets work continue on an always-on desktop, server, VM, or container while they monitor it from another device.

How It Works

  • Local daemon: A server process runs where the agents and source code live.
  • Native agent tools: Paseo starts each provider’s own command-line tool as a subprocess. Existing subscriptions, skills, configuration, and MCP servers remain in use.
  • Remote clients: Mobile, desktop, web, and command-line clients communicate with the daemon over WebSocket.
  • Agent workspace: Agents can run in a normal directory or an optional Git worktree on a separate branch.
  • Workflow UI: Paseo shows chat, terminals, files, diffs, previews, commits, pull requests, and merge actions.
  • Orchestration: Skills and commands can hand work between providers, run loops, request advice, or form multi-agent committees.

Security Boundary

Paseo is an orchestrator, not an agent sandbox. Its own FAQ says it does not modify or wrap agent behavior. An agent runs with the permissions of the daemon’s user and the native provider tool.

Paseo’s security boundary protects remote control of the daemon:

  • Hosted relay: Traffic is end-to-end encrypted after Curve25519 key exchange using XSalsa20-Poly1305 authenticated encryption.
  • Pairing: The QR code or pairing link carries the daemon public key and must be treated like a password.
  • Direct mode: The daemon listens on localhost by default. A Unix socket can restrict access to local processes.
  • Network exposure: Password authentication and host-header checks protect a daemon intentionally bound to a network address.

These controls do not prevent an agent from reading or changing files its operating-system user can access. Use a VM or container around Paseo when agent containment is required.

Platforms And Agents

  • Desktop: macOS on Apple silicon or Intel, Windows x64 or ARM64, and Linux AppImage, DEB, or RPM.
  • Mobile: iOS and Android.
  • Other clients: Browser and command-line interface.
  • First-class agents: Claude Code, Codex, GitHub Copilot, OpenCode, Cursor, and Pi.
  • Additional providers: The site claims more than 34 additional integrations and supports custom providers.
  • Headless hosts: Laptop, Mac Mini, Linux server, VM, VPS, or Docker container.

Setup And Self-Hosting

Simplest desktop path: install the desktop app, ensure at least one supported agent tool is already authenticated, then scan its QR code from a mobile client.

Headless self-hosting:

npm install -g @getpaseo/cli
paseo

Other official paths:

  • Nix: Run from the GitHub flake.
  • Docker: The official image combines the daemon and web UI. Mount a scoped workspace and persistent home directory, add agent tools, and supply provider credentials.
  • Remote access: Use the end-to-end encrypted hosted relay, a direct private-network connection such as Tailscale, or a user-managed tunnel.
  • Relay self-hosting: The project links a separate Go project, paseo-relay, as a community self-hosted relay.

For Docker, the official docs require a password before exposing port 6767, HTTPS for remote browser use, allowed hostnames, tightly scoped workspace mounts, and careful protection of /home/paseo.

Network And Credentials

  • Provider credentials: Managed by each native agent tool. Paseo says it does not store or transmit provider API keys.
  • Execution context: Native agents use the existing credentials available to the daemon user.
  • Relay privacy: The hosted relay can observe IP addresses, timing, sizes, and session IDs, but the project says it cannot read or alter message contents undetected.
  • Direct connection: Password authentication controls access but does not encrypt traffic. Use an encrypted relay, VPN, or HTTPS reverse proxy on untrusted networks.
  • Default direct access: Anyone who can reach the daemon may connect unless a password is configured; localhost is the default binding.
  • Docker secrets: The persistent home may contain provider credentials and daemon state.
  • Voice: Speech runs locally by default; OpenAI speech services are optional and require separate credentials.

Strengths

  • Broad control surface: Desktop, mobile, web, and CLI have access to the same running agents.
  • Self-hosted execution: Code and agents remain on infrastructure the user controls.
  • Provider choice: One interface works with several native agent tools without replacing their configurations.
  • Always-on workflows: A spare computer or server can keep working while a laptop sleeps.
  • Worktree support: Parallel agents can work on separate branches without changing the main checkout.
  • Mature feature set: Review, preview, commit, PR, merge, schedules, voice, and multi-agent workflows are integrated.
  • Remote encryption: The recommended relay avoids open inbound ports and encrypts client-to-daemon traffic.

Limits

  • No agent isolation: Paseo does not restrict the agent’s filesystem, commands, or outbound network.
  • Powerful daemon: Anyone who controls it can run agents and commands in its user context.
  • Exposure risk: Binding to all interfaces without password and encryption can expose the development environment.
  • Credential reach: Agents inherit the native tools’ credentials and whatever their host user can access.
  • Docker mount risk: Containers can access all mounted code and credential paths; container use is not automatically safe.
  • Solo maintenance: The README identifies one maintainer and directs urgent issues to Discord.
  • Early version number: Despite high activity, the current release remains 0.1.x.
  • Hosted-relay claims: No independent cryptographic audit was found in the checked official materials.

Activity And Maturity

Checked 2026-07-14:

  • Created: 2025-10-13.
  • Latest release: v0.1.107, published 2026-07-12.
  • Latest checked commit: 1f5283f5a369, dated 2026-07-14.
  • History: About 4,333 commits and 143 visible releases.
  • Interest: 10,386 stars and 1,006 forks.
  • Assessment: Fast-moving and widely noticed, with a large feature surface. Still pre-1.0 and dependent on a solo maintainer.

Best Fit

Best for a developer who wants to run several native coding agents on an always-on machine and control them from a phone, browser, or other computer.

For safer autonomy, run the Paseo daemon and agents inside a dedicated VM with only the required repositories and credentials. Paseo alone is not the containment layer.

Comparison

  • Versus Clawk: Paseo focuses on cross-device orchestration and many providers. Clawk focuses on disposable VM isolation and restricted agent networking.
  • Versus cloud agent services: Paseo keeps execution on user-controlled hardware and reuses existing subscriptions, but the user operates the host and remote access.
  • Versus direct terminal use: It adds mobile access, session overview, worktrees, previews, review, and multi-agent coordination.
  • Versus a self-hosted web terminal: It understands agent sessions and development workflows, but carries similarly serious remote-control risk if exposed incorrectly.

HN Context

Paseo appeared in a reply to a developer who preferred a remote Linux VM so agents could continue after a laptop slept and wanted an exe.dev-like system for a spare Mac Mini. The commenter said Paseo supports self-hosting but had only used it lightly.

That is an accurate fit: Paseo can run headless on the Mac Mini or another server and be controlled from a tablet or phone. It provides the remote orchestration layer, not the disposable VM or network sandbox discussed elsewhere in the thread.

Unknowns

  • Independent audit: No third-party review of relay cryptography or daemon exposure controls was found.
  • Provider count: The exact list behind “34 more” changes and was not fully enumerated here.
  • Multi-user controls: Fine-grained roles and permissions for teams were not established by the checked docs.
  • Self-hosted relay support: A community relay exists, but parity, maintenance, and deployment guarantees were not established.

Sources

Graph View