Claude Code 會在 30 天後刪除歷史記錄：如何保存它

如需服務使用說明，請參閱 Ailoot 文件。

Claude Code 真的會刪除工作階段歷史記錄嗎？#

你開啟 Claude Code，想接續兩個月前的工作階段，卻發現它已經不見了。檔案已從磁碟上徹底刪除。這不是故障，也不是罕見的錯誤，而是預設清理機制的運作方式。

有一項設定控制清理：cleanupPeriodDays。其預設值是 30。每次 Claude Code 啟動時，都會掃描歷史記錄資料夾，刪除超過該期限的所有內容。我的 ~/.claude/settings.json 裡完全沒有這項設定，這表示系統使用了預設值，而我的部分舊工作階段已經消失了。

Anthropic 的儲存庫中已有多項相關錯誤回報，但都尚未修復。

Claude Code 將工作階段歷史記錄存放在哪裡？#

找到歷史記錄很簡單。開啟終端機並查看資料夾內容：

ls ~/.claude/projects/

每個子資料夾都是一個獨立專案。資料夾名稱會編碼路徑：例如，位於 /Users/alex/dev/shop 的專案會成為 -Users-alex-dev-shop 資料夾。裡面則有工作階段檔案：

ls -lt ~/.claude/projects/-Users-alex-dev-shop/
# 3f8a1c2e-....jsonl   ← 一個工作階段 = 一個檔案
# a91b7d40-....jsonl

每個 .jsonl 都是逐行記錄檔：一行代表一個工作階段事件。內容不只有對話文字，還包含你決策背後的邏輯：為什麼選擇特定的資料庫結構、否決了哪些選項、Claude 在哪裡出錯，以及你如何修正。

本質上，這就是專案開發日誌。失去它令人難受，因為你失去的不是一段「聊天」，而是數週來累積的脈絡。我在指南「Claude Memory 與 CLAUDE.md」中介紹了這些脈絡的組成方式。

Anthropic 為什麼要在 30 天後刪除逐字稿？#

刪除有其理由，在全部關閉之前值得先了解。逐字稿是純文字。如果 Claude 在工作階段中讀取 .env 檔案、將金鑰插入命令，或你在提示中貼上密碼，這些內容都會以純文字形式寫入 .jsonl。這種檔案留在磁碟上的時間越久，日後外洩的機率就越高。

Anthropic 說得很清楚：逐字稿可能包含原始碼、憑證和其他敏感資料；將它們保存在磁碟上的時間超過必要範圍，會造成實際的隱私風險。30 天期限是經過權衡後的折衷方案。

社群的反對意見集中在三件事：刪除是悄悄進行的（設定時或啟動時都沒有警告）、不會徵求同意（不會詢問你），而且無法復原（不會移至垃圾桶，也沒有回復機制）。在 issue #59248 中，開發者只要求一件事：讓清理機制更公平——提供警告、復原期限，以及不那麼積極的預設期限。

為什麼備份指令碼本身可能觸發刪除？#

這是最棘手的部分，也讓試圖自行保護資料的人容易踩坑。清理機制會查看 mtime，也就是檔案的最後修改時間。它假設 mtime 代表你最後一次在該工作階段工作的時間。實際上，任何東西都可能改變 mtime：Dropbox 或 iCloud 同步用戶端、rsync、防毒軟體、索引器，或你自己的備份指令碼。

陷阱就在這裡。你決定保存歷史記錄，並為 ~/.claude/projects/ 設定雲端同步。某個時候，同步服務會重寫檔案，並將其 mtime 設為較早的日期（從雲端副本還原時就可能發生）。Claude Code 在啟動時看到「舊」檔案便會將它刪除。你本想保存它，卻反而加速了它被刪除。

結論只有一個：備份必須放在 ~/.claude/projects/ 之外。清理機制只會在這個資料夾內運作。儲存在外部的副本不受清理機制影響。我會以這項原則為基礎建立解決方案。

如何立即停止刪除歷史記錄？#

依照以下三個步驟停止刪除：

1. 開啟設定檔案：~/.claude/settings.json（如果檔案不存在，請建立它）。
2. 加入數值較大的 cleanupPeriodDays 設定：

{
  "cleanupPeriodDays": 3650
}

3. 儲存檔案。設定會在下次啟動 Claude Code 時生效。

數值 3650 代表十年：實際上，系統將不再刪除內容。如果你想保留清理功能，但延長期限，請設為 365（一年）；屆時只有超過一年的工作階段會消失。你可以使用這個命令檢查設定是否已套用：

grep cleanupPeriodDays ~/.claude/settings.json

有一項容易忽略的注意事項：延長期限不會復原已刪除的內容。清理機制會在啟動時執行，過去執行時刪除的內容已經永遠消失。因此你應該先設定此項目——它能防止未來的損失，但無法取回已經刪除的內容。如果你不只想避免遺失 Claude Code 歷史記錄，也想避免因為誤下命令而毀掉專案，請參閱指南「如何設定 Claude Code，避免它破壞你的專案」。

工作階段歷史記錄是專案第二大腦的一部分，其中包含你未曾記錄在其他地方的決策邏輯。cleanupPeriodDays 可以保存檔案，但不會讓它們成為六個月後能讓你找到所需內容的系統。

如何自動將歷史封存到清理資料夾之外？#

想法很簡單：讓 Claude Code 隨意處理自己的資料夾，同時在外部保留獨立封存副本。它可避開這套清理機制，但磁碟故障、誤刪或複製失敗仍可能讓它遺失。設定方式如下：

1. 在受管理目錄外建立封存資料夾：

mkdir -p ~/claude-history-archive

2. 將目前的歷史記錄複製到那裡。-a 旗標會保留結構和時間戳記；--ignore-existing 則會讓已複製的檔案保持不變：

rsync -a ~/.claude/projects/ ~/claude-history-archive/

3. 設定每天自動執行一次。在 macOS 上使用 launchd。建立檔案 ~/Library/LaunchAgents/com.example.claudearchive.plist：

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.example.claudearchive</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/rsync</string>
    <string>-a</string>
    <string>/Users/YOUR_NAME/.claude/projects/</string>
    <string>/Users/YOUR_NAME/claude-history-archive/</string>
  </array>
  <key>StartInterval</key>
  <integer>86400</integer>
</dict>
</plist>

4. 載入代理程式，讓它在背景執行：

launchctl load ~/Library/LaunchAgents/com.example.claudearchive.plist

在 Linux 上，只需在 crontab 中加入一行（crontab -e）即可完成相同設定：

0 3 * * * rsync -a ~/.claude/projects/ ~/claude-history-archive/

為什麼這種做法有效，而上一節的同步方式會失敗？封存資料夾位於 ~/.claude/projects/ 之外，清理機制完全看不到它。複製作業只有一個方向（從運作中的資料夾到封存資料夾），而且不會碰觸運作中檔案的 mtime，因此不會發生 mtime 問題。即使 Claude Code 明天從自己的資料夾刪除某個工作階段，它在封存資料夾中的副本仍會保留。

如何將工作階段封存檔轉變為可搜尋的第二大腦？#

光是累積檔案還不夠——你還得能存取它們。只要兩個步驟，就能讓封存檔成為實用工具。

首先，使用 git 管理版本。在封存資料夾中初始化儲存庫：

cd ~/claude-history-archive
git init
git add -A && git commit -m "Claude Code 歷史記錄的第一個快照"

將 git add -A && git commit 加到執行 rsync 的每日工作中。現在你就有了版本歷史記錄：可以查看新增了什麼以及何時新增，並透過一個命令復原意外覆寫的內容。

其次，進行搜尋。.jsonl 檔案是逐行分隔的 JSON，因此可以使用熟悉的工具。找出討論特定主題的工作階段：

grep -rl "資料庫遷移" ~/claude-history-archive/

使用 jq 從工作階段中只擷取提示文字（因為它是 JSON）：

jq -r 'select(.type=="user") | .message.content' session.jsonl

到這個階段，工作階段歷史記錄就開始成為專案的第二大腦：這是一個能讓你在幾秒鐘內找出「我們三月時是怎麼決定這件事」的資料庫。如需了解工作階段脈絡的存放位置及管理方式，請參閱另一篇說明「Claude Code 中的 Token 都去哪了」。

可以復原已刪除的工作階段嗎？#

坦白說，答案大概是不行。Claude Code 沒有復原功能、垃圾桶，也沒有已刪除逐字稿的復原記錄。檔案就這樣從磁碟上消失了。

有一種方法：如果事先啟用了系統備份，就可以嘗試還原：

1. macOS Time Machine——如果某個快照在刪除前包含 ~/.claude/projects/，你可以從所需日期的備份中取回檔案。
2. OneDrive / Dropbox 版本歷史記錄——如果資料夾已啟用版本管理並同步，請在雲端的版本歷史記錄中尋找檔案（但請記住 mtime 陷阱：同步也可能觸發刪除）。
3. 手動副本——你曾手動使用 rsync 或 cp 複製到受管理資料夾以外的任何副本。

如果這些副本都不存在，工作階段就已經遺失。而這種情況並不少見：Anthropic 儲存庫中的一則錯誤回報提到，有 38 筆記錄中的 26 筆損毀，代表數個月的工作付諸流水。唯一可靠的保護方法，是在損失發生之前就先設好。趁現在還有內容可保存，今天就設定 cleanupPeriodDays 和自動封存。

cleanupPeriodDays 應該設為多少？#

只有一項設定，但它有幾種不同的意義。比較各選項，並依照你的用途選擇：

有一項重要的安全注意事項：如果你設定 3650 並保留所有內容，就代表你同意將可能包含金鑰和程式碼的逐字稿存放在磁碟上。這是封存便利性與風險之間的刻意取捨。要降低風險：將封存檔存放在加密磁碟上（macOS 可使用 FileVault），不要放在公用雲端，也不要將它提交至公開的 git 儲存庫。我另外整理了一篇指南，說明 Claude Code 可能洩漏哪些資料：「Claude Code 的資料安全」。

今天要做什麼：檢查清單#

依照以下步驟設定保護措施：

1. 在 ~/.claude/settings.json 中將 cleanupPeriodDays: 3650 設定好——你已停止刪除。
2. 在受管理資料夾外建立 ~/claude-history-archive，並執行第一次 rsync -a。
3. 使用 macOS 的 launchd 或 Linux 的 cron 設定每日執行。
4. 在封存資料夾中初始化 git，並將 git add -A && git commit 加入同一項工作。
5. 確認封存檔位於加密磁碟上，且未同步至公用雲端。
6. 檢查每次排程是否成功複製，再查看近期封存工作階段，定期在獨立暫存資料夾還原樣本，驗證可閱讀。
7. 若也要防範裝置或磁碟遺失，請另存有適當存取控制的獨立備份並測試還原；同磁碟 Git 歷史不是獨立備份。

工作階段歷史記錄只是讓 Claude 可靠運作的其中一層脈絡。

進一步認識 Ailoot。