How should a coding agent hand off finished files to a person?
As like Claude Code and Codex become capable of finishing entire tasks on their own, one awkward step remains: actually delivering the finished result to a person. An agent might produce a , a PDF report, a build artifact, a dataset, or an exported design file, and getting that file to someone usually means choosing among a few options: committing it into a even when it doesn't belong there, granting the agent broad access to or Dropbox, uploading it manually after the agent finishes, or building out an S3 bucket with signed URLs and expiration jobs from scratch. The approach that worked best was giving the agent one narrowly scoped file-delivery tool.
It takes a local file path plus optional delivery settings and returns a browser link that expires after a set time. For example, an instruction like "deliver ./dist/client-build.zip to mark@acme.com for seven days and protect it with a password" is enough to trigger it. The key benefit isn't the upload mechanism itself but the tight limits placed on the agent: it can only upload files explicitly chosen for delivery, links expire automatically, storage are never exposed in the share URL, and passwords or recipient restrictions can be applied.
The agent gets back structured information about the file, its size, its expiry, and the resulting URL.
Key points
- can now finish tasks end-to-end, but delivering the output file to a human remains an awkward last step
- Common workarounds: committing artifacts to a repo, granting broad Drive/Dropbox access, manual upload, or hand-building S3 plus signed URLs
- Alternative: give the agent one narrowly scoped file-delivery tool instead
- That tool only uploads explicitly selected files, auto-expires links, never exposes storage in the share URL, and supports passwords and recipient limits
- The agent receives : file info, size, expiry, and the resulting URL