Data, Privacy, and Analysis

Where Ansight stores local app evidence, when data leaves the machine, and how to extract Trends history and individual sessions for independent analysis.

Ansight keeps normal app-session replays and workspace Trends history on the developer machine. The captured data belongs to you: it is stored as ordinary session files and a local SQLite database, and it can be exported without using Ansight cloud sharing.

This page covers host-side evidence collected by the resident Ansight host or CLI. Your source-controlled ansight/ workspace remains in the directory you manage, whether that is the app repository or a separate location.

Local by default

During normal capture, the instrumented app sends evidence to the local Ansight host. The host writes it to the current user’s application-data directory. Normal local capture does not use a cloud relay, and opening a capture in the local player or the loopback session explorer does not upload it.

Capture data can include sensitive information:

app, device, build, and runtime metadata;
logs and application events;
screenshots and visual-tree text;
telemetry and trends measurements;
touch input;
annotations and analyses; and
app-requested artifact files.

These capture files are not an encrypted vault. They are ordinary local JSON, images, artifacts, and SQLite data protected by the operating-system account, filesystem permissions, and any full-disk encryption you have enabled. Treat the data directory and every exported copy as sensitive development data.

Test secret values are separate. Definitions contain aliases only, while values are kept in the operating-system credential vault, a configured encrypted CLI store, or an environment variable whose name matches a declared alias. Secret values are not written into workspace test files merely because a test uses them. The app itself can still display or log sensitive content, so capture review and sanitization remain important.

When data leaves the machine

Local storage is the default, but these explicit workflows create another copy:

ZIP export writes a portable archive to the path you choose.
Sanitized export writes a new filtered archive and leaves the local capture unchanged.
Cloud sharing exports and uploads a replay to the selected team, authenticated audience, or public audience.
Cloud Trends upload copies selected local metrics and historical regression comparisons into organisation history.
Cloud test tracking uploads run summaries and counts, not prompt or validation bodies, logs, screenshots, secrets, or source files.
Hosted workspace testing can send model inputs and tool interactions to the configured hosted runner or model provider; that processing is separate from local capture persistence.

Cloud features require sign-in, an exact registered App ID for product-data uploads, and the relevant organisation entitlement. They are never required for local analysis. ansight session share uploads the raw capture by default. Add --sanitize for the built-in PII policy or --sanitizer <module.ts> for a custom policy. See Sanitizers and Exports and Handoff.

Find the data directory

The local player and CLI use the resident host’s configured base folder containing data/, logs/, and temp/.

Host	Default application-data location
macOS	`~/Library/Application Support/Ansight/data`
Windows	`%LOCALAPPDATA%\Ansight\data`
Linux	`$XDG_STATE_HOME/ansight/data` or `~/.local/state/ansight/data`

When the CLI uses --data-dir <path> or ANSIGHT_DATA_DIR, application data is stored beneath <path>/data.

Ask the CLI which base directory it is using instead of guessing:

ansight doctor
ansight host status --json

ansight doctor prints Data: <base-directory>. Append data to that base to locate the application-data files described below. A resident host’s structured status includes the same base path as dataDirectory.

Data directories from older installations are merged into the shared Ansight root on first launch after upgrading. Check ansight doctor before scripting an absolute path.

Storage layout

The important local paths are:

<base-directory>/
  data/
    session-captures/
      <app-id>/
        <session-id>/
          session.json
          device-profile.json
          logs.json
          log-streams.json
          application-events.json
          metric-channels.json
          telemetry/
          images.json
          images/
          touches.json
          visual-trees/
          artifacts/
          annotations.json
          analyses.json
          trends-results.json
    trends/
      trends-history.sqlite3
  logs/
  temp/

Folder names are filesystem-sanitized forms of the App ID and session ID. A capture contains only the evidence that was enabled and received, so some files or folders may be absent. While a session is active, the store can also contain append-oriented JSONL files and segmented data that are compacted later.

trends-results.json is the per-session sidecar when workspace Trends evaluation ran. The SQLite database is separate historical state used for cross-run metrics and regression comparisons.

Preferred: export a complete session

Use the versioned session archive when another tool or person needs a complete, portable snapshot. This avoids reading a directory while the host is still writing or compacting it.

Find the session ID and export it:

ansight session list --json
ansight session export <session-id> session.zip

The ZIP preserves session metadata and the available logs, telemetry, screenshots, visual trees, touches, annotations, analyses, and artifacts. It can be unpacked for your own Python, R, SQL, notebook, or command-line workflow, and it can later be re-imported:

ansight session import session.zip

For sensitive evidence, create a sanitized copy instead:

ansight session sanitize <session-id> sanitized-session.zip

The built-in sanitizer writes a report into the archive. A workspace-owned sanitizer can be selected with --sanitizer ansight/sanitizers/team-safe.ts.

Extract one kind of session evidence

CLI inspection commands return versioned structured JSON without requiring raw filesystem access:

ansight session show <session-id> --json
ansight session logs <session-id> --limit 10000 --json
ansight session metrics <session-id> --limit 10000 --json
ansight session images <session-id> --limit 10000 --json
ansight session touches <session-id> --limit 10000 --json
ansight session trees <session-id> --limit 10000 --json
ansight session artifacts <session-id> --limit 10000 --json
ansight session annotations <session-id> --limit 10000 --json
ansight session analyses <session-id> --limit 10000 --json

Redirect the JSON output to a file when feeding another analysis tool. These host contracts are preferable to depending on internal filenames that may evolve.

Read a per-session folder directly

Direct reads are useful for exploratory scripts because most capture metadata is JSON and binary evidence remains in named subfolders.

Use a completed session, or stop the writer before copying the directory. Do not edit files in place: the host indexes session.json, and partial writes or manual mutations can make the capture inconsistent. If you need a stable raw working set, copy the entire <session-id> directory and analyze the copy.

Treat JSONL, segmented logs, image filenames, and other internal layout details as implementation formats rather than a long-term API. Prefer a session ZIP or CLI --json contract for repeatable tooling.

Export Trends history

The supported path is the host’s versioned JSON response:

ansight trends history --limit 10000 --json
ansight trends history \
  --app-id com.example.app \
  --metric login-responsiveness.fps-p10 \
  --json
ansight trends history \
  --decision login-responsiveness.fps-p10 \
  --span-group "Secret Garden" \
  --json

The result includes the database path plus per-run metric records and historical comparison decisions. The decision ID is the monitored metric key because its regression policy is embedded on that metric. Use this route when building durable integrations because it follows the current host contract even if the underlying SQLite schema changes.

Analyze the SQLite database directly

The database is stored at:

<application-data>/trends/trends-history.sqlite3

Its primary tables are:

trends_metrics for numeric metric results and run, app, device, cohort, span-group, and status context; and
trends_history for current/reference comparisons, regression state, deltas, and app-version context.

The database uses SQLite WAL mode. If Ansight is running, do not copy only trends-history.sqlite3 and ignore its -wal file; that can produce an incomplete snapshot. Stop the host first, or use SQLite’s backup command to create a consistent analysis copy:

sqlite3 "/path/to/trends-history.sqlite3" \
  ".backup '/path/to/analysis/trends-copy.sqlite3'"

Then query the copy without risking the live store:

sqlite3 -header -csv "/path/to/analysis/trends-copy.sqlite3" \
  "SELECT evaluated_at_utc, app_id, app_version, metric_key, value, unit, metric_status FROM trends_metrics ORDER BY evaluated_at_utc" \
  > trends-metrics.csv

sqlite3 -header -csv "/path/to/analysis/trends-copy.sqlite3" \
  "SELECT evaluated_at_utc, app_id, decision_id, comparison, status, current_value, baseline_value, relative_delta_percent FROM trends_history ORDER BY evaluated_at_utc" \
  > trends-history.csv

Use read-only queries against your copy. The schema has an internal PRAGMA user_version and can evolve with Ansight, so inspect .schema and avoid writing records back into the live database.

Retention, backup, and deletion

Pin important sessions before cache cleanup:

ansight session metadata <session-id> --pin
ansight session cache status
ansight session cache compact --compaction-age-days 30
ansight session cache plan --retention-days 90 --max-cache 5GiB

Compaction preserves inactive captures in ZIP archives and reduces their disk footprint. Opening a compacted session expands it automatically and restarts its 30-day compaction age. Live sessions are skipped; pinned historical sessions may be compacted but remain protected from deletion. cache plan and cache prune are previews unless --apply is supplied. Export or copy data before intentionally deleting it:

ansight session delete <session-id>

Session folders and Trends history are separate stores. Deleting a capture removes its per-session directory; it does not rewrite the independent Trends history database. Plan retention for both stores when your project has legal or organizational data-lifecycle requirements.