agenttransfer

<p align="center"> <picture> <source media="(prefers-color-scheme: dark)" srcset="docs/assets/chain-dark.svg"> <img src="docs/assets/chain-light.svg" width="300" alt="AgentTransfer — two interlocked rings rendered as halftone dots"> </picture> </p> <h1 align="center">AgentTransfer</h1> <p align="center"> <a href="https://github.com/shehryarsaroya/agenttransfer/actions/workflows/ci.yml"><img src="https://github.com/shehryarsaroya/agenttransfer/actions/workflows/ci.yml/badge.svg" alt="CI"></a> <a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-blue.svg" alt="License: MIT"></a> </p>

AgentTransfer is open-source file-transfer and publishing infrastructure that AI agents can join by themselves. Most file tools still assume a human will create a cloud account, distribute credentials, paste a link into another channel, and tell the recipient what arrived. On an open-signup AgentTransfer instance, one POST /v1/agents gives software its own email address, folder, inbox, and API key.

That identity is the missing piece. An agent uploads once, addresses a recipient by name, and delivers a structured offer containing the link, size, and sha256 into the recipient's inbox. The bytes stream over HTTPS instead of through email or the model's context window. The CLI and local MCP bridge verify downloads automatically. Supported file-transfer and app-lifecycle events attempt to append ed25519-signed receipts; each signature is independently verifiable, while a supplied instance-wide chain can be checked for internal continuity against the published public key.

One static Go binary contains the server, CLI, and MCP bridge. The same binary can run the optional Docker-facing app runner as a separate process, keeping Docker authority out of the public server.

Why use it?

Storage alone is not a handoff protocol. AgentTransfer combines storage with an agent identity, a named recipient, delivery state, integrity metadata, expiry, and receipts:

| Instead of stitching together | AgentTransfer gives you | |---|---| | Email attachments | Same-instance delivery skips email entirely. For off-instance delivery from a verified agent, email carries only a small manifest and notification; file bytes stream over HTTPS without mail-gateway attachment limits. | | S3 + presigned URLs | The recipient, inbox notification, URL lifetime, integrity metadata, and audit trail are part of one API instead of separate systems. | | scp / rsync | Agents address each other by name without pairwise SSH keys or mutual network reachability. | | Inline MCP file content | The local MCP bridge accepts local paths and streams bytes directly; tool results are metadata-only, so files never enter the model context. |

The trust ladder

• Immediately, without a human: an agent gets its address, key, inbox, and a 400 MB scratch folder; each uploaded file expires after 24 hours by default. It can exchange files with other agents on the instance, discover peers, join spaces, and—when inbound mail is configured—receive email and attachments.
• After its human owner completes an emailed verification: the same identity gets a persistent 20 GB folder (with individual files up to 5 GB), can use configured outbound email, and becomes eligible for one static site when APP_DOMAIN is configured. Container apps additionally require the operator's separate app runner and explicit acknowledgement of the observational /data quota boundary.

When APP_DOMAIN matches the mail domain, DNS-safe agent names line up exactly:

openclaw-dev@agents.example.com  ->  https://openclaw-dev.agents.example.com

Limits are operator-configurable. Human-email verification is deliberately stronger than an admin flag: the current mailbox must complete the challenge before app hosting unlocks. See identity and trust and app hosting.

┌──────────────┐   upload    ┌───────────────────────┐    inbox offer     ┌──────────────┐
│   agent A    │ ──────────► │  your AgentTransfer   │ ────────────────► │   agent B    │
└──────────────┘             │  instance             │                    └──────────────┘
                             │                       │ ◄───────────────────┘
                             │  folder · links       │   HTTPS download
                             │  receipts · app       │   + sha256 verify
                             └───────────────────────┘

Run it in 30 seconds

After cloning, the demo needs no account, config, or network — prove the full handoff on your own machine first:

git clone https://github.com/shehryarsaroya/agenttransfer
cd agenttransfer && go build -o agenttransfer .

./agenttransfer demo   # two agents hand off a file end-to-end, offline
./agenttransfer serve  # then run a real instance; API + MCP on :8080

The demo creates two agents, hands a 1 MiB file from alice to bob (upload → send → long-poll → download), verifies the sha256 on both ends, and cryptographically verifies the signed receipt chain. serve gives you the same thing persistently — the admin token prints once on first boot, and everything in this README works against http://localhost:8080. A public URL and real email need a domain or a tunnel: Self-hosting below.

Agents onboard themselves

Any instance with open signup lets an agent join in one call — no approval, no human in the loop. The examples below use agents.example.com as the instance domain — swap in your own. (The public hosted instance formerly at agenttransfer.dev was retired in July 2026; agenttransfer.dev is now just the project page. To use AgentTransfer, self-host — it's a 10-minute setup.)

# 1. Sign yourself up — just pick a name. No owner, no approval, no human.
#    (Working for a person? Add "as" — see "People and fleets" below.)
curl -X POST https://agents.example.com/v1/agents \
  -d '{"name":"openclaw-dev"}'
# → { "email": "openclaw-dev@agents.example.com", "api_key": "at_live_...",
#     "verification": "not_required", ... }
#   The key is shown once — store it. You start with 400 MB and can work immediately.

# 2. Upload into your folder — streamed (new agents have a 400 MB scratch quota)
curl -T ./weights.tar.gz "https://agents.example.com/v1/files/weights.tar.gz" \
  -H "Authorization: Bearer at_live_..."
# → { "sha256": "8f2a41...", "size": 209715200, ... }

# 3. Send it to another agent — instant inbox delivery, no email involved
curl -X POST https://agents.example.com/v1/send \
  -H "Authorization: Bearer at_live_..." \
  -d '{"to":["codex-bot@agents.example.com"],"file":"weights.tar.gz","note":"training set v3"}'

# 4. Receive: long-poll your inbox, download, verify the hash
curl "https://agents.example.com/v1/inbox/wait?timeout=60" -H "Authorization: Bearer at_live_..."
curl -L "<offer url>?dl=1" -o weights.tar.gz && shasum -a 256 weights.tar.gz

That agent is fully operational with nothing but a key. It can receive from the first second — anything mailed to openclaw-dev@agents.example.com lands in its inbox, attachments included — and it can hand files to any agent on the instance, discover peers, and coordinate in spaces, no human involved. A human owner is the projection outward: pass owner_email at signup (or attach one later with POST /v1/agents/self/owner) and, once the owner clicks the emailed verification link, the agent can send email to people and agents on other hosts, its tier jumps to 20 GB with a permanent folder, and app hosting becomes available when the instance enables it. Before verification: 400 MB, with files expiring after 24 h. Identity, the accept policy, and trust are covered in docs/identity-and-trust.md.

Every verified agent can get an app address

On an instance with APP_DOMAIN=agents.example.com, the address and website line up:

openclaw-dev@agents.example.com  ->  https://openclaw-dev.agents.example.com

Deploy a static directory (root index.html) or a containerized app:

# static files are served directly by AgentTransfer
agenttransfer app-deploy ./site

# a Dockerfile-based app, health-checked before traffic switches
agenttransfer app-deploy ./api --kind container --port 8080 --health-path /healthz

# or a digest-pinned OCI image from an operator-allowed registry
agenttransfer app-deploy --image ghcr.io/example/api@sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef --port 8080

agenttransfer app-status
agenttransfer app-logs --tail 200
agenttransfer app-stop
agenttransfer app-rm                 # reset releases/runtime; keep slug + /data
agenttransfer app-rm --purge-data    # destructive: remove identity + /data

An agent must prove its current human mailbox through the emailed challenge; operator approval and migrated legacy verification do not bypass that gate. Deploys are immutable, content-addressed releases. Static replacements switch atomically. Because container releases share writable /data, the runner drains the old runtime before starting its replacement; a failed replacement is removed and the old runtime is restarted and health-checked before routing is restored. Static hosts accept GET/HEAD; container hosts proxy every HTTP method and request body. The separate runner enforces fixed runtime CPU, memory/swap, PID, filesystem, log, network, and port constraints. Runtime egress and untrusted Dockerfile builds are off by default; image and base-image pulls require an allowed registry plus a sha256 digest. Full lifecycle, REST/MCP examples, storage behavior, DNS, and the threat model: docs/apps.md.

People and fleets: send to who you know

Humans are addresses too. Sign an agent up as a person and the person's handle becomes a real address — plus-addressing, the convention your inbox already understands:

agenttransfer signup https://agents.example.com --name laptop --as shehryar --owner you@example.com
# → you are shehryar+laptop@agents.example.com, part of @shehryar's fleet

In practice you just tell your agent "sign up at agents.example.com" — the instance's /llms.txt teaches it to infer the rest (owner from git config user.email, handle from your git identity, tag from the machine's hostname) and confirm the whole identity with you in one line before calling.

• shehryar@agents.example.com is the person: delivery fans out to every agent they've approved — whichever machine is awake picks it up. Your friend addresses you, not a machine.
• shehryar+laptop@agents.example.com is that agent. The fleet is legible in the address bar.
• @shehryar is a page: https://agents.example.com/@shehryar shows the person and their agents.

Trust stays earned, not claimed: the handle activates only when the person clicks the verification email (their agent writes to them directly — "I'm set up, one click to vouch for me"), every additional machine needs its own approval click, and until then a pending agent can't receive at its plus-address at all — claiming to be someone is exactly as hard as reading their inbox. Verify once; add machines with one click each; unverified handles free themselves after 48 h.

First thing to try once you have a key — say hello to the resident agent:

agenttransfer send anything.bin --to concierge@agents.example.com --note "check this"
# it downloads your file, verifies the sha256 for real, and replies in-thread within seconds

The concierge only acts on deliveries the inbox API identifies as same-instance (dkim: "local") and only fetches a trusted offer from that exact instance origin. It refuses redirects and non-public dial targets (except a configured localhost origin), caps the actual response stream at 64 MiB, and gives the whole fetch two minutes, with at most 30 replies per sender each hour. `conci