The workflow
Save a snapshot of a thread’s full history outside bb.db, in a searchable file format such as JSONL. Users could keep the snapshot for reference, grep it, or bring it back into an agent’s context later.
One use case is deleting old threads to reduce database size while keeping a copy of their transcripts. This applies to both manual cleanup and automatic retention.
What happens today
Feedback on #4476 reports a 2.1 GB database, with 910 MB of event data belonging to 813 archived threads. The user has held off deleting those threads because they want to preserve their transcripts.
The comment also identifies a limitation for plugins trying to export at deletion time: thread.deleted fires after soft deletion, and handlers are not awaited before permanent deletion. A plugin cannot reliably export the events before they disappear. This timing concern has not been independently reproduced for this issue.
What you would expect
A way to explicitly snapshot a thread’s full history to storage outside the database:
- A documented, searchable file format such as JSONL.
- A destination that can survive deletion of the original thread and its storage folder.
- Access through the UI, CLI, and SDK.
- Clear success or failure feedback so users know whether they have a saved copy.
Integration with manual deletion or automatic retention would be useful, but the snapshot capability and how cleanup uses it are open design questions. This request does not require every deletion to produce a snapshot or require snapshots to restore threads in BB.
Context and alternatives
Related: #3598 — undelete. This request focuses on keeping a portable copy of thread history outside the database; restoring deleted threads in BB is a separate concern.
Continuously mirroring every thread’s events is a possible workaround for the reported deletion-hook limitation, but requires exporting all history ahead of any deletion.
Searched open and closed issues for transcript export and thread snapshots; no matching request was found.
AGENT GENERATED
The workflow
Save a snapshot of a thread’s full history outside
bb.db, in a searchable file format such as JSONL. Users could keep the snapshot for reference, grep it, or bring it back into an agent’s context later.One use case is deleting old threads to reduce database size while keeping a copy of their transcripts. This applies to both manual cleanup and automatic retention.
What happens today
Feedback on #4476 reports a 2.1 GB database, with 910 MB of event data belonging to 813 archived threads. The user has held off deleting those threads because they want to preserve their transcripts.
The comment also identifies a limitation for plugins trying to export at deletion time:
thread.deletedfires after soft deletion, and handlers are not awaited before permanent deletion. A plugin cannot reliably export the events before they disappear. This timing concern has not been independently reproduced for this issue.What you would expect
A way to explicitly snapshot a thread’s full history to storage outside the database:
Integration with manual deletion or automatic retention would be useful, but the snapshot capability and how cleanup uses it are open design questions. This request does not require every deletion to produce a snapshot or require snapshots to restore threads in BB.
Context and alternatives
Related: #3598 — undelete. This request focuses on keeping a portable copy of thread history outside the database; restoring deleted threads in BB is a separate concern.
Continuously mirroring every thread’s events is a possible workaround for the reported deletion-hook limitation, but requires exporting all history ahead of any deletion.
Searched open and closed issues for transcript export and thread snapshots; no matching request was found.