Trails is designed around metadata over transcripts. Each stage derives the smallest bounded representation needed by the next stage.
Always stays on the originating Mac
- Raw coding-agent transcript bodies.
- Local transcript file paths.
- The original session files owned by Claude Code, Codex, omp, or pi.
- Parsing of those files.
Trails never sends transcript bodies or transcript paths to the hub.
One-Mac mode
The default installation keeps the complete application on one Mac. Its collector and canonical SQLite service communicate over loopback. No trails data needs to cross the network.
The service always binds to 127.0.0.1:7412. It does not listen on the LAN.
Optional multi-Mac mode
Each spoke sends normalized observations over a private Tailscale connection to the hub:
- source type;
- a session identifier used for idempotent ingestion;
- working directory and branch context;
- timestamps and event counts;
- the first prompt;
- minute-level activity;
- a bounded digest used for optional summarization.
The hub stores these observations in its local SQLite database. Tailscale transports the encrypted connection; it does not run trails or store trails data.
Tailscale Serve exposes the hub’s loopback service privately to authorized devices on the tailnet. Trails still does not open a LAN listener or public endpoint.
Reaches the browser
The web app receives the information needed to render the timeline and save your organization. It does not receive source-local session identifiers or bounded digests.
Capture bootstrap data includes display fields such as titles, timestamps, project context, and image metadata. Private capture summary inputs, including bounded meeting notes and prompts, stay in hub storage and are omitted from bootstrap responses to both the browser and generic clients such as plugins.
In local mode the browser connects to http://127.0.0.1:7412/. In multi-Mac mode an authorized tailnet device can use the private HTTPS URL configured by Tailscale Serve.
May reach one harness-configured provider
Generated summaries are optional and off by default. After the hub owner activates a harness, Trails sends that local process only trails-owned system prompts and the bounded summary input for a queued job. The provider already configured in the harness may receive that input. Complete transcripts, source files, database contents, collector traffic, and unrelated environment values are never summary input.
Current limits are:
- up to 9,000 characters for a session summary input;
- up to 12,000 characters for a day summary input;
- up to 4,000 characters of stored harness output.
Harness selection remains on the hub in owner-only ~/.config/trails/server.json. Harness credentials stay under the harness’s ownership; Trails never reads, copies, refreshes, stores, or exposes them. The browser receives only harness availability, selection, timestamps, and a closed error class.
If no harness is active or it is unavailable, timeline collection continues and durable summary jobs remain queued. Trails uses the session’s first prompt as fallback copy and never sends a failed job to another harness automatically.
Optional beta feedback
Feedback leaves the browser only when you press send. Every report contains the selected feedback kind, your message, an optional follow-up, and the time you created it.
Safe context is off by default. If you turn on include safe context, trails adds only:
- the trails app version and current view;
- the canonical hub revision;
- the selected work date when you are in Days or Project;
- session counts grouped by Claude Code, Codex, omp, and pi;
- viewport width and height;
- whether browser synchronization is currently in an error state.
Safe context never includes a URL or tailnet detail, device or project name, local path, branch, prompt, summary, identifier, digest, transcript content, or browser user-agent.
The browser writes the report directly to a separate Cloudflare feedback Worker and D1 database. That endpoint accepts writes from allowed trails origins and has no public read route. Feedback records expire after 90 days and are deleted by the next daily cleanup.
This expiring feedback store is separate from summary generation. It never becomes canonical trails state; the hub Mac’s SQLite database remains canonical for sessions and organization.