Claude Code memadam sejarah selepas 30 hari: cara menyimpannya

Untuk mendapatkan bantuan menggunakan perkhidmatan ini, lihat dokumentasi Ailoot.

Adakah Claude Code benar-benar memadam sejarah sesi anda?#

Anda membuka Claude Code untuk menyambung semula sesi dari dua bulan lalu—tetapi sesi itu sudah tiada. Fail tersebut telah dipadam sepenuhnya daripada cakera. Ini bukan gangguan atau pepijat yang jarang berlaku: begitulah cara mekanisme pembersihan lalai berfungsi.

Satu tetapan mengawal pembersihan: cleanupPeriodDays. Nilai lalainya ialah 30. Setiap kali Claude Code dimulakan, ia mengimbas folder sejarah dan memadam semua kandungan yang lebih lama daripada tempoh tersebut. Saya langsung tidak mempunyai tetapan ini dalam ~/.claude/settings.json, yang bermaksud nilai lalai sedang digunakan dan beberapa sesi lama saya sudah pun hilang.

Beberapa laporan pepijat tentang perkara ini masih terbuka dalam repositori Anthropic, dan tiada satu pun telah dibetulkan.

Di manakah Claude Code menyimpan sejarah sesi?#

Mencari sejarah anda mudah. Buka terminal dan lihat kandungan folder:

ls ~/.claude/projects/

Setiap subfolder ialah projek berasingan. Namanya mengekod laluan: contohnya, projek di /Users/alex/dev/shop akan menjadi folder -Users-alex-dev-shop. Di dalamnya terdapat fail sesi:

ls -lt ~/.claude/projects/-Users-alex-dev-shop/
# 3f8a1c2e-....jsonl   ← satu sesi = satu fail
# a91b7d40-....jsonl

Setiap .jsonl ialah log baris demi baris: satu baris bersamaan dengan satu peristiwa sesi. Kandungannya lebih daripada teks perbualan. Ia menyimpan logik di sebalik keputusan anda: sebab anda memilih struktur pangkalan data tertentu, pilihan yang anda tolak, kesilapan yang dilakukan Claude dan cara anda membetulkannya.

Ringkasnya, ia ialah jurnal pembangunan projek. Sebab itulah kehilangannya menyakitkan: anda bukan kehilangan “sembang”, tetapi konteks yang telah anda bina selama berminggu-minggu. Saya menerangkan struktur konteks ini dalam panduan “Claude Memory vs. CLAUDE.md”.

Mengapa Anthropic memadam transkrip selepas 30 hari?#

Pemadaman mempunyai rasionalnya, dan wajar difahami sebelum anda mematikannya sepenuhnya. Transkrip ialah teks biasa. Jika Claude membaca fail .env semasa sesi, memasukkan kunci ke dalam arahan, atau anda menampal kata laluan ke dalam arahan, semuanya akan tersimpan dalam .jsonl sebagai teks biasa. Semakin lama fail sedemikian berada pada cakera, semakin besar kemungkinan ia akan bocor suatu hari nanti.

Anthropic menyatakannya dengan jelas: transkrip mungkin mengandungi kod sumber, kelayakan log masuk dan bahan sensitif lain; menyimpannya pada cakera lebih lama daripada yang diperlukan menimbulkan risiko privasi yang nyata. Tempoh 30 hari dipilih sebagai jalan tengah.

Bantahan komuniti tertumpu pada tiga perkara: pemadaman berlaku secara senyap (tiada amaran semasa persediaan atau permulaan), tiada persetujuan diminta, dan tiada pemulihan (Sampah tidak digunakan dan tiada cara untuk mengundurkan pemadaman). Dalam issue #59248, pembangun meminta satu perkara: jadikan pembersihan adil—berikan amaran, tempoh pemulihan dan tempoh lalai yang kurang agresif.

Mengapa skrip sandaran sendiri boleh mencetuskan pemadaman?#

Inilah bahagian paling rumit, dan ramai yang cuba melindungi data sendiri terperangkap dengannya. Pembersihan melihat mtime, iaitu cap masa terakhir fail diubah suai. Ia menganggap mtime mencerminkan kali terakhir anda bekerja dalam sesi tersebut. Dalam praktiknya, apa-apa sahaja boleh mengubah mtime: klien penyegerakan Dropbox atau iCloud, rsync, perisian antivirus, pengindeks atau skrip sandaran anda sendiri.

Inilah perangkapnya. Anda memutuskan untuk menyimpan sejarah dan menyediakan penyegerakan awan untuk ~/.claude/projects/. Pada suatu masa, perkhidmatan penyegerakan menulis semula fail dan menetapkan mtime-nya kepada tarikh yang lebih awal (ini boleh berlaku apabila memulihkan salinan daripada awan). Claude Code melihat fail “lama” semasa permulaan lalu memadamkannya. Anda mahu menyimpannya, tetapi anda mempercepatkan pemadamannya.

Kesimpulannya hanya satu: sandaran mesti berada di luar ~/.claude/projects/. Pembersihan hanya berfungsi di dalam folder ini. Salinan yang disimpan di luarnya berada di luar jangkauan pembersihan. Saya akan membina penyelesaian berdasarkan prinsip ini.

Bagaimanakah anda boleh menghentikan pemadaman sejarah sekarang?#

Hentikan pemadaman dalam tiga langkah:

1. Buka fail tetapan: ~/.claude/settings.json (jika fail itu tiada, cipta fail tersebut).
2. Tambahkan tetapan cleanupPeriodDays dengan nilai yang besar:

{
  "cleanupPeriodDays": 3650
}

3. Simpan fail itu. Tetapan akan berkuat kuasa apabila Claude Code dimulakan seterusnya.

Nilai 3650 bermaksud sepuluh tahun: dalam praktiknya, pemadaman tidak akan berlaku lagi. Jika anda mahu mengekalkan pembersihan tetapi memberikan lebih banyak masa, tetapkan kepada 365 (satu tahun); selepas itu hanya sesi yang lebih lama daripada setahun akan hilang. Anda boleh menyemak sama ada tetapan telah digunakan dengan arahan ini:

grep cleanupPeriodDays ~/.claude/settings.json

Satu perkara yang mudah terlepas pandang: memanjangkan tempoh TIDAK memulihkan perkara yang telah dipadam. Pembersihan dijalankan semasa permulaan dan semua yang dipadam dalam larian terdahulu hilang selama-lamanya. Sebab itulah anda patut menetapkan ini dahulu—ia mencegah kehilangan pada masa depan tetapi tidak mengembalikan perkara yang sudah dipadam. Jika anda mahu mengelakkan kehilangan sejarah Claude Code serta projek anda akibat arahan yang tidak disengajakan, lihat panduan “Cara Mengkonfigurasi Claude Code Supaya Tidak Merosakkan Projek Anda”.

Sejarah sesi ialah sebahagian daripada otak kedua projek anda: ia mengandungi logik keputusan yang tidak direkodkan di tempat lain. cleanupPeriodDays menyimpan fail, tetapi tidak menjadikannya sistem yang membolehkan anda mendapatkan semula perkara yang diperlukan enam bulan dari sekarang.

Bagaimanakah anda mengarkib sejarah secara automatik di luar folder pembersihan?#

Caranya mudah: biarkan Claude Code mengurus foldernya mengikut kehendaknya, sementara anda menyimpan arkib berasingan di luarnya. Arkib dilindungi daripada mekanisme pembersihan itu, tetapi masih boleh hilang akibat kegagalan cakera, pemadaman tidak sengaja atau salinan gagal. Sediakannya begini:

1. Cipta folder arkib di luar direktori terurus:

mkdir -p ~/claude-history-archive

2. Salin sejarah semasa anda ke sana. Bendera -a mengekalkan struktur dan cap masa; --ignore-existing membiarkan fail yang telah disalin tidak berubah:

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

3. Automatikkan proses supaya berjalan sekali sehari. Pada macOS, gunakan launchd. Cipta fail ~/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. Muatkan ejen supaya ia berjalan di latar belakang:

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

Di Linux, perkara yang sama dilakukan dengan satu baris dalam crontab (crontab -e):

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

Mengapa cara ini berfungsi sedangkan penyegerakan daripada bahagian sebelumnya gagal? Arkib berada DI LUAR ~/.claude/projects/, jadi pembersihan langsung tidak dapat melihatnya. Penyalinan berlaku dalam satu arah (daripada folder aktif ke arkib) dan kami tidak mengubah mtime fail aktif—maka pepijat mtime tidak berlaku. Walaupun Claude Code memadam sesi daripada foldernya sendiri esok, salinannya akan kekal dalam arkib.

Bagaimanakah anda boleh menjadikan arkib sesi sebagai otak kedua yang boleh dicari?#

Mengumpulkan fail sahaja tidak mencukupi—anda perlu dapat mengaksesnya. Dua langkah menjadikan arkib alat yang berfungsi.

Pertama, kawal versinya dengan git. Mulakan repositori dalam folder arkib:

cd ~/claude-history-archive
git init
git add -A && git commit -m "First snapshot of Claude Code history"

Tambahkan git add -A && git commit pada larian harian yang sama dengan rsync. Kini anda mempunyai sejarah versi: anda boleh melihat perkara yang muncul dan bila, serta membatalkan penindihan yang tidak disengajakan dengan satu arahan.

Kedua, lakukan carian. Fail .jsonl ialah JSON yang dipisahkan mengikut baris, jadi anda boleh menggunakan alat yang biasa digunakan. Cari sesi yang membincangkan topik tertentu:

grep -rl "database migration" ~/claude-history-archive/

Ekstrak teks arahan anda sahaja daripada sesi (menggunakan jq kerana kandungannya ialah JSON):

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

Pada ketika ini, sejarah sesi anda mula berfungsi sebagai otak kedua projek: pangkalan data yang membolehkan anda mendapatkan semula “bagaimana kita membuat keputusan ini pada bulan Mac” dalam beberapa saat. Untuk penerangan berasingan tentang lokasi konteks dalam sesi dan cara menguruskannya, lihat “Ke Mana Perginya Token dalam Claude Code”.

Bolehkah sesi yang telah dipadam dipulihkan?#

Jawapan yang jujur: mungkin tidak. Claude Code tidak mempunyai ciri pemulihan, Sampah atau log untuk membatalkan pemadaman transkrip. Fail itu lenyap begitu sahaja daripada cakera.

Ada satu pilihan: sandaran sistem, jika telah didayakan lebih awal:

1. macOS Time Machine—jika syot kilat menangkap ~/.claude/projects/ sebelum pemadaman, anda boleh mendapatkan semula fail daripada sandaran pada tarikh yang diperlukan.
2. Sejarah versi OneDrive / Dropbox—jika folder disegerakkan dengan pengversian didayakan, cari fail dalam sejarah versi awan (tetapi ingat perangkap mtime: penyegerakan juga mungkin telah mencetuskan pemadaman).
3. Salinan manual—sebarang arahan rsync/cp yang anda jalankan secara manual untuk menyalin ke lokasi di luar folder terurus.

Jika tiada satu pun wujud, sesi itu sudah hilang. Dan ini bukan perkara luar biasa: seorang pengarang pepijat dalam repositori Anthropic mendapati 26 daripada 38 rekod rosak, mewakili kerja selama berbulan-bulan. Satu-satunya perlindungan yang boleh diharap ialah perlindungan yang tersedia SEBELUM kehilangan berlaku. Tetapkan cleanupPeriodDays dan pengarkiban automatik hari ini, sementara masih ada sesuatu yang boleh disimpan.

Apakah nilai yang patut dipilih untuk cleanupPeriodDays?#

Hanya ada satu tetapan, tetapi ia boleh membawa beberapa maksud. Bandingkan pilihan dan pilih yang sesuai dengan kegunaan anda:

Peringatan keselamatan penting: jika anda menetapkan 3650 dan menyimpan semuanya, anda bersetuju menyimpan transkrip yang mungkin mengandungi kunci dan kod pada cakera. Ini ialah pertukaran yang disengajakan: kemudahan arkib berbanding risiko. Kurangkan risiko: simpan arkib pada cakera yang disulitkan (FileVault pada macOS), jangan letakkannya dalam awan awam dan jangan masukkannya ke repositori git awam. Saya telah menyediakan panduan berasingan tentang data yang mungkin bocor melalui Claude Code: “Keselamatan Data dalam Claude Code”.

Perkara yang perlu dilakukan hari ini: senarai semak#

Sediakan perlindungan langkah demi langkah:

1. Tetapkan cleanupPeriodDays: 3650 dalam ~/.claude/settings.json—anda telah menghentikan pemadaman.
2. Cipta ~/claude-history-archive di luar folder terurus dan jalankan rsync -a buat kali pertama.
3. Jadualkan larian harian menggunakan launchd (macOS) atau cron (Linux).
4. Mulakan git dalam arkib dan tambahkan git add -A && git commit pada larian yang sama.
5. Pastikan arkib berada pada cakera yang disulitkan dan tidak disegerakkan ke awan awam.
6. Periksa setiap pelaksanaan berjadual untuk salinan berjaya, kemudian periksa sesi arkib terkini dan pulihkan sampel secara berkala ke folder sementara berasingan bagi memastikan ia boleh dibaca.
7. Jika kehilangan peranti atau cakera termasuk dalam skop, simpan sandaran bebas dengan kawalan akses yang sesuai dan uji pemulihannya juga. Sejarah Git pada cakera sama bukan sandaran bebas.

Sejarah sesi hanyalah satu lapisan konteks yang menjadikan Claude boleh diharap.

Kenali Ailoot.