delete_session leaves the transcript .jsonl on disk for spawned/child task sessions

Status Open
Reported on v2.1.266
Maintainer reply None cached
Activity 0 comments · opened Sep 12, 2026

Summary

Deleting a session via the delete_session MCP tool (or the equivalent UI action) removes the session's record from the app's session index, but for a session that was itself a spawned child task (created via a background/scheduled task spawning a sub-task, not opened directly by the user), the underlying transcript .jsonl file under ~/.claude/projects/<project>/<sessionId>.jsonl is left behind on disk, fully intact and readable.

This contradicts the tool's own documented behaviour: delete_session's description states "Each session's transcript, record and worktree (with its branch) are removed and cannot be recovered."

Evidence

~/Library/Logs/Claude/main.log shows the deletion completing normally for the affected session:

LocalSessions.delete: sessionId=local_14e76123-1f6e-45a2-9fc9-4c57b0880187
[CCD] Spawned-task ended → parent local_c76058e7-66dd-48a4-b51f-f05747aa0826: task_ef28d57d (local, child local_14e76123-1f6e-45a2-9fc9-4c57b0880187)
Archived session local_14e76123-1f6e-45a2-9fc9-4c57b0880187
[CCD] delete local_14e76123-1f6e-45a2-9fc9-4c57b0880187: 0 side session(s) named, 0 left live
Deleted session local_14e76123-1f6e-45a2-9fc9-4c57b0880187
Shell PTY for session local_14e76123-1f6e-45a2-9fc9-4c57b0880187 exited (stale — already replaced)
[LocalSessionManager] Requested CCR delete of 1 Remote Control bridge session(s) for deleted session local_14e76123-1f6e-45a2-9fc9-4c57b0880187

Confirming the record is genuinely gone from the index (not just unlisted), mcp__ccd_session_mgmt__get_session on that internal session ID returns:

Session local_14e76123-1f6e-45a2-9fc9-4c57b0880187 not found.

The transcript file's sessionId field inside the JSONL is a different UUID from the internal local_<uuid> the app uses to track/delete the session (the mapping is logged separately: Mapping internal session local_14e76123-1f6e-45a2-9fc9-4c57b0880187 to CLI session 98d5ed86-0690-45e2-bcb9-4e6eeaeffbab) — despite this, the file at ~/.claude/projects/<project>/98d5ed86-0690-45e2-bcb9-4e6eeaeffbab.jsonl still exists after deletion, at its full original size (observed: ~2.9MB, matching the session's actual content, still fully parseable).

list_sessions and search_session_transcripts both correctly show no trace of the deleted session (consistent with the index deletion), but the raw file is still directly readable from disk by any process with filesystem access, and — separately — was also never listed as a discoverable session even before deletion, since it was a spawned child task rather than a top-level session (a possibly-related, separate gap: list_sessions doesn't appear to enumerate spawned child task sessions at all, top-level or otherwise).

Expected behaviour

Per delete_session's own description, the transcript should be unrecoverable after deletion. At minimum, the raw .jsonl file backing a deleted session should be deleted from disk alongside the index record.

Actual behaviour

The index record is removed (get_session → not found), but the raw transcript .jsonl file survives deletion, fully intact, for a spawned/child task session.

Environment

  • Claude Code desktop app, version 2.1.266 (from the transcript's own version field)
  • macOS
  • The affected session was created via a spawned background task (spawn_task/scheduled-task-launched child session), not a top-level interactive session

Why this matters

Anyone deleting a session for privacy or content-removal reasons (rather than just tidiness) would reasonably rely on the documented "removed and cannot be recovered" guarantee. For this session type at least, that guarantee doesn't hold — the full content remains trivially recoverable from disk after the app reports the session deleted.

View original on GitHub ↗