Recordings and capture history

Record a connected device

1. Open a project and select its device in the center toolbar.
2. Choose Start Recording and review the capture options. Visual tracks require explicit selection and platform permission.
3. Reproduce the issue, then stop the recording.
4. Open Recordings in that project’s sidebar to replay, export, or delete it.

Recordings appears when the project has saved recordings or a recovery problem to review. Capture remains tied to the device selected at the start; switching projects/devices does not add other sessions to it.

This also works for connected .NET and Node.js servers: select the server’s connection to record logs and HTTP activity on the Mac. These adapters do not provide offline recording or screen capture.

Use the toolbar folder button or Open Recording… (⌘O) to import a .tracebeam file. Replay does not execute the original app or resend captured HTTP requests. Leaving replay returns to live inspection. Deleting a library recording moves its file to Finder’s Trash; exported copies remain separate.

Recording buffer and recovery

Settings → Recording controls the writer’s memory buffer. It is a queue budget, not the recording’s maximum file size or a guarantee against a slow/full disk. A larger buffer can absorb a burst but also uses more memory.

Required state updates are not silently skipped to keep recording going. If the writer cannot accept or save required data, capture stops and committed data is finalized as an interrupted recording where possible. Optional screen-capture overload can stop only the visual track.

After an unexpected exit, Tracebeam attempts to recover committed records on the next launch. Recovered recordings are marked interrupted and returned to their project (or Default if it was removed). Uncommitted data and unfinished video segments may be lost. Failed recovery keeps the original recovery files and exposes a review action; recovery cannot guarantee restoration from damaged or full storage.

On-device support recording

The installed React Native and Flutter SDKs can record without a Mac connection. Your app must expose an explicit recording action and let the user review options and consent. The resulting local .tracebeam file can be shared using the platform share sheet and opened on the Mac. Nothing uploads automatically.

Connecting the SDK never starts screen recording. Supported visual modes depend on the runtime/platform; Flutter iOS Simulator video uses the Mac’s Simulator tooling, while physical-device capture uses platform screen-capture APIs. Use a full native rebuild after SDK updates.

Recent capture history is separate

Settings → Capture → Save recent capture history is off by default and asks for confirmation. It saves future Network, Console, and Timeline entries locally, without a full replay recording, video, or state checkpoints. Demo and unassigned traffic are excluded.

Use History in an inspector to browse retained data for the current project’s devices one at a time. Disabling history stops new writes but keeps saved entries. Clear one project’s history or all history with confirmation; this does not delete explicit recordings or clear live capture.

History has a storage budget and row cap, evicts the oldest entries, and may skip observations under storage pressure. It is a convenience for recent investigation, not a complete audit log.

Privacy and sharing

Recording recovery files, library archives, exports, and capture history can contain credentials, request bodies, private logs/state, and screen content. They are local but not encrypted storage. Deletion is not secure erasure. Review before exporting or sharing.

Network investigation sharing is a separate, smaller JSON export—not a replay recording. Its privacy preview excludes bodies/logs by default and masks common secrets. Optional content can still contain private information; review the exact preview and explicitly confirm sharing. Automatic masking is not a guarantee that every secret is removed.