Built for AI-to-human handoffs.

The last step of every agent task

Agent work ends in a file — a build, a report, a render, a dataset. Then comes the step that actually matters: getting that file to the person who asked for it, or to the machine where it's needed. scp wants a key and a reachable port. Cloud drives park your file on someone else's server. peeza makes delivery one command.

$ peeza link render-final.mp4
https://g.peeza.app/7XK4M2QD#k=…

$ peeza send build.zip --to <device>      # peeza devices lists yours

The minted link prints alone on stdout, so $(peeza link file) is the link — ready to paste into a chat, an email, a pull request.

01A link any human can open

peeza link mints a single-use, end-to-end-encrypted download link. The person on the other end needs no account and no app — any browser will do.

• One-time by design. The link is spent by the first fetch — once your recipient has the file, the URL left behind in a chat log is worthless.
• The relay does not receive the key (with one exception, when you ask for it). The decryption key rides in the link's # fragment, which browsers never send — the mechanics are on the tech page.
• No signup on either end of the handoff. The receiving human clicks; that's the whole onboarding.

02Your machines, without SSH

peeza send --to reaches the machines on your account wherever they are. No key on the far machine, no open port, no VPN, no shared network.

• Crosses NAT by itself. Direct peer-to-peer when possible; a blind relay carries ciphertext when it isn't.
• Offline is fine. A machine that's asleep or away receives the file when it returns.
• Same desk? peeza send --nearby moves files over the local network — no internet, no relay, no account.

03The transfer survives the agent

Transfers belong to a background engine, not to the process that started them.

An agent that exits — or a session that ends, or a laptop that reboots — doesn't kill the delivery. Transfer state is persisted before anything else happens, and an interrupted transfer resumes from the last byte written, not from zero.

04Made to be scripted

The command line was specified for machines from day one — an agent hits edge cases a human never does.

• Verbs block until the transfer is actionable and exit with documented codes (0–6), so a script never has to guess whether the send took.
• --json turns every answer into machine-readable output; peeza ls and peeza watch report live transfer state.
• An MCP server (peezad mcp) exposes the same operations to agent frameworks — wiring it in is a deliberate opt-in, never a default.
• The rest of the surface: peeza get '<link>' redeems a link — quote it, because the #k= fragment is the key and an unquoted # is a shell comment. peeza park packages a file and holds it with no network contact. peeza accept starts a held transfer. --against <path> on get or accept sends only the parts that changed from a file you already have. --wait complete returns when the bytes have arrived instead of when the transfer is actionable.

Every verb, flag and exit code, and the MCP server's tools, are in the command-line reference — the binary's own peeza help, published as is.

05The same security, whoever's driving

A transfer started by an agent is encrypted exactly like one started by a person: end to end, on every path, always.

Files stream directly between devices; when a relay has to step in, it forwards only ciphertext it cannot read and stores nothing — within the limits our published protocol lists, including one exception, when you ask for it. The full mechanics — keys, pairing, what the relay keeps — are on the tech page and in the privacy policy.

06Install

The command line installs with the desktop app, from a terminal or from the app itself. On a Mac that already has peeza, turn it on in Settings › General › Command line.

macOS 14 or later, with Homebrew

brew install ercwilcom/tap/peeza

Puts peeza in Applications and the peeza command on your PATH. The app updates itself, so brew upgrade leaves it alone.

Ubuntu 22.04, Debian 12 or later

sudo wget -qO /usr/share/keyrings/peeza-archive-keyring.gpg https://apt.peeza.app/peeza-archive-keyring.gpg
sudo wget -qO /etc/apt/sources.list.d/peeza.sources https://apt.peeza.app/peeza.sources
sudo apt update && sudo apt install peeza

Adds peeza's signed apt repository — the same one the .deb adds — so updates arrive with the rest of your system's.

Windows 10 (2004) or later

No package manager: the app's own installer (peeza.app/download) puts the peeza command on your PATH.

All downloads, checksums and the Flatpak are on peeza.app/download.

07Before the first verb

What has to be true before a command works — so an agent can check instead of guess.

• An engine must be running. The desktop app runs it. On a Mac the command line starts it for you through the app's launchd job. On Linux and Windows it starts nothing: open the app once, or run the engine yourself — on a .deb install, /usr/lib/peeza-app/peezad --port 7411; the exit-3 message names the path on any install. With no engine to reach, every verb exits 3 and says why; peeza health asks without a token.
• No account for links, parking or nearby. peeza link, peeza park, peeza get and send --nearby work signed out.
• Your machines and teams need an approved account. send --to, send --team and peeza devices need peeza connect on an account that has been approved — accounts are a closed beta, approved by hand. peeza whoami says which state this machine is in.
• Sizes. A direct transfer has no size limit. A link that has to go through the relay carries up to 250 MB per transfer without an account, and the account's relay allowance with one — the figures are on the relay page.
• The engine outlives the agent, not the machine. A transfer survives the process that started it because the engine owns it. A container or sandbox that exits takes its engine with it, so run the engine where the files should keep moving.