What we can see.

A tool call carries its arguments and nothing else. For a publish that is a slug and a file list — paths, sizes, hashes, and for publish_inline the file contents themselves, because the server has to hash and upload them.

What surrounds the call in your chat never reaches us. We could not produce your conversation if we were asked for it, because we were never sent it.

Publishing declares the whole site up front: every path, its exact size, its content type and its SHA-256. That list becomes the version’s manifest, and it is immutable afterwards.

Each file then gets a short-lived signed grant naming one version, one path, one byte count and one hash. The edge recomputes the hash as it writes and refuses anything that disagrees. Nothing can be added mid-upload, swapped for different bytes under the same name, or written outside its own version.

Finalizing re-reads what was actually stored and compares it to the manifest. Every file matches or the version is discarded. There is no partial publish.

Limits, enforced when the list is declared: 100 files per version, 5 MB per file, 25 MB per version, and fifteen minutes to use a grant before it expires.

Published HTML is served by a different system, on a different host, from the application you sign in to. A page you publish has no way to read a session cookie you hold here, because the browser will not give it one.

Each site also gets its own origin — your-slug.example rather than a shared path — so two published sites are as separate from each other as any two websites are.

We never set a cookie on a published response, and published pages are marked noindex so they are not gathered into search results by default.

This is the distinction that matters more than any single rule. A blocklist — “reject .env, reject .pem” — fails open on whatever nobody thought of. An allowlist fails closed.

application/javascript · application/json · font/woff · font/woff2 · image/avif · image/gif · image/jpeg · image/png · image/webp · image/x-icon · text/css · text/html · text/javascript · text/markdown · text/plain

Files are also scanned for credentials before anything is stored. A publish carrying an API key, a private key or a database password is refused, naming the file and the line — most often a key an assistant wrote into the page it just generated.

What we hold:

• Your email address and the account it belongs to.
• Every slug you publish, and each file’s path, size, content type and SHA-256.
• Which versions exist, which is live, and when each change happened.
• Request metadata at our hosts: IP address, user agent, timestamps.

What we do not hold:

• Your conversation.
• Files you never declared — a grant authorises one path and nothing else.
• Any means of altering a published version after the fact. Versions are immutable once verified.