Privacy and data handling

What a published session can contain

A publisher selects a saved session and reviews it before sharing. Depending on the app and saved source, it may include user and assistant messages, tool calls and results, command output, system or error records, and attachments. It may also include details such as the app name and version, session ID, capture time, title, and summary. Each source records different information, so a capture may not include everything that happened in the original app.

A session may contain source code, prompts, personal information, passwords, or other sensitive text in addition to any attached files provided to the agent during the session. Before publishing, the service checks readable content for known patterns, however it does not review session attachments. The publisher can review flagged items and request exact-text redactions. These checks can miss sensitive information; a clean scan does not guarantee that a session is safe to share.

The web view of a session shows metadata about the session as well as the SHA for each file contained within the download of that session. The zip bundle is not scanned and is available only as a download. Visitors electing to download the session must accept a warning before each download, and the link given after attestation is temporary and stops working after a short time.

The publisher approves the content and chooses who can open each link. Anyone with an anonymous link can open it. A restricted link requires GitHub sign-in and an account that meets the publisher's access rules. People can forward links. A forwarded anonymous link works for anyone; a forwarded restricted link still requires an eligible account.

Publishers can set a link to expire or revoke it. If they publish the same session again with different access, expiry, redaction, title, or summary settings, the new version can have a separate link. An older link can keep showing the version approved for it. Expiring or revoking a link does not delete the session.

These access checks do not confirm who created a session or whether its contents are correct or safe.

How session content is stored and managed

The database stores session and link details, such as the title, summary, access rules, expiry settings, and references to the content. Session transcripts, uploaded files, and resumable bundles are stored separately in private file storage. The database references let the service find those files when a link allows access.

Each share link has its own access rules and expiry or revocation settings and one session can have many share links with varying expirations, redactions, etc. Therefore, the expiration (forced or otherwise) of one link does not delete the session. Deleting a session link blocks further access to it via that link. Purge later removes the database record and requests deletion of the stored files.

Expiry, deletion, and purge

When a link expires or is revoked, new requests through that link are denied, but the session and its files stay stored. When a publisher deletes a session, the service marks it as deleted and denies new link requests. It does not delete the files at that point. The publisher can restore the session before purge. The publisher can request purge any time after deletion. Otherwise, the service can purge it once both the wait period (90 days by default) has passed and the last active link has expired.

At purge, the service removes the session record and requests deletion of its transcript, uploaded files, and resumable bundle, unless another session still uses a file. It records the purge and reports any file it could not delete; a later cleanup job will retry unreferenced files. Deleted files can be restored from storage for 30 days. After that recovery window, deleted files are removed from storage. There is no SLA on the time when a version is permanently removed from storage. Session Registry cannot delete copies downloaded or saved elsewhere.

Sign-in and service operations

GitHub handles sign-in and checks access to restricted links. After sign-in, the browser gets a session cookie. The server stores the GitHub credential in an encrypted session until it expires. The site also uses cookies for login and request security. When a publisher uses a GitHub token to check an audience, the service uses it for that request and does not store it. The theme choice is saved in the browser.

Cloud services run the app, database, cache, private file storage, request routing, and monitoring. The app records diagnostic information to help operate the service, investigate problems, and protect access. Depending on the event, these records may include an internal publisher ID, an action, an error, or a one-way hash of a network address made with a random per-process value. Audit records may include a GitHub login or internal publisher ID, session IDs, the action, time, and result. Security-event records are designed not to include raw IP addresses, access tokens, or storage access URLs. Other diagnostic records may contain session-related details.

Session files, sign-in records, audit records, and diagnostics are stored separately and can have different retention settings. Their lifetimes depend on current service settings. This page describes the data flows, not every service or system that may support the site.

Choices available to visitors