Confirmed by the last run: a working file's download_url is
chatgpt.com/backend-api/estuary/content?cid&id&p&sig&ts&v — the same route
the browser uses. So /files/{id}/download is the minting endpoint, and a
gizmo file's 403 is a refusal to mint the signature. That is why no amount
of scoping helped; we were turned away at the only door that issues them.
Nothing else in the estuary namespace serves files: 404 across the board.
But section B tested file_000000001b3071f5…, one of the seven DELETED
files, because it took the first failure without checking its class. Those
results say nothing about the eleven recoverable ones.
- Pick the target by probing /files/{id} and taking one that answers 200,
skipping (and naming) the deleted ones.
- Add two experiments: estuary/content with a ts but no sig, since
validation asked only for id/p/ts and never sig; and a working file's
freshly minted URL with the refused id swapped in, which shows whether
the signature is bound to the file.
A URL copied from the browser gave us the route we never tried:
/backend-api/estuary/content?id=…&ts=496382&p=fs&cid=1&sig=…&v=0
Fetched with no cookies it returns 403 {"detail":"File stream access
denied."}, so the signature rides on the session rather than replacing it.
Every earlier probe lived under /backend-api/files/*; estuary/* is new
ground.
estuary_probe.py checks two things:
A. What /files/{id}/download hands back for a file that works. If its
download_url is an estuary URL, that endpoint is the minting step, and a
gizmo file's 403 is a refusal to mint — which is why no amount of
scoping helped.
B. Whether the estuary namespace exposes a route that serves a refused
file directly.
It also replays a pasted URL through the exporter's session, and says
plainly whether the id in that URL is one of the refused files — the two
captured so far were working images, so they showed the shape without
telling us whether the broken ones have a URL at all.
JesseMarkowitz