An agent writes a report, tells you the file path, and hours later the download button does nothing. The output was living on the computer that made it, and that computer was designed to disappear. Why this failure is structural rather than a bug, and what to do at the moment the work is finished.
An agent spends twenty minutes on a report, tells you the file is ready and where it lives, and you go and read what it wrote. A few hours later you come back for the file and the download does nothing at all. No error worth the name, no deleted-file message. Just a button that has stopped meaning anything.
You will meet one of three versions of this, and they look different enough that people rarely connect them.
The first is the dead download. The agent produced something, you have a link or a button, and at some point it silently stops working. The second is the vanishing path: the agent tells you the output is at /tmp/report/index.html or /workspace/out/summary.md, which is a perfectly good path on a computer you cannot reach and will never see again. The third is the most confusing, because it does not look like a failure at all — you ask for the file again and you get one, and it is subtly not the same file.
All three have the same cause, and it is not a bug in any of these products.
Agent platforms give a run its own machine. Depending on the product it is a container, a microVM, or a sandboxed process, but the shape is the same: an isolated environment with its own filesystem that gets created when the work starts and destroyed when the work is over. This is a good design and the reason these tools can run arbitrary code on your behalf without it being reckless.
The consequence is that the agent's working directory is not storage. It behaves like storage for as long as the run is alive, which is exactly long enough to convince you otherwise. Every file the agent creates, including the one you actually wanted, lives in a filesystem whose expected lifetime is measured in minutes.
The timer is what makes it feel arbitrary. Most platforms reclaim on idleness rather than on a fixed clock, because a sandbox nobody is talking to is a sandbox nobody needs. That policy is sensible and it produces a nasty interaction with how people actually work: you finish the run, you stop typing, you go and read the twelve paragraphs the agent just wrote — and the idle timer starts counting during precisely the period when you are paying the most attention to the output and the least to the machine.
So the file does not disappear while you are ignoring it. It disappears while you are reading it.
The natural recovery is to go back to the conversation and ask for the file. Sometimes you get one. That is the worst outcome available.
An agent that no longer has the file does not usually say so. It re-runs the work. The prompt is the same, the tooling is the same, and the result is close enough that nothing announces the difference — but the numbers in the table came from a fresh pass, the phrasing moved, a section might be structured differently. If nobody has seen the first version this costs you nothing. If you already sent it to someone, you now have two documents with the same filename in the world and no way to tell which one they are looking at.
This is the same class of problem as two agents editing the same document: the failure is not that the work is wrong, it is that there is no longer a single answer to "which one is the real one".
There is a second failure stacked on top of this one, and it is worth naming separately because it survives even after you have solved the storage problem.
A long agent run produces a lot of files. Scratch data, intermediate JSON, a log, three drafts, and somewhere in there the thing you asked for. Ask an interface to hand you "the output" and it has a surprisingly hard problem: there is often no structured record of which file was the deliverable, so it falls back on scraping a filename out of the agent's own prose. That reliably gives you whatever the agent mentioned most recently, which is frequently a diagnostic file rather than the report.
The practical version of this: say what the deliverable is, out loud, while the run is still open. Not because the agent needs telling, but because you do. The moment you name it is the moment it becomes a thing you can move.
The fix is not a product, it is a step — and it belongs at the moment the work finishes, not at the moment you discover it is gone.
Work out whether the output stands alone. This is the step people skip and it decides everything after it. Open the file outside the agent's environment and see what happens. A page that loads its own styles from a local path, calls a service on localhost, or reads a key out of the environment is not portable yet. Finding that out yourself takes a minute; finding it out from the person you sent it to costs considerably more. If you built it with a coding agent, getting a genuinely self-contained file out is usually a matter of asking for one explicitly — most of them will inline assets on request, but few will do it unprompted.
Then give it an address. Which address depends on what the thing is, and the split is cleaner than it first looks:
| What the output is | Where it goes | Why |
|---|---|---|
| Data you will process further | Object storage | It needs to be fetchable, not viewable |
| A page a person will open | A static host | It needs to render for someone who has none of your tooling |
| Something with a login or a database | Vercel or Netlify | It is an application; it needs a platform that runs code |
| Scratch work | Nowhere | Let it die with the sandbox — that is what the sandbox is for |
That third row is worth taking seriously rather than treating as a fallback. If the output needs server-side anything, a static-link host will waste your afternoon, and the honest answer is that this is not the tool for it.
Send the address rather than the file. Agent output gets revised. That is the whole point of working this way. An attachment freezes at the moment you sent it, so every revision becomes a new email and a new file in someone's downloads folder with -v2 appended. A URL that can be updated in place means the version you revised is the version they open, without anyone having to think about it.
Not a tool. A habit, and it is one step long: when a run finishes, before you go and read the result, decide whether anything in that sandbox needs to outlive it.
Most of the time nothing does, and you close the tab with a clear conscience. When something does, moving it takes under a minute and the whole failure mode described here never happens to you again. The reason it keeps happening is not that the step is hard — it is that the moment it belongs in feels like the moment the work is finished, so it does not feel like a moment that requires anything.
The machine is designed to disappear. That is not the flaw. The flaw is assuming that anything on it was ever being kept.
You sent a Claude Slides deck with 'anyone with the link' and your client got a sign-up screen. Why that happens, what Docs, Slides and Design actually export, and how to get the work in front of someone who will never make a Claude account.
You sent a client the public link to a Claude Code artifact and asked them to mark up what to change. There's nowhere to comment. That's by design. Here's the rule, which plans it leaves without a comment option for outside viewers, and how to collect pinned notes anyway. Checked against Anthropic's docs on 15 September 2026.
Hit a ChatGPT Sites usage limit? Your Sites aren't gone. Here's how to tell the ones that are just pages, which travel, from the ones that need Sites underneath them.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.