Inspect the app data behind an issue

Inspect live app files and databases, then save relevant snapshots to the session timeline for review after the app disconnects.

Check the files, databases, and assets your app is using when an issue occurs. The local player lets you browse approved app files, preview supported formats, and save a file to the session timeline so later reviewers have the same copy even after the app disconnects.

The host handles file access and previews. Browser code receives bounded content and typed viewer data, never an unrestricted host filesystem path.

Browse an SDK-connected app

When the selected live session exposes the files.* suite, use the Files view to browse only the roots approved by the app. Read access can include directory listing, text or binary download, checksum, and format-aware preview. Push, copy, move, and delete remain separate write or critical operations governed by the SDK policy.

Right-click a file and choose Save to timeline, or use the same action in its preview header, to stream the complete file through files.begin_binary_download and retain it as an artifact snapshot on the current session. The saved copy remains available after the app disconnects.

Browse an externally monitored app

The Files view also supports live external sessions. The host browses iOS simulator containers through simctl and the local filesystem, or Android emulator data through ADB. Android private access requires a debuggable app with run-as support or an already provisioned root ADB daemon. When access is unavailable, the player shows the reason.

External access supports browsing, previews, downloads, and Save to timeline. It is read-only. iOS supports the data and app containers and available app-group containers; Android supports the app data root. Paths are relative to the selected root, and traversal and symlinks are refused.

SQLite previews and queries operate on a local copy; the browser does not query the running app’s database directly. Live copies are best effort, so capture at a stable point when consistency matters. The monitor can also copy selected files when capture ends; see automatic sandbox copies.

Workspace tasks use ansight.files.list, read, and capture for external sandbox access. These host APIs are distinct from the SDK’s app.files suite; see the Task API.

Captured artifacts

Artifacts stored with a session remain available after disconnect. The host resolves persisted artifact paths beneath the captured snapshot directory and applies bounded reads before returning viewer data.

Built-in viewers

Depending on the installed host version, the player can render:

  • structured JSON and XML;
  • binary or XML property lists;
  • CSV tables and Markdown;
  • source code and plain text;
  • images, PDFs, audio, and video;
  • SQLite schema and read-only query results;
  • GLB, glTF, OBJ, and STL assets.

Unknown or oversized files fall back to metadata and explicit download instead of being interpreted speculatively.

SQLite safeguards

SQLite inspection is read-only. The local player accepts bounded SELECT, WITH, PRAGMA, or EXPLAIN queries and does not open a database directly in browser code. Export a working copy before using an external application that may mutate the file.

CLI access

Agents should discover the file or artifact tool first, then use the relevant ansight app call, ansight session artifacts, or export command. Avoid copying secrets or unrelated app data into a prompt merely because a file is available.