Discuss session deletion semantics across source agents

[samzong]

Summary

A user requested a way to delete a session and specifically used wording equivalent to "delete completely". This needs product and implementation discussion before we expose a delete action.

Source user: https://linux.do/u/nolog

Problem

Recall indexes sessions from source agents. If Recall only deletes its local SQLite rows, the next sync can re-import the same session from the source tool because the source data still exists.

That makes a plain session delete command misleading unless the product semantics are explicit.

Product question

What should "delete a session" mean in Recall?

Possible semantics:

1. Forget from Recall

   • Delete the session from the Recall index.
   • Record a tombstone keyed by (source, source_id) so future sync/import does not bring it back.
   • Do not delete source-agent data.
   • Wording should avoid "permanent" or "complete" deletion.

2. Delete source data too

   • Recall would delete the backing session from Claude Code, Codex, OpenCode, Grok, Cursor, etc.
   • This is much riskier because each source stores sessions differently and Recall does not currently own those storage contracts.
   • This should probably be a separate, source-specific design, not the first version.

3. No delete support

   • Keep Recall read/index/export/share/resume only.
   • Users must delete sessions in the original agent and then re-sync.

Current code context

• sessions are keyed by (source, source_id).
• Store::delete_session_data(source, source_id) only removes Recall-indexed data.
• Sync scans source-agent storage and can re-insert sessions if the backing source still exists.
• SourceAdapter currently supports scan/prune/resume/open style operations, not source deletion.
• Existing docs marked local session deletion and source editing out of scope for the first session CLI release.

Suggested first version

If we support this, the safest first version is likely:

• Add a session_tombstones or equivalent ignored-session table keyed by (source, source_id).
• recall session delete --id <id> removes Recall-indexed data and records the tombstone.
• Sync/import must skip tombstoned sessions.
• Add an explicit restore/unignore path.
• UI/CLI copy should say "Forget from Recall", not "Delete completely".

Discussion needed

• Is tombstone-based "forget" enough for the user expectation?
• Should source deletion ever be supported by Recall?
• How should shared/published session pages be handled if the deleted session was already published?
• Should imported sessions and locally backed sessions have different delete behavior?