一个开发者最怕的，不一定是代码没了。

代码通常还有 Git。真正麻烦的是那条“为什么这么写”的路没了：设计取舍、调试岔路、失败实验、模型帮你排过的坑。GitHub 上 anthropics/claude-code #62476 这条 bug issue，刺中的正是这个点。

报告者称，Claude Code 的 cleanupPeriodDays 默认值是 30。用户如果没有改配置，工具启动时可能会静默删除 ~/.claude/projects/*.jsonl 里超过 30 天的本地项目 conversation transcript。

没有首次告知。没有删除前确认。/config 里也看不到这个设置。

边界也要先说清：这不是删代码仓库，不是删 Git 历史，也不是账户数据消失。它指向的是 Claude Code 本地项目 transcript jsonl。可对重度用户来说，这未必只是“日志”。

这条 issue 说了什么

项目信息
Issueanthropics/claude-code #62476
状态Open，带 bug 标签
报告时间May 26, 2026
触发条件使用超过 30 天，且未覆盖 cleanupPeriodDays 默认值
默认值cleanupPeriodDays: 30
删除对象~/.claude/projects/*.jsonl 本地项目 transcript
不涉及代码仓库、Git 历史、账户数据
临时办法在 ~/.claude/settings.json 设置更长周期，如 "cleanupPeriodDays": 3650

报告者给出的证据很具体：~/.claude/history.jsonl 里还能看到某项目 3 到 4 月的 14 个 session、1315 条 prompts，但 ~/.claude/projects/ 下只剩当前 session 的 jsonl。缺口正好卡在 30 天默认值附近。

他的诉求也不复杂：关闭默认自动删除；首次运行时披露；删除前确认；软删除到 trash；把设置暴露在 /config。

这些要求不像高级功能。更像软件处理用户资产时的最低礼貌。

目前材料里看不到 Anthropic 官方回应证据。issue 标题里有 “won't fix”，但不能据此断言官方已经拒绝修复。现在能确定的，是报告者提出了这个问题，issue 仍标为 bug。

谁最该立刻检查

最相关的是两类人。

一类是 Claude Code 重度用户，尤其是一个项目聊了几周、几个月的人。你以为本地 transcript 是工作档案，默认策略可能把它当过期文件。现在最现实的动作，是检查 ~/.claude/settings.json，显式设置 cleanupPeriodDays，再备份 ~/.claude/projects/。

另一类是把 AI 对话当研究笔记、调试记录、长期项目管理入口的人。你需要把关键结论落到 repo、文档、issue 或笔记系统里。不要只把长期上下文押在工具自己的 transcript 里。

使用方式这件事的影响该做什么
偶尔用 Claude Code 写小脚本影响可能有限知道边界即可，必要时改配置
长期项目依赖对话追踪可能丢失数月推理上下文设置 cleanupPeriodDays，备份 projects jsonl
团队把 AI 对话当知识库风险更高，责任边界不清暂缓把 transcript 当唯一档案，建立外部归档
企业采购或试点不是立刻迁移理由，但会影响信任评估要求 retention、导出、删除确认、审计说明

这里的现实约束也要说透：不是所有用户都会丢数据。只有在未覆盖默认 cleanupPeriodDays、并且本地项目 transcript 超过 30 天的情况下，才可能触发这类问题。

也没有证据说明被清理的 transcript 一定无法通过其他备份恢复。能不能恢复，取决于本机备份、同步工具、文件系统快照，以及用户自己的归档习惯。

但这并不能把问题洗成“小概率”。开发者工具的默认值，一旦碰到工作资产，就不能只按“多数时候没事”来设计。

transcript 不是普通日志

很多产品团队会把 transcript 当日志。日志过期清理，节省空间，减少噪音，看上去合理。

AI 编程工具里的 transcript 不一样。它承载的是工作过程本身。

一个长期项目里，开发者问过什么，模型误判过什么，某个架构为什么被放弃，某个 bug 是怎么一路缩小范围的，这些都不一定会进代码注释，也不一定会进 commit message。

它们常常只留在对话里。

对研究、调试、长期项目管理的人来说，这些对话不是边角料，而是半成品知识库。删掉它，代码还在，但上下文断了。案卷还在，口供没了。

这里最反常的不是 30 天这个数字，而是“静默”。

默认清理可以讨论。30 天是否太短也可以讨论。但破坏性操作默认开启、启动时自动执行、用户事前不知道、事后难恢复，这几件事叠在一起，性质就变了。

轻一点说，这是默认值太粗。重一点说，这是产品没有把用户的推理过程当资产。

接下来该看什么

我更在意的不是这个 issue 最后会不会多一个配置项。更大的问题是：AI 编程工具到底把什么算作“用户资产”。

传统 IDE 时代，源代码、配置、项目文件是资产；缓存、索引、临时日志可以清。到了 AI 编程时代，对话链条开始变成生产资料。模型参与推理、试错和决策，那条链条就不该轻易进垃圾桶。

“天下熙熙，皆为利来。”放在这里不玄。默认值背后有产品激励：本地目录更轻，清理逻辑更简单，用户界面更干净。代价往往落到三个月后回来追旧项目的人身上。

这不等于 Claude Code 删了用户代码，也不该夸张成账户事故。它更像一个小口子，露出 AI 工具产品化时的老问题：产品想替用户省心，结果替用户做主。

接下来最该观察三件事。

观察变量为什么重要
Anthropic 是否明确回应 #62476决定这是个待修 bug，还是被接受的产品策略
是否把 cleanupPeriodDays 暴露到 /config用户能否发现并控制 retention
是否增加确认、trash 或导出机制破坏性操作是否被降级为可恢复操作

这三项比口头解释重要。开发者工具靠可预期性吃饭，不靠“相信我”。

默认破坏性操作应该 opt-in。尤其在开发者工具里。

开发者不是不能接受清理。开发者最不能接受的是不被告知。你可以给保留周期，可以提示磁盘占用，可以问要不要归档。别悄悄替用户决定什么不重要。

Claude Code 这次暴露的，不只是一个 cleanupPeriodDays。它至少提醒所有 AI 编程工具：当模型越来越像同事，产品就不能再把它留下的工作痕迹当浏览器缓存。

开头那个问题也就回来了：开发者怕什么没了？

不是代码。是把代码写出来的那条路。