# Remote Pi: controlling a local Pi coding agent from your phone > Remote Pi pairs a Flutter mobile client with a Rust relay and a Node extension so you can keep a Pi coding agent running on your own machine and talk to it from a phone. The pairing model is neat; the trust boundary is the part worth reading before you install it. **jacobaraujo7/remote_pi** — 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. - Repository: https://github.com/jacobaraujo7/remote_pi - Website: https://remote-pi.jacobmoura.work - Stars: 411 · Forks: 107 - Language: Dart - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/jacobaraujo7-remote-pi ## The gap Remote Pi fills between a desktop agent and a phone A coding agent that runs locally has an obvious advantage: your source code and your model calls stay on hardware you own. It has an equally obvious disadvantage. The agent lives in a terminal session on a desktop, so the moment you leave that desk, you lose the ability to answer its questions. Long-running work stalls on a clarification prompt nobody is there to read. Remote Pi targets exactly that gap. The README describes it as a way to control your Pi coding agent from your phone, pairing with a one-time QR code and chatting with your local agent even when you are away from your computer. The audience is narrow and specific: people who already run the Pi coding agent, keep it on a machine they control, and want a mobile view of it rather than a hosted alternative. It is not a general remote desktop, and it is not a way to run an agent in someone else's cloud. ## How the relay, extension and mobile app fit together The repository splits into four packages, and the split tells you most of the design. `app/` is a Flutter client for iOS and Android. `pi-extension/` is Node plus TypeScript and exposes a `/remote-pi` command inside Pi. `relay/` is Rust with Tokio, handling WebSocket routing and signed mesh membership storage. `site/` is a NextJS landing and legal site. The data path in the README runs the mobile app over `wss` to the relay, and the relay over `wss` to the Pi extension, which sits next to the local Pi process. Below that, a Unix Domain Socket broker handles the local mesh, letting other agents on the same machine talk to each other. When several Pi agents run on one machine, one wins a leader election and binds the socket while the others connect as clients; agents address same-machine targets through opaque addresses returned by `list_peers`, with no relay and no network involved. Three tools are exposed to the model in the Pi chat: `list_peers`, `agent_send` and `agent_request`. The README is unusually precise about `agent_send` acknowledgement values: compatible ACK values are `received`, `busy`, `denied` and `timeout`, but current brokers return only `received`, `denied` or `timeout`, and `busy` means a message was dropped by an old broker leader that must be restarted before resending. Broadcast returns `sent` with no ACK. That level of detail about a failure mode is rare in a README and it is a good sign about how the protocol is documented. ## Installing the Pi extension and pairing a phone The extension installs through Pi's own package manager, so you need Pi present in the project where the agent runs. The README gives this single command: ```bash pi install npm:remote-pi ``` After installation, the setup wizard is invoked from the Pi chat rather than the shell: ``` /remote-pi ``` The wizard asks for an agent name, a session name and a relay choice, then prints a QR code. Scanning that code with the Remote Pi mobile app completes pairing. Peers are persisted in Keychain on mobile and under `~/.pi/remote/` on the desktop, which is where you would look if a paired device stops being recognised. The README also names an optional companion package, `@eko24ive/pi-ask`, installed the same way: ```bash pi install npm:@eko24ive/pi-ask ``` With it, 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 let the flow resolve on the desktop. Without it, the agent asks in plain chat text. Remote Pi works either way, but if answering prompts from a phone is your main reason for installing, pi-ask is what makes that experience structured rather than improvised. ## The trust boundary is the part to read twice Remote Pi is candid about its security model, and the candour is the most useful thing in the README. TLS protects traffic in transit, but current payloads are not end-to-end encrypted, and the README points to `relay/README.md` for the exact trust boundary. The free community relay at `wss://relay-rp1.jacobmoura.work` is described as enough to get started, with the warning that the relay operator can see the content of your messages and is a single point of trust for routing. For sensitive work the README recommends running your own relay, described as a single Docker command. The authentication story has a similar shape. Ed25519 is used in the Relay handshake to prove possession of the connection key, and App-to-Pi pairing is enforced by the endpoints. For Pi-to-Pi routing, the README states that the current Relay permits a route when a correctly signed Owner blob lists both Pi keys, and then says plainly that this check does not prove the Owner paired with or controls either Pi. That is a real limitation stated by the project itself, not an inference. If your threat model includes a hostile participant on the same relay, the mesh routing check is weaker than the name suggests. ## Where Remote Pi is the wrong tool The project labels its own status as a functional MVP, with planning notes and a roadmap in `plan/`. Treat that as a boundary rather than a disclaimer. If you need a hardened remote access product with audited end-to-end encryption, the README tells you this is not it yet, and the relay operator visibility is a property of the current design rather than a misconfiguration. There is a second, quieter constraint. The extension runs inside Pi, so Remote Pi is useless without the Pi coding agent, and the mobile client is a client for that agent rather than a general terminal. Anyone looking for a way to reach an arbitrary shell on a Raspberry Pi from a phone is in the wrong repository, despite what the project's name suggests. The local mesh also assumes multiple Pi agents on one machine; a single-agent setup gets the phone pairing and nothing from the mesh tools. ## Compared with a plain SSH session to the same machine The obvious alternative is SSH from a phone client into the machine running the agent. The difference is in what each one exposes. An SSH session gives you the whole machine: you attach to the agent's terminal, you can also edit files, restart services, or do anything else the account allows. Remote Pi gives you the agent surface instead, with structured prompts through pi-ask, a peer list, and a pairing model built around a phone rather than a keyboard. You lose shell access and gain a narrower, purpose-built UI. The trade is real in both directions. SSH keeps your traffic between your phone and your own host with no third party in the path, which is a meaningful advantage given that Remote Pi payloads are not end-to-end encrypted. Remote Pi answers a question SSH answers badly: how do I respond to an agent's clarification prompt in two taps while standing in a queue. If you are already comfortable in a mobile SSH client, the case for Remote Pi rests almost entirely on that structured prompt flow and on the mesh tools. ## Licensing, release cadence and what upgrading costs The repository carries an MIT licence at the top level, but the README is explicit that licensing is per-package and that each subproject has its own `LICENSE` file, with `pi-extension` being MIT and a repository-wide decision still pending. That matters if you plan to redistribute or bundle a component. Check the `LICENSE` inside the specific package you are shipping, and treat the top-level file as a starting point rather than the answer. Nothing here is legal advice; the point is that the licensing question is not settled at the repository level. On maintenance, the last push was on 2026-09-10, and releases are frequent and small: `cockpit-v1.28.25` on 2026-09-09, `cockpit-v1.28.24` on 2026-09-07 and `cockpit-v1.28.23` on 2026-08-29. The patch numbering suggests a steady stream of incremental fixes rather than infrequent large drops. For upgrade cost, the practical exposure is version skew between the extension and the relay: the README describes ACK behaviour that differs between current and old broker leaders, and a stale leader must be restarted before a `busy` message can be resent. If you self-host, plan to keep the relay image current alongside the extension rather than pinning one and forgetting the other. ## Conclusion Adopt Remote Pi if you already run the Pi coding agent on a machine you control and want to check on it or answer its prompts from a phone, and if you are willing to run your own relay for anything sensitive. Do not adopt it if you need end-to-end encrypted payloads today, since the README states current payloads are not E2E and the relay operator can read message content. Before pairing anything real, read relay/README.md for the exact trust boundary, confirm which subproject LICENSE applies to the component you are installing, and decide whether the community relay at wss://relay-rp1.jacobmoura.work is acceptable for your traffic or whether you will start your own. ## FAQ ### What is Remote Pi and what does it do? Remote Pi is a set of packages for controlling a local Pi coding agent from a phone. The README describes pairing through a one-time QR code so you can chat with the agent running on your own machine while away from your computer. ### How do I install Remote Pi? You install the Pi extension with `pi install npm:remote-pi`, then run `/remote-pi` in the Pi chat. The setup wizard collects an agent name, a session name and a relay choice, then prints the QR code you scan with the mobile app. ### Are Remote Pi messages end-to-end encrypted? No. The README states that TLS protects traffic in transit but current payloads are not E2E, and it points to relay/README.md for the exact trust boundary. It also warns that the operator of the community relay can see message content. ### Can I run my own Remote Pi relay instead of the community one? Yes. The README recommends running your own relay for sensitive work and describes it as a single Docker command, with the self-hosting guide in relay/README.md. The free community relay at wss://relay-rp1.jacobmoura.work is offered as a way to get started. ### Does Remote Pi work without the @eko24ive/pi-ask package? Yes. The README says Remote Pi works either way, but without pi-ask the agent asks its clarification questions in plain chat text rather than as structured prompts with options, multi-select and previews rendered in the mobile app. ## Sources - [jacobaraujo7/remote_pi on GitHub](https://github.com/jacobaraujo7/remote_pi) - [License: MIT](https://github.com/jacobaraujo7/remote_pi/blob/main/LICENSE) - [Project website](https://remote-pi.jacobmoura.work) - [README](https://github.com/jacobaraujo7/remote_pi/blob/main/README.md) - [Releases](https://github.com/jacobaraujo7/remote_pi/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jacobaraujo7-remote-pi