返回博客列表

Gemini CLI 误删 Home 目录：cd 失败 + find -delete 的事故与恢复

2026年3月13日 | Ruichen Zhou | 约 7 分钟阅读
Gemini CLI 灾难恢复 macOS

系列文章：本文是「Gemini 灾难恢复」系列的第 1 篇。

  1. Gemini CLI 误删 Home 目录：cd 失败 + find -delete 的事故与恢复（本文）
  2. Dotfiles 统一管理：11 台跨平台设备的 symlink + Git 方案
  3. macOS 灾后状态恢复：Keychain 重建、Syncthing 重配对、OneDrive 冲突处理

本文记录一次 Gemini CLI 误删 Home 目录的事故，包括事故触发过程、根因分析、损失范围和恢复步骤。环境是 macOS，设备是 MacBook Air，使用的工具是 Gemini CLI。

事故经过与根因

当时我想整理课件文件夹，让 Gemini CLI 帮我把一些子目录按学期归类，并删除重复的 PDF。

它给出了一组命令：先 cd 到目标目录，再用 find 按条件匹配，最后通过 -delete 清理。我检查后认为逻辑成立，于是执行了。

问题出在目标目录实际上不存在。原因可能是路径写错，也可能是该目录之前已经被我移动了。关键点在于：shell 里的 cd 失败并不会自动中止后续命令，因此后面的 find ... -delete 仍然继续执行。

而这条 find ... -delete 执行时的当前目录是 ~/，也就是 Home 目录。

这次事故的根因链条很直接：

  1. cd 目标目录失败。
  2. shell 没有因为 cd 失败而停止执行。
  3. 后续 find ... -delete 从当前目录 ~/ 开始运行。
  4. find -delete 在我中断之前已经删除了大量文件。

我看到终端持续输出被删除的文件路径后，立刻按了 Ctrl+C，但 find -delete 的执行速度很快，中断时已经造成了较大范围的删除。

受损范围

事故发生后，问题是逐项暴露出来的。

首先是终端工具失效。exa、bat、fd 等命令开始报 command not found，或者提示 symlink 指向的目标不存在。很多通过 Homebrew 安装的 CLI 工具是通过软链接暴露到 PATH 里的，目标文件被删掉后，链接就变成了死链。

接着是 Git 仓库损坏。多个仓库的 .git 目录内对象文件被部分删除，git status 直接报 fatal，仓库处于半损坏状态，既不能正常 commit，也不能 checkout。

系统字体也受到了影响。之前安装的 JetBrains Mono、Noto Sans CJK 等字体被删除后，系统界面部分位置开始回退到默认字体，某些地方甚至出现方块字形。

输入法配置同样丢失。~/Library/Rime 下的配置文件被删空后，鼠须管无法正常工作，候选框不再弹出，输入法基本不可用。

微信聊天记录也丢了。对应数据库位于 ~/Library/Containers 下，被误删后，对话列表变为空，聊天记录、发送过的图片和收藏文件一并消失。

Keychain 被清空后，系统开始频繁要求重新登录。Apple ID 自动退出，iCloud 同步中断，依赖 Keychain 凭证的服务都需要重新认证。

最后，桌面壁纸也恢复成了 macOS 默认设置。这不是关键损失，但说明用户级配置已经被广泛影响。

恢复过程

确认损失范围后，我改用 Claude Code 辅助逐项恢复。

Dotfiles 是最先恢复的部分。因为 dotfiles 仓库仍然在 GitHub 上，我重新 clone 仓库并重新执行 symlink 脚本，.zshrc、.gitconfig 以及 .config/ 下的大部分配置都恢复了。这次事故也验证了维护 dotfiles 仓库的实际价值。

Homebrew 相关内容随后恢复。Homebrew 本体没有损坏，问题主要在于它管理的 symlink 和 Cask 安装资源被删除，因此只需要重新安装相应软件和字体即可，例如 brew install --cask font-jetbrains-mono、brew install --cask font-noto-sans-cjk，以及重新安装 exa、bat、fd、ripgrep、lazygit 等工具。

Rime 输入法通过 rime-auto-deploy 重新部署了雾凇拼音。由于 default.custom.yaml 和 squirrel.custom.yaml 之前也保存在 dotfiles 里，我直接把它们重新 symlink 回去，再重新部署，输入法就恢复可用。

SSH keys 从备份中恢复。我的私钥之前备份在加密的外置硬盘里，因此恢复后 GitHub 和服务器的 SSH 连接可以重新正常使用。

Keychain、Syncthing 和 OneDrive 这几部分的恢复明显更难，因为它们丢掉的不是静态配置，而是登录态、设备证书和同步状态。比如 Syncthing 的节点证书丢失后，其他 10 台设备把 air 识别为未知设备，只能逐台重新接受配对，这也是恢复过程中最耗时的一步。这三项的详细恢复过程在第二篇恢复记录里单独展开。

无法恢复的内容

大部分系统级工具和配置都可以重装或通过备份恢复，但以下内容无法找回。

微信聊天记录没有做过本地备份，也没有使用过迁移功能。数据库文件删除后，这部分历史对话、图片和资料就彻底丢失了。

一些本地临时脚本和笔记也没有恢复。这些内容平时散落在 ~/scripts/ 和 ~/notes/ 之类的目录里，没有进入 Git 仓库，也没有同步到其他地方，因此删除后没有可用副本。

Keychain 中少量只保存在本机的密码同样丢失。大部分账号密码在 1Password 里有备份，但一些本地服务凭证和少量 Wi-Fi 密码只存在 macOS Keychain 中，只能在后续使用时重新设置。

结论

这次事故本质上是一个典型的命令执行上下文错误：cd 失败没有阻止后续命令，而 find -delete 又是在 ~/ 下执行，最终把 Home 目录当成了清理目标。恢复工作本身可控，但前提是重要配置、密钥和工具安装路径已经有备份。

之后我重新整理了 dotfiles 仓库，也给 ~/Library 下的关键目录增加了额外备份。以后无论是自己写命令还是让 AI 工具生成命令，只要涉及删除操作，都会先做 dry-run，例如先用 find ... -print 确认目标范围，再决定是否执行 -delete。

评论