1. 为什么要写这份 OpenClaw 卸载指南
OpenClaw 这类个人 AI 助理，在安装阶段通常把“低门槛”放在第一位，一条 npm 命令、一个 Docker run 就能把整套服务拉起来。但问题也恰恰出在这里：它不是一个只放到目录里的普通程序，而是会把配置文件、会话快照、消息平台授权、定时任务、开机自启这些状态分散到系统的不同位置。卸载时如果只删掉主程序目录，剩下的状态文件不仅继续占磁盘，还可能让系统在重启时反复尝试拉起一个已经不存在的服务。
我最早帮朋友处理一台测试服务器时，遇到的现象很典型：明明执行过 npm 卸载，但登录终端还是提示 openclaw command not found，某个端口也还在监听。查到最后发现是 shell 的命令缓存、遗留的 systemd 服务、还有一堆~/.openclaw下的锁文件和会话记录没清。所以“完整卸载 OpenClaw”这件事，本质上不是删文件夹，而是要把程序本体、命令入口、配置、日志、会话、自启、授权全部按清单拆干净。
这篇文章会按实际卸载顺序来写。无论你当初是用 npm 全局安装、Docker 部署，还是源码方式跑的 OpenClaw，都能照着操作一遍。里面的关键命令我都标注了“为什么这么做”，不只是给结论。
1.1 OpenClaw 装到你机器上的三个常见姿势
OpenClaw 的安装方式直接决定了你该重点清哪些位置。根据我在自己服务器和群里看到的情况，主要分三种：
- npm 全局安装：最常见，一条
npm install -g openclaw之后，终端里直接出现openclaw命令。它会把可执行文件软链到/usr/local/bin或/usr/bin，真正的包文件放在 Node.js 的全局node_modules下。这类安装还需要额外清理 shell 缓存和 npm 痕迹。 - Docker 容器部署：隔离性最好，但如果创建时挂了数据卷，配置和会话数据会留在宿主机上，
docker rm只是删容器，并不会帮你删镜像、网络和卷。 - 源码 / Git Clone 手动跑：通常需要自己
npm install或者pnpm install，再通过node或全局软链启动。卸载时源码目录、依赖目录、软链和自动生成的配置文件都要分开处理。
另外还有一种容易被忽略的情况：用npx openclaw临时跑过。这种没有全局安装，但会在 npm 的_npx缓存目录里留一份完整副本，卸载时同样要清。
1.2 卸载前先确认这三个信息
在动手删任何东西之前，我会先做一轮“体检”，把 OpenClaw 到底装在哪个位置、有没有跑起来、有没有注册服务搞清楚。你可以直接复制下面这组命令：
which openclaw npm ls -g --depth=0 | grep -i openclaw docker ps -a --filter "name=openclaw" ps aux | grep -i openclaw systemctl list-units --all | grep -i openclaw systemctl --user list-units --all | grep -i openclaw输出结果会告诉你三件事：命令入口在哪、哪个安装方式在用、当前是否有进程和服务在跑。我建议把这些输出保存到一个临时文本里，后面清理完再回来对照，能避免误删同一个名字下的其他目录。注意一个细节：which openclaw找到的可能只是软链，别急着rm -rf它所在的整个/usr/local/bin，只删 openclaw 这个软链就够了。
2. 备份、停服、去自启：卸载前的黄金三步
很多人卸载软件的第一步就是rm -rf，但在 OpenClaw 身上我强烈不建议这么干。它的配置目录里存的不只是设置项，还有你写过的自动化脚本、会话历史、消息平台登录状态和自定义插件。这些数据一旦删掉，基本没有找回的可能。所以在我这里，备份和停服永远是先于删除的动作。
2.1 五分钟搞定数据备份
OpenClaw 的数据目录在不同系统上略有差异，但下面这几个是我实测最常见的位置：
mkdir -p ~/openclaw-backup tar -czf ~/openclaw-backup/openclaw-$(date +%Y%m%d).tar.gz \ -C ~ \ .openclaw \ .config/openclaw \ .local/share/openclaw \ .local/state/openclaw 2>/dev/null这条命令把用户目录下的 OpenClaw 相关配置和状态全部打包。如果某个目录不存在，tar 会提示但不会中断，结尾的2>/dev/null只是把“找不到目录”的抱怨压掉，不影响备份结果。如果你是在 macOS 上跑的，还需要额外看一下~/Library/Application Support/OpenClaw和~/Library/Logs/OpenClaw，这两个目录经常不在上面那几个路径里。
备份完看一眼 tar 包的大小。如果只有几十 KB，说明这台机器上 OpenClaw 基本是空跑；如果有几十 MB，那里面大概率塞了会话记录和插件依赖，按后续步骤删除时也要重点关注这些大目录。
2.2 把进程和服务先停稳
卸载前最忌讳的是“程序还在跑，你直接删文件”。在 Unix 系统上，文件即使被删掉，只要进程一直持有文件描述符，它依然可以继续写入，而且会留下大量半截状态。OpenClaw 在运行时会读写 session 文件，如果你强行删掉目录，轻则报错，重则让后续的进程无法创建新会话。
停服务的顺序是：先停用户级 service，再停系统级 service，最后兜底杀进程。
systemctl --user stop openclaw.service 2>/dev/null sudo systemctl stop openclaw.service 2>/dev/null pkill -f openclaw注意pkill -f openclaw是个比较宽泛的匹配，它会把命令行里含“openclaw”字符串的进程都结束。我建议执行完再跑一次ps aux | grep -i openclaw确认没有残留。如果还有，就用kill -9 <pid>强制结束，但这是最后手段，能不用尽量不用。
2.3 拔掉开机自启
OpenClaw 一旦被注册成守护进程，即使你删掉全部文件，重启后 systemd 也可能因为找不到可执行文件而反复报错，甚至触发 Restart 策略帮你把它拉起来。这一步要先禁用，再考虑删除 unit 文件。
systemctl --user disable --now openclaw.service 2>/dev/null sudo systemctl disable --now openclaw.service 2>/dev/null sudo rm -f /etc/systemd/system/openclaw.service rm -f ~/.config/systemd/user/openclaw.service systemctl daemon-reload systemctl --user daemon-reload先disable是因为它会把自启软链从multi-user.target.wants里移除，即使后面删除 unit 文件失败，系统也不会再在开机时尝试启动它。如果你用的是 macOS，对应操作是launchctl unload ~/Library/LaunchAgents/com.openclaw.plist，然后删掉这个 plist 文件。做完这些，自启层面就断了。
3. 按安装方式拆除 OpenClaw 本体
备份和停服都完成之后，才进入真正的“拆除”阶段。这个阶段的核心思路是：本体文件、全局命令、配置文件、数据卷四个维度分别清，不能混在一起删。
3.1 npm 全局安装型：一条命令加三次确认
如果你是用 npm 全局安装的，第一步当然是卸载 npm 包。但这里有个经常踩坑的点：官方文档里说的包名和你实际装的可能不是同一个。有的版本是openclaw，有的版本是@openclaw/cli。删错包名会出现“明明提示卸载成功，但openclaw命令还在”的诡异现象。
先确认包名：
npm ls -g --depth=0 | grep -i openclaw确认好之后按对应包名卸载：
npm uninstall -g openclaw # 或者 npm uninstall -g @openclaw/cli卸载完再跑which openclaw。如果还是有路径输出，多半是软链没被 npm 清掉，手动删：
rm -f /usr/local/bin/openclaw rm -f /usr/bin/openclaw hash -rhash -r是为了清空 shell 的命令路径缓存。很多人在删完命令后依然能执行openclaw，就是因为 bash/zsh 记住了旧路径。
3.2 Docker 容器型：镜像、容器、卷、网络一个都不能少
用 Docker 部署 OpenClaw 的情况，很多人觉得“我docker rm一下不就完了”，这是最大的误解。docker rm只会删掉容器的可写层，镜像、命名卷、自定义网络都还在宿主机上。其中命名卷通常是 OpenClaw 真正的数据盘，里面存着.openclaw目录的完整内容。
我先看一下当前有哪些相关对象：
docker ps -a --filter "name=openclaw" docker images | grep -i openclaw docker volume ls | grep -i openclaw docker network ls | grep -i openclaw然后把它们逐项清掉：
docker stop openclaw docker rm openclaw docker rmi <image-id> # 或者 docker image rm openclaw:tag docker volume rm <volume-name> docker network rm <network-name>如果你的 OpenClaw 是用docker compose拉起来的，那么进入 compose 文件所在的目录直接执行：
docker compose down --volumes --rmi all这条命令会把容器、网络、镜像和挂载卷一次性清掉。使用前请确认docker-compose.yml里没有写volumes: - /宿主机路径:/容器路径这种挂载方式，否则--volumes只会清掉匿名卷，宿主机目录里的数据仍需手动删除。
3.3 源码编译或 Git Clone 型：删源码还不够
源码型安装最隐蔽的坑是：你以为“删掉 clone 下来的目录就完事”，但如果你在安装时执行过npm link或ln -s把openclaw命令暴露到了全局，那个软链还留在系统里。即使源码目录没了，命令路径依然是坏的，shell 也会一直提示找不到。
先找到源码目录：
find /opt /home /srv -maxdepth 4 -type d -iname "*openclaw*" 2>/dev/null然后删除源码目录和依赖目录：
rm -rf ~/openclaw /opt/openclaw /srv/openclaw rm -rf node_modules如果你执行过npm link，记得反向操作：
npm rm -g openclaw unlink /usr/local/bin/openclaw源码型安装还有一个特点：很多插件数据会直接写在源码目录外的~/.openclaw下，所以下面的“通用隐藏目录清理”是必做项。
3.4 通用隐藏目录清理（Linux / macOS / Windows）
无论哪种安装方式，OpenClaw 都会往用户目录里写配置。这一步清的就是这些零散目录。Linux 和 macOS 上常见的路径包括：
rm -rf ~/.openclaw rm -rf ~/.config/openclaw rm -rf ~/.cache/openclaw rm -rf ~/.local/share/openclaw rm -rf ~/.local/state/openclawmacOS 还要看这些：
rm -rf ~/Library/Application\ Support/OpenClaw rm -rf ~/Library/Caches/OpenClaw rm -rf ~/Library/Logs/OpenClaw rm -rf ~/Library/Preferences/com.openclaw.plistWindows 用户如果是在本地安装的，重点看三大块：%APPDATA%\openclaw、%LOCALAPPDATA%\openclaw、%USERPROFILE%\.openclaw。我建议在cmd或 PowerShell 里逐条dir确认后再删，不要一个rmdir /s把整个 AppData 路径删了。
这里再说个安全提醒：rm -rf是终端里最危险的操作。我个人的习惯是先把这些目录统一挪到一个临时目录，比如mv ~/.openclaw ~/openclaw-trash/，确认系统一切正常后，再在一个小时后真正清空。多一步操作，能避免很多“删完才后悔”的情况。
4. 干掉幽灵进程和残留依赖
主程序删完之后，很多人以为可以收工了。但真正影响系统“干净度”的，往往是那些看不见的残留：还在监听的端口、npm 缓存里的副本、systemd 里加载的服务单元、shell 配置里写死的环境变量。这一步要把它们翻出来。
4.1 端口为什么还开着？先找进程再动手
有一种典型情况：openclaw命令已经删了，但某个端口还在监听。因为进程是在卸载前启动的，命令行里的可执行文件被删了，不代表进程内存里的代码会立刻消失。它甚至可以持续运行到下次重启。
先查看端口状态：
ss -tulpn | grep -i openclaw lsof -i :<port>ss -tulpn能看到监听端口对应的进程 PID 和程序名。如果找到 PID，确认是 OpenClaw 派生出的进程后，先kill <pid>给它发 SIGTERM，让它有机会清理 session 文件。如果 5 秒后还没退出，再kill -9 <pid>。这里我不建议一开始就kill -9，因为 OpenClaw 在退出时如果不走正常流程，很可能会留下一堆 session 锁文件，那个session file locked (timeout 60000ms)的报错就是这么来的。
4.2 清理包管理器缓存和 npx 残留
如果你用npx openclaw跑过一次，npm 会把它下载到~/.npm/_npx目录里。这是全局卸载命令永远扫不到的地方。检查方式：
find ~/.npm/_npx -maxdepth 2 -iname "*openclaw*" 2>/dev/null如果找到，直接把对应目录删掉。注意不要顺手把整个_npx目录删了，里面可能还缓存着其他工具，删完会影响别的包。
如果安装过 yarn 或 pnpm，也要执行对应的全局卸载：
yarn global remove openclaw pnpm remove -g openclaw至于npm cache clean --force，我不建议你只为了卸一个软件就这么干。它会清掉 npm 下载过的所有缓存，反而可能让下一轮安装变慢。真正该清的是~/.npm/_logs里以 openclaw 开头的日志文件。
4.3 清理 systemd / launchd 服务残留
卸载程序时最容易忽略的就是“服务单元文件”。很多人只在第一步systemctl stop了服务，没有把 unit 文件删掉。结果就是系统进程管理器里永远挂着一个残废的单元，每次systemctl daemon-reload都会扫到它。
清理动作我在 2.3 已经做了大半，这里再补两个排查命令：
systemctl list-unit-files | grep -i openclaw systemctl --user list-unit-files | grep -i openclaw只要还有输出，就继续删。删完再执行systemctl daemon-reload和systemctl --user daemon-reload，让 systemd 重新加载单元定义。如果看到Failed to disable unit: Unit file openclaw.service does not exist，反而是好事，说明已经清干净了。
macOS 的 launchd 同理，除了删除 plist，还要确认没有加载中的任务：
launchctl list | grep -i openclaw launchctl remove com.openclaw4.4 清理 shell 环境变量和别名
还有一种“隐形残留”：你的.bashrc、.zshrc或.profile里可能写死了 OpenClaw 的启动逻辑。常见写法有：
export OPENCLAW_HOME="$HOME/.openclaw" alias openclaw='node /path/to/openclaw/index.js'这些行如果不删，即使程序文件不存在，每次打开终端也会报“找不到路径”的错误，更麻烦的是它会让你误以为“OpenClaw 还在”。排查方式：
grep -ni openclaw ~/.bashrc ~/.zshrc ~/.profile ~/.bash_profile 2>/dev/null找到后把对应行删掉或注释掉，然后重新加载配置：
source ~/.bashrc # 或 source ~/.zshrc注意环境变量OPENCLAW_HOME一旦被导出，当前终端会话里依然保留，需要unset OPENCLAW_HOME才能彻底去掉。这一步不做，你后续再跑echo $OPENCLAW_HOME还是会有输出。
5. 卸载过程中的典型问题与故障定位
我在实际操作和帮人排查时，遇到过不少“看着删了，实际上没删干净”的经典问题。下面这几个是最常见的，直接按顺序排查可以省很多时间。
5.1 session file locked (timeout 60000ms) 的根治方法
这个报错是 OpenClaw 在启动或处理消息时，发现会话文件被锁住，等待 60 秒没拿到锁就放弃了。它本质上不是卸载导致的，但卸载顺序不对会加剧这个问题。
典型的错误场景是：OpenClaw 进程还在跑，你直接删掉了~/.openclaw/sessions目录。进程持有的文件句柄还在，但新启动的进程找不到原文件，就会尝试创建新文件，却发现旧锁还在，于是卡住等待。
正确的处理顺序是：先停进程，再等 3 秒，最后删除 session 目录。如果再启动时报同样的错，说明有僵尸进程还在占用锁文件。这时用ps aux | grep -i openclaw找到它，杀掉，然后手动清理~/.openclaw/sessions/*.lock文件。只要这个目录整个被删，锁文件自然也就没了。
5.2 openclaw 命令删了还在用的真相
which openclaw没输出，但你在终端里敲openclaw还能执行，这八成是 shell 的命令哈希表在作怪。bash 和 zsh 会把最近执行过的命令路径缓存起来，即使路径已经失效，当前会话里依然能“唤起”它。
这时候先执行：
hash -r如果是在 zsh 里，也可以rehash。之后再敲openclaw应该就是command not found了。如果依然能执行，那就不是缓存问题，而是存在多个命令入口，用type -a openclaw把每个路径都列出来，逐个删除。
5.3 刚删掉的配置目录又自动生成
如果你删完~/.openclaw后，过几分钟它又出现了，说明后台还有一个 OpenClaw 相关进程活着，或者是系统里的某个定时任务在反复执行启动命令。先把进程查一遍：
ps aux | grep -i openclaw crontab -l | grep -i openclaw有一种隐蔽情况是 OpenClaw 被跑成了某个系统级服务的子进程，即使你杀了它的父进程，子进程也会被 systemd 自动拉起。所以出现“删了又生成”时，别急着堆rm -rf，先回头看看 2.3 的 systemd 清理到底做没做。
5.4 消息机器人、Obsidian 插件和浏览器扩展怎么清
OpenClaw 很流行的玩法是接入消息平台和 Obsidian。这些联动模块往往不在主程序目录里，而是散落在各个宿主应用的目录中。
- 消息平台接入：去对应平台的管理后台撤销 OpenClaw 应用的授权，删除 webhook 地址。这一步不做的后果是，你卸载后它仍然会占用平台的 API 配额，甚至继续接收消息。
- Obsidian 插件：检查
.obsidian/plugins/openclaw目录，把插件文件夹删除，同时在 Obsidian 设置里移除对应插件。 - 浏览器扩展：如果装过 OpenClaw 的浏览器侧边栏或控制台扩展，在浏览器的扩展管理页面卸载，并清理它写入的本地数据。
清这些联动时，我习惯先取消授权再删文件。因为有些插件会缓存 token，直接删目录可能留下登录状态，反而更不安全。
5.5 卸载是否会影响同机的其他服务
这是我在清理前最担心的问题，结果拆了几个版本之后可以给个明确结论：正常卸载 OpenClaw 不会影响同机的其他 Node.js 项目。它的 npm 包是独立的，Docker 容器也是隔离的，source 目录更是独立文件夹。
唯一需要小心的是“全局依赖”交叉影响。如果你在 OpenClaw 的目录下执行过npm install -g某些工具，这些工具其实装到了 Node.js 全局目录，卸载 OpenClaw 时不能一刀切把整个全局node_modules删掉，否则其他服务也会挂。正确做法是只移除npm ls -g里明确和 openclaw 相关的包。
6. 卸载完成的验证清单和我的一些收尾习惯
最后这步非常重要，建议在做完所有清理后，用五个命令做一次“最终验收”。验收不是走形式，它能帮你定位到“某个隐藏目录还没清”的具体位置，比满系统乱翻高效得多。
6.1 用五个命令确认“真没了”
| 检查项 | 执行命令 | 期望结果 |
|---|---|---|
| 命令入口 | which openclaw | 无输出 |
| 全局包 | npm ls -g --depth=0 | grep -i openclaw | 无输出 |
| Docker 对象 | docker ps -a --filter "name=openclaw" | 无容器 |
| 系统服务 | systemctl list-units --all | grep -i openclaw | 无服务 |
| 配置文件 | ls -d ~/.openclaw ~/.config/openclaw 2>/dev/null | 无目录 |
注意第二个命令里的npm ls -g，如果 npm 报错“No such file”，说明你已经清干净了，别把 npm 本身的报错当成问题。另外，执行完所有命令后，最好重启一次 shell 或重新登录，再跑一遍openclaw，确保不是当前会话缓存带来的假象。
6.2 我踩过的三个卸载坑
第一个坑是“只删本体，不删 npx 缓存”。我当时用npx openclaw跑过一次测试，后来以为npm uninstall就够了，结果发现~/.npm/_npx里藏着一个几百 MB 的副本，心里挺堵的。
第二个坑是“systemd 服务没删干净”。我有一次卸载后重启服务器，日志里反复出现 openclaw.service 的启动失败记录，虽然不影响业务，但看着特别烦。后来才意识到 unit 文件还在，systemctl daemon-reload也救不了，必须手动删文件。
第三个坑是“备份当成卸载”。有一次我只是想重装，就把~/.openclaw移到备份目录，结果忘了它已经在系统里注册过 launchd 服务。重装后两个进程抢同一个 session 文件，直接复现了那个session file locked (timeout 60000ms)的报错。所以我的建议是：任何重装或卸载前，先做完整备份，再做完整的服务停用，顺序不能反。
6.3 我的建议：下次安装前先做两件事
卸载这件事做得多了，我现在对新装 OpenClaw 反而更谨慎。第一件事是保留安装记录，包括安装方式、包名、数据卷挂载路径、接入过哪些平台。别嫌麻烦，卸载时面对一堆未知目录，最需要的就是这个记录。
第二件事是尽量用 Docker 方式部署。容器虽然看起来比 npm 包重，但卸载时它把镜像、卷、网络都做了明确的边界，docker compose down --volumes --rmi all一键收尾，比在用户目录里大海捞针式清文件安全得多。我现在的习惯是，跑正式环境都用 compose 文件管理，临时测试才会用 npm 全局版，而且测试完会立刻按 6.1 的清单验一遍，绝不让测试残留过夜。
最后再分享一个小技巧：卸载完 OpenClaw 后，如果你的服务器上有类似claw、openclawd这类名字很像的命令或进程，可以在卸载前把它们一起列入待清理清单。OpenClaw 的旧版本或者某些周边工具会用不一样的命令名，单独搜 openclaw 关键字反而容易漏掉。整个过程多花十分钟，换来的是一台真正干净的机器，这笔账怎么算都值。
