最近，我用 AI Agent 做项目，做着做着就报错了硬盘已满。
Wait, Wait, Wait。我这512G的盘才用了一个月不到啊。
顺着占用往下查，一个平时看不见的目录引起了我的注意：.mimosa。在一次测量中，它占用了约 334 GiB。
这里的 GiB 是电脑常用的二进制容量单位。你可以先把它理解成“约 334 GB 这个量级”，不用被单位劝退。
这次排查发生在 2026 年 11 月 6 日。我在 Mac 上使用外置硬盘，借助 Codex 检查项目；工作区里也有 Mimosa 安全插件留下的运行数据。
几组数字分别来自不同时间、不同范围：
| 看到的情况 | 当时的记录 |
|---|---|
| 清理前一次测量 | 工作区根目录 .mimosa 约 334 GiB |
| 一轮历史记录清理前后 | 整块外置盘可用空间约从 7.7 GiB 增至 130 GiB |
| 随后再次测量 | 根目录 .mimosa 仍约 203 GiB |
这几组数字不能直接互减：左边是一个目录，右边是整块磁盘，而且测量时刻不同。清理中，较新的会话及关联记录被保留；剩下的 203 GiB 也不能直接认定全是垃圾。
这次清理没有报告操作错误，但我没有对所有历史会话逐一做恢复测试，因此也不能声称它对所有旧会话都“零影响”。
这篇文章要解决的不是“教你一键删掉它”，而是帮你弄清：它为什么存在、什么时候会变大、普通人怎么判断和处理。
01 先认人：.mimosa 到底是什么？
先说一个最容易误会的地方：
.mimosa 不是所有 Agent 都会生成的“通用聊天记录”。
在这次案例里，.mimosa 与 Mimosa 代码安全插件有关。它可以在 AI 准备修改代码、任务收尾或提交代码时做安全检查，并在项目中保存运行状态。官方说明介绍了它与 ZCode 的集成；插件载荷文档也提到其他支持相关能力的宿主。装了什么插件、启用了什么功能，比使用哪个大模型的名字更关键。 Mimosa 官方说明、载荷说明
文件名前面的 .，在 macOS 和 Linux 中通常意味着它是隐藏目录。隐藏只是为了减少日常界面里的干扰，既不表示它有问题，也不表示里面的东西可以随便删。
如果把 AI 编程想成装修，Mimosa 有点像旁边的安全检查员：
- 开工前，先留一份需要对照的现场记录。
- Agent 修改时，检查部分高风险操作。
- 任务收尾时，对照修改前后的差异，生成检查结果。
- 为了后续查看、追踪和重试，部分状态与报告会留下来。
它不是在给整个电脑做备份，也不能替代 Git、网盘或移动硬盘备份。
02 里面装的是什么：有“草稿”，也有“档案”
这次打开目录后，能看到的不只是一类文件。
| 常见名称 | 可以先这样理解 | 处理提醒 |
|---|---|---|
hook-state | 检查过程中的会话状态，以及一些基线快照 | 大小可能很可观；先确认会话和版本 |
*.baseline、其中的 .source | 用于对照修改的基线目录和文件快照 | 可能包含项目源码或配置内容 |
hook-status | 检查状态等信息 | 不要在工具运行时随意改动 |
history、reports、finding-ledger | 历史、报告或安全发现相关记录 | 可能有审计、排障或追踪价值 |
security-policy.json（如果存在） | 项目使用的安全策略 | 可能是团队需要保留的配置 |
实际目录和格式可能随版本、宿主、项目而变化；表格只是理解方向，不是一份“照表删除”清单。
尤其要注意 .source：它可能包含代码快照。如果代码或配置本身含有敏感信息，截图、打包、上传或求助时都有泄露风险。官方文档同时说明，项目外的用户数据目录也可能保存持久扫描历史，不能只盯住一个文件夹。 Mimosa 官方说明
03 为什么会越积越多？
这里有三件事叠在一起。
第一层：安全检查需要“修改前”
要知道 Agent 改了什么，检查工具需要一个对照。Mimosa 载荷文档描述：提交请求时保存源码基线，任务结束时用它与当前文件比较，再复查变化。 Mimosa 载荷说明
因此，出现基线文件本身是有用途的。项目文件越多、任务和并行会话越多，产生的数据也可能更多；具体增长速度取决于工具实现、任务和文件系统。
第二层：有回收设计，不等于所有历史都会消失
查资料时，我发现一个需要讲准确的细节：
- 官方文档写到，任务收尾时，相关报告和历史成功落盘后，会清理对应基线。
- 遇到扫描、报告或进程异常时，基线可能被保留，以便后续重试。
- 历史报告和安全发现记录本身也有保留用途，不等同于这一次基线。
也就是说，不能简单断言“它从来不清理”。另一方面，有部分自动清理，也不代表所有场景都能稳定回收。
在 ZCode 插件仓库的一个公开反馈中，一位用户报告：Mimosa 1.0.4 的 hook-state 在约 33 天内积累了约 24 GB、182 万个文件。那是另一位用户针对特定版本和使用环境的报告，不是所有人的结果，也不能据此确定我这里的增长原因。 公开反馈 #152
截至我查阅的官方说明和这份反馈，没有找到可直接用于批量清理旧 hook-state 基线的官方保留期设置或清理命令。官方文档里的 ledger prune 针对的是另一类安全记录，且文档注明当时仅支持预览，不能把它当成基线清理按钮。软件更新后请以自己安装版本的文档为准。 载荷说明：CLI 与行为细节
第三层：小文件多，磁盘占用可能被放大
我还抽查了本机一个 .source 文件：
- 文件内容大小：23 字节。
- 系统报告实际分配空间：131,072 字节，也就是 128 KiB。
可以把它想成租储物柜：只放一张纸，柜子也不会缩成一张纸的大小。文件系统分配空间有自己的单位和规则，很多小文件各占一份空间时，累计占用可能远超文件内容相加的大小。
这个样本用 Python 的 os.stat() 读取：文件大小取 st_size，系统报告的分配空间取 st_blocks × 512。
这只是我的外置盘上的一个抽样，不是所有硬盘都会按 128 KiB 分配，也不能用这一个样本算出全部占用的原因。本机还有多少空间来自快照内容、多少来自小文件分配开销，这次没有完整拆算。
04 会话归档了，为什么硬盘不一定变空？
“归档”这个词很容易让人以为“已经清理好了”。但在 Agent 工作中，它可能指好几件不同的事。
| 你做的事 | 它主要处理什么 | 是否必然清掉 .mimosa？ |
|---|---|---|
| 在 Agent 界面归档会话 | 整理侧边栏，方便以后查找 | 不一定 |
| 在 Agent 界面删除会话 | 按该产品规则处理聊天记录 | 不一定 |
| 把作品移到其他磁盘 | 转移准备长期保存的成果 | 确认转移后删除原件，才可能释放原盘空间 |
| 清理插件运行数据 | 处理插件自己的状态、快照或历史 | 取决于具体插件和所选内容 |
例如，Codex 对会话的归档是整理聊天列表，会话仍可查找；它不等于替第三方插件回收项目目录。 OpenAI Developers：管理 Codex 会话
另一个例子是 Claude Code：官方提供 cleanupPeriodDays 来管理会话记录等应用数据的保留期；文档所列默认值为 30 天，特定桌面会话还有例外。这不是 .mimosa 的清理开关。 Claude Code 设置说明
记住这句话就够了：聊天、项目成果、插件状态，是不同的账本，要分别确认。
05 普通人先做什么？先看盘，再找目录
Mac：不用终端也能检查
- 点左上角苹果菜单 → 系统设置 → 通用 → 储存空间，查看 Mac 内置盘。
- 如果项目在外置盘，打开访达，选中侧边栏里的外置盘，按
Command + I，查看容量和可用空间。 - 打开你的项目文件夹，按
Command + Shift + .，切换显示或隐藏以点开头的文件。 - 找到
.mimosa后选中它，按Command + I。文件很多时，计算大小可能要等一会儿。
不确定项目在哪里？先看 AI 编程工具打开的是哪个工作区；有些项目各有自己的 .mimosa，根目录也可能有一份。
如果外置盘上还看到 ._.mimosa，它通常是 macOS 在某些文件系统上保存的配套元数据，不是同一个 .mimosa 目录。不要仅凭名字批量删除。 Apple：文件与 Finder 元数据
Apple：释放 Mac 储存空间 ｜ Apple：查看外置磁盘信息
Windows：看空间和隐藏项目
- 打开 设置 → 系统 → 存储，查看系统盘占用；外置盘或其他盘也可在“此电脑”中查看。
- 打开项目所在文件夹。在 Windows 11 文件资源管理器中，点 查看 → 显示 → 隐藏的项目。
- 找到
.mimosa后右键查看属性；若项目内没有，也可以检查上一级实际工作区。
Windows 的“存储感知”可以帮忙管理部分系统临时文件，但它不是 Mimosa 专用清理工具；它主要管理系统驱动器，不能指望它自动清理外置盘或 .mimosa。 Microsoft：存储感知 ｜ Microsoft：文件资源管理器
想看得更精确：两条只读命令
如果你愿意在 Mac 或 Linux 上使用终端，可以先输入 cd （注意后面有一个空格），把项目文件夹拖到终端窗口，按回车。再运行：
# 当前项目所在磁盘还有多少空间
df -h .
# 这个项目下的 .mimosa 占用了多少空间
du -sh .mimosa
这两条命令只查看，不删除。df 看的是所在磁盘，du 看的是指定目录；没有 .mimosa 时，第二条会提示找不到目录。
文件特别多时，du 可能运行很久。本次完整统计就用了几分钟；如果不想等，按 Control + C 可以停止这次统计。
06 真要清理，怎么做才有把握？
我的建议是：先停、再分、先核对、后删除。
第一步：先停下相关工作
把这个工作区中仍在跑的 Agent 任务正常结束，并确认没有其他窗口、后台工作流或团队成员还在使用同一份目录。只关掉一个聊天窗口，不一定代表所有后台任务都结束了。
如果是共享目录、公司项目，或者有合规审计要求，先按团队的数据保留要求处理。
第二步：先给重要东西留退路
把需要的项目成果、审计报告和可能还要恢复的记录备份到另一块有足够空间的位置，确认能打开。
备份也可能包含源码或敏感信息，应存到可信的位置。单纯在同一块满盘里复制一份，通常不会帮你腾空间。
第三步：只处理能确认归属的候选项
先看插件有没有适用于当前版本、当前数据类型的官方清理功能；有的话优先按官方步骤操作。
如果没有，可以从 hook-state 中检查旧的 .baseline 目录，但要同时满足这些条件，才把它列为人工处理候选：
- 能确认它关联的会话或工作流已经结束，之后不需要恢复或继续检查。
- 能确认它不属于仍在运行或等待重试的任务。
- 需要保留的内容已经有可靠备份，自己也接受可能失去相关恢复或排障能力。
只看到“七天前修改”，还不够。 父目录的修改时间不能可靠代表所有子文件的最新状态；会话也可能暂时没活动，之后再继续。如果看不懂关联关系，就先保留，或者请熟悉该插件的人协助。
第四步：人工检查后，再移动或删除
对已经确认的具体候选目录，可以在访达或文件资源管理器里逐项移到废纸篓／回收站。注意系统提示：某些外置设备或设置下，删除可能直接生效、无法从回收站恢复。
重新打开工具，检查项目和必要的安全状态是否正常。如果发现异常，先停止相关任务，再把候选目录从废纸篓或备份还原到原路径；若原位置已生成新数据，先核对再恢复，避免覆盖。确认不需要恢复后，再清倒对应废纸篓／回收站，并重新查看磁盘空间。
不要直接删除整个 .mimosa，也不要照搬网上“一键删除七天前所有文件”的命令。时间适合用来排查，不足以单独证明安全。
这次我自己的操作，是让 Agent 按当时能核实的会话关系保留近期活动组，再处理部分历史记录；它是一份经历，不是可无差别复制的删除规则。
如果你也想让 Agent 帮忙，先这样说
下面这段可以直接复制，把方括号改成你的实际情况：
请只读检查 [项目文件夹] 的磁盘占用，重点查看其中的 .mimosa。
先不要移动、删除或修改任何文件，也不要关闭安全插件。
请列出：
1. 该磁盘的可用空间，以及 .mimosa 和主要子目录的占用；
2. 可能与已结束会话有关的旧基线，以及你判断归属的证据；
3. 无法确认用途、仍可能运行、需要重试或需要保留的内容；
4. 每个候选项的具体路径、最新活动依据、预计影响和恢复方式。
请提醒我先检查备份。等我逐项审阅清单后，再讨论是否清理。
它的作用是让 Agent 先交一份可检查的清单。Agent 说“可以删除”，也仍要核对证据；无法确认的项目继续保留。
07 怎么防止下次又堆满？
不需要先搭一个复杂的自动清理系统。我现在会从一套小习惯开始：
每周或每月选一个固定时间：
- 看空间：项目所在盘还有多少可用容量？外置盘也要单独看。
- 找大户：工作区里的
.mimosa、依赖、下载和导出文件，谁在增长？ - 留成果：源码、最终文档、实验数据和需要审计的报告，按用途备份。
- 清候选：只处理确认完成、确认不再需要、且已经考虑恢复方式的内容。
- 再复测：记录前后容量；确认工具能正常使用。
如果盘快满了，优先清理自己确定不再需要的大型下载、重复导出或已备份的安装包；不要为了腾空间，先去关掉安全检查，或者对未知目录执行批量删除。
长期来看，更理想的 Agent 工具应该让用户看见：哪些数据是谁创建的、是否仍被使用、占了多少、何时可以安全回收，以及删除后会失去什么。自动清理要配合明确的保留期、预览、恢复和失败处理，而不是定时把旧文件一股脑删掉。
这次经历让我记住了一件事：Agent 的工作速度可以很快，但它在硬盘上留下的“工作现场”，也需要有人定期盘点。
如果你也遇到过 Agent 用久后磁盘空间悄悄减少，最占空间的是哪一类文件？你会如何在“留着以后能查”和“及时回收空间”之间做选择？
