Remote Pi: pairing a phone with a local Pi coding agent over a relay
Control your Pi coding agent from your phone. Pair with a one-time QR code and chat with your local agent, even when you're away from your computer.
At a glance
- What is it?
- Remote Pi is a Flutter client, a Node Pi extension and a Rust relay that together let you drive a local Pi agent from a phone. The README is candid about the trust boundary, and that candour is the most useful thing in it.
- Who is it for?
- Adopt Remote Pi if you already run Pi locally and want to answer its prompts from a phone without exposing the machine, and if you are willing to run the relay yourself for anything sensitive, since the README states the community relay operator can read message content. Skip it if you need end-to-end encryption today, because payloads are not E2E, or if you want a repository-wide licence answer before shipping, because the README says that decision is pending.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Dart, 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 gap Remote Pi fills: a Pi agent you can reach from a phone
A Pi coding agent runs on your machine and holds your files, your shell and your credentials. That is the point of it. It is also why you cannot casually reach it from a phone: there is no public endpoint to call, and putting one there means exposing the machine. Remote Pi's answer is a pairing flow rather than a login. The README describes a one-time QR code, short-lived, scanned by the Flutter app, with peers persisted in Keychain on mobile and under ~/.pi/remote/ on desktop. Nothing in that description requires you to open a port or publish a hostname. The intended user is someone who already runs Pi locally and wants to keep a session moving while away from the desk, not someone looking for a hosted coding agent. The repository is split into app/ (Flutter), pi-extension/ (Node and TypeScript), relay/ (Rust and Tokio) and site/ (NextJS), so the mobile client, the agent-side integration and the routing service are separable pieces rather than one monolith.
Two channels: a WebSocket relay and a local Unix socket mesh
The architecture diagram in the README shows the Flutter app connecting over wss to the Rust relay, and the Pi extension connecting to the same relay over wss. Behind the extension sits the local Pi process, and behind that a Unix Domain Socket broker that other agents on the same machine can join. Those are two different transports with different properties, and the README treats them separately. Remote traffic goes through the relay. Traffic between Pi agents on one machine does not: when several agents run on the same host, the extension manages a UDS broker, one agent wins a leader election and binds the socket while the others connect as clients, and agents address each other using the opaque addresses returned by list_peers. The README states plainly that same-machine targets use no relay, no network and no extra config. That split is the design decision worth noticing. The remote path is the one with a trust question attached; the local path is the one that costs nothing to run.
The three tools the agent actually sees
The extension does not just forward chat. It exposes three LLM-facing tools inside the Pi chat, and their semantics are specific enough to matter when you build a workflow. list_peers returns the local and cross-PC addresses available to the agent. agent_send sends a unicast message and waits for a delivery ACK; the README lists received, busy, denied and timeout as the compatible ACK values, then narrows it: current brokers return received, denied or timeout, and busy only indicates a dropped message from an old broker leader that must be restarted before resending. Broadcast returns sent with no ACK, and asynchronous content replies come back through re. agent_request is request/response with a timeout and is described as available only as deprecated legacy behavior. That last point is the one to plan around. New work should be built on agent_send plus re, not on agent_request, because the README marks the latter as legacy. A backend agent asking a frontend agent for help on the same machine is the example the README gives, and it runs in parallel with the mobile pairing rather than instead of it.
Getting it running: two commands and a wizard
Installation is deliberately short. In any project where Pi runs, the README gives pi install npm:remote-pi, then /remote-pi inside the Pi chat. The setup wizard collects an agent name, a session name and a relay choice, then prints a QR code for the mobile app to scan. The optional companion is @eko24ive/pi-ask, installed with pi install npm:@eko24ive/pi-ask, which makes the agent's ask_user clarification prompts (structured questions with options, multi-select and previews) render natively in the mobile app so you can answer from the phone and have the flow resolve on the desktop. Without it the agent asks in plain chat text, still answerable from the phone but unstructured. The README is explicit that Remote Pi works either way. The default relay is wss://relay-rp1.jacobmoura.work, described as a free community relay that is enough to get started. Binaries come from Google Play, the App Store, or a sideloaded APK from GitHub Releases.
The trust boundary the README does not hide
This is where the project is more honest than most, and also where its main limitation sits. The README states that TLS protects traffic in transit but current payloads are not end-to-end encrypted, and points to relay/README.md for the exact boundary. It then says the community relay operator can see the content of your messages and is a single point of trust for routing, and recommends running your own relay for sensitive work, describing that as a single Docker command. The authentication story has a similar edge. Ed25519 authentication means the Relay handshake proves possession of the connection key, and App to Pi pairing is enforced by the endpoints. For Pi to Pi routing, the README says the current Relay permits a route when a correctly signed Owner blob lists both Pi keys, and then adds the qualification that this check does not prove the Owner paired with or controls either Pi. Read that twice. The signature establishes that a key signed a blob naming two Pi keys; it does not establish that the named Pis consented. For a same-machine mesh behind a UDS broker that may be acceptable. For cross-PC routing through a relay you do not operate, it is the thing to reason about before trusting the channel with anything.
Where the release cadence and packaging leave questions
The most recent releases are cockpit-v1.28.25, cockpit-v1.28.24 and cockpit-v1.28.23, dated 2026-09-09, 2026-09-07 and 2026-08-29. The gaps are uneven: two days, then nine. The tag prefix cockpit- does not obviously map to the four packages listed in the README, and the material does not say which subproject those releases belong to, so treat the cadence as a signal that the project is active rather than as a versioning scheme you can plan upgrades against. The status section says the MVP is functional and that planning notes and roadmap live in plan/. Licensing is per-package, with pi-extension under MIT and a repository-wide decision still pending. That matters if you intend to redistribute or bundle anything beyond the extension: the licence of the relay and the app is not settled by the material provided, and the MIT label on the repository as a whole should not be assumed to cover every directory. Check each subproject's LICENSE file rather than the top-level metadata.
What Remote Pi is not, and what to compare it against
Remote Pi is not a way to run a coding agent in the cloud, and it is not a general remote-shell tool. It assumes Pi is already installed and running on a machine you control, and it adds a control surface for that process. The nearest alternative in approach is a self-hosted tunnel or reverse proxy in front of a locally exposed agent endpoint: something like a WireGuard or Tailscale interface plus a small HTTP service, or an SSH port forward with a terminal client on the phone. Those give you a raw connection to the machine and leave the agent interaction entirely to you. Remote Pi goes the other way. It ships a purpose-built mobile client, a structured pairing flow, a relay that routes between named peers, and a set of agent-level tools (list_peers, agent_send, agent_request) so one Pi can address another. The trade is explicit: you get a tailored chat and mesh experience, and you accept a relay in the path plus a Node extension inside your Pi process. If your requirement is simply to reach a shell, the tunnel is less machinery. If your requirement is to answer an agent's clarifying question from a phone and keep the session on the desktop, Remote Pi is doing work the tunnel does not.
Who should adopt it, and what to check before you commit
The case for adopting is narrow and clear. You run Pi locally, you want phone access to a live session, and you are prepared to run the relay yourself rather than depend on the community instance for anything sensitive. The README makes that last part easy to act on: it describes self-hosting as a single Docker command, with the trade-offs documented in relay/README.md. The case against is equally clear. If you need end-to-end encryption of message payloads today, this is the wrong tool, because the README says payloads are not E2E. If you need a settled repository-wide licence before you ship or redistribute, the README says that decision is pending. If you are building on agent_request, note that it is marked deprecated legacy behavior and plan the migration to agent_send with re. Before installing, read relay/README.md for the exact trust boundary, decide whether the community relay at wss://relay-rp1.jacobmoura.work is acceptable for your content, and confirm which subproject the cockpit-* release tags belong to so your upgrade expectations match reality.
Editorial conclusion
Adopt Remote Pi if you already run Pi locally and want to answer its prompts from a phone without exposing the machine, and if you are willing to run the relay yourself for anything sensitive, since the README states the community relay operator can read message content. Skip it if you need end-to-end encryption today, because payloads are not E2E, or if you want a repository-wide licence answer before shipping, because the README says that decision is pending. Verify two things first: the current relay trust boundary in relay/README.md, and whether your Pi agent's clarification prompts need @eko24ive/pi-ask for structured rendering.
Community notes