Setup guide

Share Threads Securely

Trit can publish read-only thread and artifact views through a second loopback listener. The share listener uses the same SQLite database and private artifact storage as Trit. It does not mount Trit APIs, WebSockets, terminals, Git, project files, or prompt submission routes.

Thread sharing is disabled until TRIT_SHARE_PUBLIC_ORIGIN is set.

Choose whether to enable sharing

Enable sharing only when the owner needs to send thread or artifact content to other people. Otherwise, omit all TRIT_SHARE_* variables. Trit will not start the share listener or show thread or artifact share controls.

Thread shares have one update mode:

Standalone artifact shares also support frozen and live modes. A frozen artifact share serves the exact revision selected at creation. A live artifact share resolves the current revision whenever the viewer loads the page. Neither mode streams changes into an open page.

Both thread modes include the history that the main chat renders: user and assistant messages, reasoning, tool activity, terminal-output blocks, diffs, approval activity, errors, turn boundaries, session notices, and the exact artifact revisions selected when the share is created. They include images or resource links attached to user messages. They omit raw ACP payloads, hidden mode and configuration events, the terminal dock, and all workspace controls.

The share listener has no prompt-submission route, workspace API, or WebSocket. A viewer can expand local transcript details and open shared attachments or artifacts, but cannot send a message, answer an approval, run a tool, or modify the thread or artifact.

Each share also has one access mode:

Each share can expire after 1, 3, 6, 12, or 24 hours; after 1, 7, 14, or 30 days; or never. Every share can be revoked. Trit stores only a SHA-256 hash of each token and shows the full URL once, immediately after creation.

The owner UI defaults to a dialog. Set settings.shareUi to panel to open sharing in a right sidebar instead:

settings:
  shareUi: panel

Keep sharing on a separate origin

Use separate hostnames and loopback origins:

SurfacePublic hostnameLoopback originAccess policy
Full Trit workspacetrit.example.comhttp://127.0.0.1:9420Existing owner policy
Read-only thread and artifact sharesshare.example.comhttp://127.0.0.1:9520Access only on /e/*

Do not add share routes to the full Trit hostname. Do not expose either loopback port directly to the public Internet.

Configure the reverse proxy or tunnel to preserve the existing workspace route and add the share route. A Cloudflare Tunnel ingress configuration can use:

ingress:
  - hostname: trit.example.com
    service: http://127.0.0.1:9420
  - hostname: share.example.com
    service: http://127.0.0.1:9520
  - service: http_status:404

For a remotely managed tunnel, add the share hostname to the tunnel’s public hostnames and route it to http://127.0.0.1:9520.

Configure optional email authentication

Skip this section if the owner only needs link-only shares.

  1. Enable a Cloudflare Access login method, such as One-time PIN.
  2. Create a self-hosted Access application for share.example.com/e/*. The /e/* path covers email-restricted thread shares, standalone artifact shares, and artifact content selected in thread shares. /s/* serves all link-only shares.
  3. Add an Allow policy for the identities that may attempt authentication. Trit performs the narrower per-share email check after Cloudflare authenticates the visitor.
  4. Copy the application audience tag. Use it only as TRIT_SHARE_CF_ACCESS_AUD.

The share audience must differ from every audience in TRIT_CF_ACCESS_AUD. If an Access application protects the full share hostname, verify that it does not block the intended /s/* link-only behavior.

Configure Trit

Add the share listener values to Trit’s environment file:

TRIT_SHARE_PUBLIC_ORIGIN=https://share.example.com
TRIT_SHARE_HOST=127.0.0.1
TRIT_SHARE_PORT=9520

To enable email-restricted shares, also add:

TRIT_SHARE_CF_ACCESS_AUD=the-share-access-application-audience

The share listener reuses TRIT_CF_ACCESS_TEAM_DOMAIN to verify Cloudflare Access signatures. The full workspace continues to use TRIT_CF_ACCESS_AUD and its existing owner allowlist.

Restart Trit through the installation’s normal service-management procedure after updating the environment.

Verify the boundary

Verify both loopback listeners:

curl -fsS http://127.0.0.1:9420/health
curl -fsS http://127.0.0.1:9520/health

Confirm that the share listener does not expose workspace routes:

curl -i http://127.0.0.1:9520/api/threads
curl -i http://127.0.0.1:9520/ws/thread/example

Both requests must return 404.

Open a non-draft thread in Trit and select Share thread. Create a short-lived frozen share and confirm that its reasoning, activity, and selected artifact revisions appear but later events or revisions do not. Create a live thread share and confirm that later visible history appears after a reload. In the Artifacts workspace, create frozen and live artifact links and confirm that the sandboxed file loads. Confirm that no share page has a message composer, approval controls, or workspace navigation. For email-restricted shares, confirm that a listed email can open each type and that a different email cannot.

Revoke each test share. Refresh its URL and confirm that Trit reports that the share is unavailable.

Operations