How AI Coding Agents Deliver Files to Developers

When an agent runs on your own laptop, delivery is trivial: it writes ./dist/report.pdf and you open it. Most of the interesting setups are not like that. Cloud coding agents run in short-lived VMs or containers; chat assistants execute code in a hosted interpreter; remote development environments sit in a datacenter; CI-driven agents run in a runner that is destroyed when the job ends. In each case the agent can produce a build, a dataset, a log bundle or a generated report, then tell you a path that means nothing on your machine.

These environments also share a network shape: outbound connections allowed, inbound blocked. You cannot scp into a sandbox that has no SSH server and no public address, and the agent cannot push to your laptop for the same reason in reverse. The one channel that always exists is the conversation, which carries text.

Why pasting the file into chat fails

The obvious workaround is to have the agent print the file, base64-encoded if it is binary. Base64 represents every 3 bytes as 4 characters (RFC 4648), so the text is a third larger than the file, and every character passes through the model as output tokens. A few hundred kilobytes already crowds the context window that the agent needs for actual work. Worse, the model reproduces the string token by token: a single dropped or altered character produces a file that fails to decode or silently differs, and long outputs are often truncated. It is acceptable for a short config snippet, and the wrong tool for anything you would call a file.

Five approaches cover nearly every setup. They differ mainly in what credentials the agent needs, whether a copy persists somewhere, and whether the agent's environment must stay alive until you download.

Object storage is the right call when the file must survive the sandbox or be fetched repeatedly over days: a stored copy is exactly what you want there. The cost is putting long-lived credentials somewhere an agent, and anything that can steer it through prompt injection, can use them, plus remembering to delete the object. The CI artifact store is the same idea with credentials already managed by the platform; the CI/CD artifact sharing guide compares those options in detail.

The trick is to invert the connection. Instead of the developer connecting to the sandbox, a process inside the sandbox opens an outbound WebSocket to a relay on port 443, the same kind of connection an environment needs to reach a package registry. It registers a random token and prints a URL. When someone opens that URL, the relay asks the sandbox process for the bytes over the connection that already exists and forwards them to the HTTP response as they arrive. Nothing is uploaded ahead of time and nothing is written to the relay's disk.

SRIFT's quick-share is an implementation of this. Its CLI normally hands the work to a background daemon on 127.0.0.1:3822, which keeps serving after the command exits. Sandboxes often forbid exactly that (no detached processes, no local listening ports), so when the daemon cannot start, the CLI and MCP server run it inside their own process instead. This embedded mode needs nothing but outbound HTTPS/WSS on 443; the process stays up until the download finishes, and --wait makes the command block until then, which is what you want when the sandbox is torn down as soon as the agent stops.

• Encryption: --encrypt seals the file with AES-256-GCM in 1 MiB chunks under a random key carried after #k= in the link. Browsers never send the fragment to the server (RFC 3986, section 3.5), so the relay sees ciphertext and the generic name encrypted.srift. Decryption happens in the browser page or in srift get; plain curl would save the ciphertext.
• Limits: --once allows one download, --max-downloads N caps downloads, --ttl 15m (also 30s, 2h, 1d) sets an expiry. With no flags a link has no expiry and lives as long as the sender serves it.
• Folders: a directory becomes a .tar.gz (.git and node_modules are always excluded), and several paths become one bundle link.

From an MCP-capable agent

Agents that speak the Model Context Protocol can call a delivery tool instead of composing a shell command. SRIFT's local MCP server (srift mcp, 15 tools) exposes srift_quick_share; the agent passes an absolute path and gets a URL back to show you:

srift_quick_share {
  "filePath": "/workspace/dist/app.zip",
  "encrypt": true,
  "maxDownloads": 1,
  "ttlMs": 3600000
}
-> {
  "downloadUrl": "https://srift.app/d/<token>#k=<key>",
  "fileName": "app.zip",
  "encrypted": true,
  "expiresAt": 1791460800000,
  "maxDownloads": 1
}

Setup differs per client; the guides for sending files from Claude Desktop and Claude Code and for Cursor agents show the configuration. One caveat: the hosted endpoint at https://srift.app/mcp has no filesystem access and offers only the 9 session and control tools, so a chat assistant that can only attach remote MCP servers cannot deliver files through it. Delivery needs the local server running where the file is.

From any agent with a shell

srift quick-share ./dist/app.zip --encrypt --once --ttl 2h --wait
# prints https://srift.app/d/<token>#k=<key> and blocks until downloaded

# no install, e.g. in a throwaway container:
npx -y srift-transfer quick-share ./dist/app.zip --encrypt --wait

srift get "https://srift.app/d/<token>#k=<key>"
# or open the link in a browser; unencrypted links also work with
# curl -fLOJ "<url>"  or  wget --content-disposition "<url>"

Quote the URL in shells: # starts a comment in many of them, which would drop the key. If the sandbox blocks something unexpected, srift doctor probes DNS, HTTPS, WebSocket, local ports and process spawning and reports whether links will be served from a background daemon, embedded, or not at all.

The same constraints apply when you need to give the agent something: a database dump to analyse, a design file, a log from production. You cannot upload into the sandbox, but the sandbox can open a room on a relay and invite you into it.

srift session start --name "inbox"
# Access Link: https://srift.app/join-session?id=ABC1234
srift session status          # lists pending join requests
srift approve <temp-user-id>  # let the developer in
srift list                    # the developer's file offer appears with its file ID
srift receive <file-id> --save-dir ./incoming

The developer opens the access link in a browser, presses Request to Join, and once approved drags the file in. Over MCP the steps map to srift_start_session (returns the join URL), srift_session_status, srift_approve_join, srift_list_transfers and srift_accept_transfer with a saveDir. Joining always requires the host's approval, so a leaked session code alone does not let a stranger push files. Unlike quick-share, the CLI session commands need the background daemon, so they do not work in sandboxes that forbid detached processes.

Chunks that pass through the relay are sealed with AES-256-GCM under a per-transfer key the two sides agree with ECDH. Those public keys are exchanged through the SRIFT server without a verification step, so this protects against passive observers and an honest server, not against an operator who actively substitutes keys. Between two CLI or agent peers, --room-secret mixes a secret the server never sees into the keys.

• Links are bearer secrets. Anyone who has the full URL can download, and with --encrypt the URL also contains the key. Chat transcripts are stored and sometimes shared, so pair links with --once or a short --ttl.
• Without --encrypt, it is TLS only. The relay handles the real file name and the plaintext bytes in transit. The CLI warns about this; prefer encryption for anything you would not post publicly.
• Metadata remains. Even for encrypted links the relay sees IP addresses, timing and the ciphertext size.

A streamed link depends on the sandbox staying up. If the platform kills the environment the moment the agent replies, and you will not download for an hour, the link will be dead when you click it; that is the case for object storage or a CI artifact. The same goes for files many people will fetch over weeks, for audit requirements that need a retained copy, and for outputs that belong in version control, where a commit is the honest answer. Streamed links are for the common middle case: one person, now, from an environment that can only dial out.