Rowel

Drive the coding agent on your Mac from your iPhone. End to end encrypted; the relay only ever sees ciphertext.

The DeepSeek Harness (dsh) runs where your code and your keys already are. Rowel is the other half: read what the agent did, approve what it wants to do next, answer the question it is blocked on, start the next thing from a train.

 iPhone                  internet                   your Mac
┌────────┐          ┌──────────┐          ┌──────────────────┐
│ Rowel  │◄──wss───►│  Relay    │◄──wss───►│ Bridle ──► dsh  │
└────────┘  sealed  └──────────┘  sealed  └──────────────────┘
     └────────── Noise_IK_25519_ChaChaPoly_SHA256 ─────────┘

Bridle dials out. No port forwarding, no public IP, nothing to change on your router. When the phone and the Mac are on the same network the app talks to the Mac directly and the relay is not involved at all — both paths are raced and the local one wins.

There are no accounts. Pairing is a QR code in your terminal.

Where this is

The Mac side is finished and in daily use. The relay is deployed. The app is not on the App Store yet — getting it means building it with Xcode, which is free but comes with a seven-day catch.

Getting it running

1. Install Bridle on the Mac

curl -fsSL https://rowel.novabox.ai/install | sh

Needs Node 22+ and git. The script installs neither — it stops and tells you what is missing. It writes nothing outside ~/.rowel, plus one symlink onto your PATH. It is 134 lines, a third of them comments, if you would rather read it before running it.

2. Pair

bridle pair

A QR code appears in the terminal. Point the app at it. The first run of bridle does this for you, so this command is for adding a second phone.

Over SSH, where a terminal may not draw a QR code, add --link to print the raw pairing link. There is also an 8-character short code underneath, for when the camera is not an option — but read the note in SECURITY.md about that path first; it is currently the weaker of the two.

3. Keep it running

bridle service install

Starts after login and survives closing the terminal. bridle service uninstall takes it back off.

The bridle command

bridle                    start (and pair, on the first run)
bridle pair               a fresh pairing QR and short code
bridle status             machine, relay, harness, paired devices
bridle devices            list paired devices
bridle revoke <prefix>    remove one
bridle backup <file>      save this machine's identity, encrypted
bridle restore <file>     put a saved identity back
bridle service install    keep it running after login
bridle doctor             check this machine's setup

Useful flags on bridle itself:

--relay <url>       a different relay (default: the public one)
--dsh <url>         the harness, if it is not on a usual port
--advertise <url>   an extra address to put in the pairing code — a tunnel
                    hostname the machine cannot discover for itself. LAN and
                    Tailscale addresses are found automatically.
--direct-port <n>   fix the local-network port
--no-direct         do not listen on the local network at all
--no-auto-start     never launch the harness
--link              also print the raw pairing link

State lives in ~/.rowel/bridle.json, mode 0600, and it holds this machine's private key. ROWEL_HOME moves it.

Two harnesses on one Mac

One Bridle serves one dsh. Left to itself it probes the usual ports (3080–3083, 8080, 8791) and stays with whichever dsh answered last time — fine with one harness, a coin toss with two. --dsh ends the guessing:

bridle --dsh http://127.0.0.1:3081

If nothing answers there, Bridle starts a harness on that exact port — the startup line says (started by bridle) when it did. --no-auto-start makes it refuse instead.

Only one Bridle may run per identity; a second start stops and names the first. So to move your existing pairing to a different port, stop the running Bridle and start it again with --dsh. To serve a second harness alongside the first, give it an identity of its own:

ROWEL_HOME=~/.rowel-3081 bridle --dsh http://127.0.0.1:3081

Its first run prints its own QR code, and the app shows a second machine — same name, told apart by a fingerprint suffix. bridle pair needs none of this: it starts nothing, so it runs happily beside a Bridle that is already up.

What it is protecting, and what it is not

The relay switches sealed frames between two sockets by circuit number. It has no key material and cannot open them, which is a property of the shape rather than a promise about anyone's conduct — an end-to-end test taps the socket and fails if a method name, a machine name, or a session id ever appears on the wire. Both implementations of the tunnel use only their platform's own primitives, Node's node:crypto and Swift's CryptoKit. There is no third-party cryptography dependency in the tree.

The part people underestimate: dsh has no authentication of its own, so a paired phone has the same authority over that Mac as its own terminal — it can run commands and read and write files. bridle revoke is the only way to take that back. Nothing in the app is a smaller permission than that; the app just draws fewer buttons.

SECURITY.md is the full threat model, including what the relay does learn, what an unlocked phone means, and the known weaknesses. It is worth reading before you pair anything you care about.

Building from source

npm install
npm test               # build, docs check, unit tests. Seconds.
npm run test:e2e       # the whole stack (most of it needs a harness running)
npm run test:ios       # needs Xcode and `brew install xcodegen`
npm run vectors        # regenerate the cross-language test vectors

protocol/      Noise, frames, pairing, relay wire format (TypeScript)
bridle/        the companion process and its CLI
dsh-plugin/    the same core, mounted inside the harness instead of beside it
relay/         the Node relay
relay-worker/  the same relay on Cloudflare Workers and Durable Objects
e2e/           tests that span all three
ios/           the app (Swift, SwiftUI, XcodeGen)

How two implementations stay one protocol

The Noise handshake and the frame encoding are written twice, in TypeScript and in Swift. "My server talks to my client" proves nothing when both are mine, so npm run vectors runs the handshake with fixed keys and fixed ephemerals and writes a deterministic fixture; the Swift side compares byte for byte — handshake messages, the handshake hash, the confirmation number, transport ciphertext, the pairing link, frame encoding.

A failure there is a protocol fork, not a flaky test. It has already caught one: Foundation's JSONEncoder does not guarantee key order, which both ends were happy to parse and no amount of talking to myself would have found.

Running your own relay

bridle --relay wss://your.host is the whole client side. relay/ is a single Node process with no database and no configuration file; relay-worker/ is the same switchboard on Cloudflare Workers, which is what the public one runs on. docs/deployment.md has the DNS and TLS details.

Documentation

docs/ is in Chinese — it was written for the person maintaining this, and translating it is a bigger job than keeping it correct. English readers are not locked out of the parts that matter: SECURITY.md covers the threat model, CONTRIBUTING.md covers the build and the rules, and the code comments and commit messages are English throughout.

docs/README.md says which sections are specification-grade and which are design-grade. Ask before reimplementing from a design-grade one.

Licence

MIT. See LICENSE.