超级简历WonderCV引言
聊到Ubuntu下卸载openclaw，很多人第一反应是“删个文件夹不就行了”，但真动手之后才发现，这东西不像普通软件那样走一遍 apt remove 就完事。openclaw拆开来看，至少包含三块东西：Node服务本体、命令行CLI、以及Windows Companion配过来的遥控端和浏览器扩展入口。一旦装的时候用了脚本自动部署，那它还会往你的用户目录、系统服务、配置目录里塞文件。卸载不完全，最典型的症状就是：重启后端口还在监听、clawd命令还能用、Companion里反复提示连接失败但状态又是“已连接”。
这篇文章就把我实测过的完整卸载流程拆开讲清楚。方案覆盖定位组件、清除数据、查杀残留、验证结果四个阶段，按照本地单机方式、Docker容器方式、原生二进制方式分类整理。后面还会附上我踩过的坑和一些排查思路，比如配置文件删了但进程还活着、提示“permission denied”、以及 /etc/systemd 里头的顽固残留。无论你是装完想回滚，还是准备换一台干净环境重新部署，这套步骤应该都能直接照着抄。
1. 卸载前先搞清楚 openclaw 在 Ubuntu 上到底装了什么
1.1 先聊聊 openclaw 本身的运行机制
刚开始摸openclaw的时候，我也以为它就是一个简简单单的Node项目，npm install -g 一下全局完事。实际看了一圈目录结构和进程依赖之后，发现事情没那么简单。openclaw一般会包含三个层面：核心是服务端，负责和本地模型或远端API通信，处理代理请求；其次是CLI交互层，也就是你在终端里敲 clawd 进入的那个图形化命令面板；还有一个是浏览器侧或桌面侧扩展，比如Windows Companion的桥接服务，让Windows上的配置面板能连到WSL或独立Ubuntu主机上的openclaw服务。这三个层面分别对应不同安装路径、配置目录和数据目录。
如果你是通过我上一篇文章里提到的“自动部署脚本”或npm全局安装方式装的，那还会有全局 node_modules 里的包、~/.openclaw 这类隐藏配置目录、~/.clawd 历史会话记录目录，以及systemd用户级服务。所以卸载之前，先把这个结构摸清楚，能省掉很多“为什么删完还在”的疑惑。
1.2 查看当前openclaw的实际安装方式
建议先跑一段检测命令，把openclaw当前的状态完整暴露出来。在终端按顺序执行下面几组命令，看看各条命令的返回值：
bash复制which clawd
which openclaw
clawd --version
npm ls -g --depth=0 2>/dev/null | grep -i claw
ls -la ~/.openclaw 2>/dev/null
ls -la ~/.config/openclaw 2>/dev/null
systemctl --user list-units --type=service 2>/dev/null | grep -i claw
执行之后，会出现几种典型情况：
- 如果
clawd有路径输出，说明装的是全局CLI版本； - 如果
npm ls -g里能看到clawd或者openclaw相关包名，基本可以确认卸载主体就在npm全局包里； - 如果
~/.openclaw目录存在，那配置和数据残留就得单独清； - 如果
~/.config/openclaw存在，说明还涉及XDG规范下的配置文件； - 如果systemd user service里出现了
clawd或openclaw字样的服务，那就说明自动注册了后台服务，这个最容易漏。
把这些信息记下来，然后按照下面的方案走。中途不管哪一步报错“找不到命令”或者“目录不存在”，都属于正常情况，说明当前环境里没有对应组件，跳过即可。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 干净卸载的核心思路：先停服务，再删程序，最后清残留
2.1 为什么不能直接删安装目录
很多人图省事，直接在文件管理器里翻到 /usr/lib/node_modules 或者 ~/.openclaw，右键删除，心里觉得“删完就没了”。但后续使用中很快会发现：终端还是能自动补全 clawd 命令；Companion连接面板里那个开关状态依然显示“运行中”；ps aux 里还挂着 node .../clawd 的僵尸进程。原因很好理解，一个正在运行的进程会把正在使用的文件锁住，部分文件删除后进程仍在内存里跑，直到你重启或者手动kill掉。更关键的是，systemd服务或用户级守护进程会自动重新拉起缺失的服务文件，形成“删了又自动回来”的假象。
所以标准顺序一定是：先停止所有和openclaw相关的进程，再移除systemd注册信息，最后删文件和配置。挂着的服务不干掉，后面步骤怎么删都是白费。
2.2 第零步：暂停Companion与所有会话
如果你在Windows侧装了openclaw的Companion，或者正在远程用浏览器和CLI会话，请先手动退出所有对话界面，然后把Windows上的Companion程序完全关闭。否则卸载过程中服务端会不断尝试重新握手，产生新的日志文件和进程，干扰判断。建议关闭后确认没有新的TCP连接请求，再继续下面的操作。
3. 卸载方案一：npm全局安装的卸载流程（最常规）
目前大多数人部署openclaw走的都是 npm install -g openclaw 或类似的包名。这种方式卸载最标准，但也最容易留下隐藏 rc 文件。步骤拆开如下。
3.1 停止并禁用服务
先看有没有注册systemd用户服务。执行：
bash复制systemctl --user stop clawd.service 2>/dev/null
systemctl --user disable clawd.service 2>/dev/null
systemctl --user stop openclaw.service 2>/dev/null
systemctl --user disable openclaw.service 2>/dev/null
如果提示找不到单元，就说明没有注册为系统服务。但有些部署脚本会写 /etc/systemd/system/ 下的系统级服务，需要再用一条命令确认：
bash复制sudo systemctl stop clawd.service 2>/dev/null
sudo systemctl disable clawd.service 2>/dev/null
sudo systemctl stop openclaw.service 2>/dev/null
sudo systemctl disable openclaw.service 2>/dev/null
3.2 检查并结束残留进程
服务停止后，再手动清理还在运行的node进程。执行：
bash复制ps aux | grep -E 'clawd|openclaw' | grep -v grep
如果有进程输出，记下PID，然后逐个结束，或者一次性全部结束：
bash复制pkill -f clawd
pkill -f openclaw
这里有个小技巧：pkill -f 匹配的是完整命令行，比单纯用pkill clawd更稳，因为openclaw相关进程的名称未必统一是clawd，有的显示为 node /usr/lib/node_modules/openclaw/dist/index.js。
结束后再跑一次 ps aux | grep -E 'clawd|openclaw' | grep -v grep，确认列表为空。
3.3 卸载npm全局包依赖和命令入口
清理完进程，用npm自带的卸载命令移除全局包。命令格式要看当初安装时的注册名，最稳妥的办法是按下面顺序执行：
bash复制npm uninstall -g openclaw
npm uninstall -g clawd
如果提示某个包不存在，就跳过另一个。执行完之后，再验证一下 which clawd。如果还能查到路径，说明命令入口是软链残留，手动清理：
bash复制sudo rm -f $(which clawd)
sudo rm -f $(which openclaw)
有些系统上，npm全局bin目录下会留下缓存下来的 clawd 和 openclaw 两个软链接文件，删除后重启终端即可彻底消失。这里提醒一句，不要尝试直接用 rm -rf /usr/lib/node_modules，那会把系统中其他全局包一起干掉，影响面太大。
3.4 清理配置目录、历史数据与日志
这一步更关键，因为openclaw默认会在用户主目录下创建多个隐藏目录。我实测过的目录主要有这些：
bash复制rm -rf ~/.openclaw
rm -rf ~/.clawd
rm -rf ~/.config/openclaw
rm -rf ~/.local/share/openclaw
rm -rf ~/.cache/openclaw
rm -rf ~/.npm/_logs 中的相关日志（这个建议用npm cache clean --force替代，避免误删其他日志）
删除前如果里面有你想保留的对话记录或配置，请先备份，比如 cp -r ~/.openclaw ~/openclaw-backup。如果确定不再需要，直接重复执行上面的删除命令。需要注意，有的版本会把数据写到 ~/.local/share/clawd，查看一下是否存在，按实际路径清理。
4. 卸载方案二：Docker容器部署的卸载流程
4.1 为什么Docker卸载要单独讲
有些用户是通过docker镜像跑openclaw的，这种方式下宿主机上的 clawd 命令根本不存在，但容器、镜像、数据卷三个层面积累的残留更大。我见过有人删了容器但没删镜像，结果磁盘上凭空多出好几个G的镜像层；还有的只 docker rm 了容器，但挂着具名volume，重新部署后老配置自动“复活”，以为是玄学，其实就是数据卷没清干净。
4.2 删除容器、镜像和数据卷
先查看当前存在的相关资源：
bash复制docker ps -a | grep -i claw
docker images | grep -i claw
docker volume ls | grep -i claw
确认名字后，按顺序执行：
bash复制docker stop <container_name>
docker rm <container_name>
docker rmi <image_id>
docker volume rm <volume_name>
例如我常见到的容器名是 openclaw 或 clawd-container，镜像名是 openclaw/openclaw 或 ghcr.io/openclaw/openclaw。如果你是用docker compose部署的，请到compose文件所在目录执行 docker compose down --volumes --rmi all，这样容器、默认网络、声明的数据卷都会一并清理。
4.3 清理docker compose残留和宿主机映射目录
用compose部署过的环境，一定检查家在哪个目录下挂载了宿主机路径。常见的是 ~/openclaw-data、~/docker/openclaw，这些目录里的模型缓存、日志和数据库文件同样要处理：
bash复制rm -rf ~/openclaw-data
rm -rf ~/docker/openclaw
执行完这些，再用 docker system df 看一下整体资源占用，你会发现镜像层的空间立刻释放出来了。这一步在纯node环境里没有，但对Docker用户而言是“卸载完最爽的一瞬间”。
5. 卸载方案三：源码编译部署的清理
5.1 源码编译安装的特点
如果你是从GitHub仓库clone了openclaw源码，然后 npm install && npm run build 方式部署的，那情况又不一样了。源码方式不会注册全局命令，通常是在项目目录里用 node clawd.js 或 npm start 启动，所以卸载的关键是先找到那个源码目录，然后全部删掉。
5.2 定位源码目录并彻底删除
一般clone时默认目录名是 openclaw，很可能在你的根目录或 ~/projects 下。用以下命令定位：
bash复制find ~ -maxdepth 3 -type d -name "openclaw" 2>/dev/null
find /opt -maxdepth 2 -type d -name "openclaw" 2>/dev/null
确定了位置后，先停掉相关终端进程，然后删除：
bash复制rm -rf ~/openclaw
rm -rf ~/projects/openclaw
如果在 ~/.bashrc 或 ~/.zshrc 里添加过alias，比如 alias clawd='node ~/openclaw/cli.js'，记得打开文件把那行删除。否则虽然程序已经删了，但每次新起终端还是会报 No such file or directory 的错。
5.3 用包管理器构建时的额外残留
有些用户会把openclaw打包成deb或者用了yarn/pnpm安装依赖。如果是这样，除了源码目录，还要检查 node_modules 是否被单独安装到其他路径。在源码目录内执行过 npm install 的话，node_modules 会随着整个目录删除一起消失，这倒不麻烦。
但如果检查过程中发现有人把依赖装到了 /usr/local/lib/node_modules，就得手动清理对应包：
bash复制sudo rm -rf /usr/local/lib/node_modules/openclaw
sudo rm -rf /usr/local/lib/node_modules/clawd
6. 深度清理：隐藏的env配置、bashrc引用与系统级残留
6.1 环境变量和Shell别名
openclaw部署时，如果我们在 ~/.profile、~/.bashrc、~/.zshrc、/etc/environment 里配置过环境变量，比如 OPENCLAW_HOME、CLAWD_API_URL、NODE_ENV=production，卸载时大概率没注意到。这些变量虽然在当前已加载的shell里不会立即生效，但新开的终端里依旧会被加载。清理方式很简单：
bash复制grep -n -i 'openclaw\|clawd' ~/.bashrc ~/.zshrc ~/.profile 2>/dev/null
搜到哪一行包含相关配置，用文本编辑器打开手动删除整行。如果依赖某个环境变量来指定模型API地址，记在笔记里备用即可。这里要特别提醒，不要急着直接执行 sed 批量删除，尤其是 /etc/profile.d/ 下可能还有其他脚本引用这些变量时，先确认引用关系再动手。
6.2 系统级残留：日志、锁文件、PID文件
openclaw服务运行时会生成一些锁文件或socket文件，常见位置在 /tmp/ 和 /var/run/ 下：
bash复制sudo find /tmp /var/run -iname '*clawd*' -o -iname '*openclaw*' 2>/dev/null
有输出就按实际路径删除。这些文件留着无害，但如果你想追求“彻底干净”，删掉它们。删除前确认不是其他软件共享的文件名，比如某些系统里也有名为claw的模块。
6.3 深入检查用户级systemd服务文件
前面在方案一里已经停过service，但没删除 .service 文件本身。彻底清理时应该把对应文件也删掉。执行：
bash复制rm -f ~/.config/systemd/user/clawd.service
rm -f ~/.config/systemd/user/openclaw.service
rm -f /etc/systemd/system/clawd.service
rm -f /etc/systemd/system/openclaw.service
删完服务文件之后，再执行 systemctl daemon-reload 和 systemctl --user daemon-reload，让systemd重新读一遍配置目录。这一步做不做，直接决定了之后 systemctl status clawd 是显示“could not find unit”还是继续弹“unit not loaded”。
7. 常见卸载问题与排查技巧实录
7.1 为什么删完了 clawd 命令还是能用？
这是遇到最多的情况。原因通常是npm全局bin目录下有个软链接指向 node_modules/openclaw/dist/index.js，但文件已被删除，shell哈希表还缓存着旧路径。which clawd 能查到路径，执行时却报错“No such file or directory”。解决办法是用 hash -r 刷新当前终端的命令哈希，并清理 ~/.bashrc 里的alias引用。
7.2 删掉 ~/.openclaw 之后，window companion 仍然显示“已连接”
这个现象我实测过。原因是Companion并不是实时扫描文件目录，而是通过8080或3000端口上的服务状态判断后端是否在线。如果端口还在监听，要么是系统还有openclaw进程没结束，要么是Companion自身在Windows侧缓存了旧状态。处理思路是先执行 ss -tlnp | grep 8080 找到占用进程的PID并结束，再在Windows侧退出Companion后删除它的连接记录。
7.3 npm uninstall -g openclaw 提示 EACCES 权限不足
全局卸载需要root写权限。要么前置 sudo npm uninstall -g openclaw，要么把npm全局目录改到当前用户有权限的路径下再卸载。不建议直接 chmod -R 777 /usr/lib/node_modules，那样会搞乱整个npm目录的权限结构。
7.4 卸载后发现Docker里的镜像还在，空间没释放
Docker镜像和数据卷不会因为容器删除自动消失，这是设计特性。只有在 docker rmi 和 docker volume rm 之后才会真正释放磁盘。用 docker system df 查看，你会发现很多匿名卷标着可回收的 RECLAIMABLE 状态，但这不会自动清理，务必手动执行。
7.5 误删了重要配置，能否恢复？
如果你顺着本文流程删除了 ~/.openclaw，但后来发现里面存着关键的模型API Key或skill配置，除非之前做过备份或文件系统快照，否则基本无法恢复。所以在动手之前，请务必将配置文件目录打包存一份，放心的做法是：
bash复制tar -czf openclaw-backup.tar.gz ~/.openclaw ~/.clawd 2>/dev/null
后续想恢复只需解压回原路径。建议六个月内不需要再接触openclaw再彻底删除，毕竟配置迁移成本可比擦键盘高多了。
8. 卸载完的验证清单
8.1 功能层面：命令、进程、目录三者全清
为了让这篇教程闭环，我把“如何判断卸载成功”也整理成一个清单。按顺序核对，任何一步有输出都说明残留：
| 验证项 | 命令或操作 | 预期结果 |
|---|---|---|
| CLI命令入口 | which clawd openclaw |
无输出 |
| npm全局包 | npm ls -g --depth=0 |
列表无clawd/openclaw |
| 运行进程 | ps aux | grep -E 'clawd|openclaw' | grep -v grep |
无输出 |
| 用户目录 | ls -d ~/.openclaw ~/.clawd ~/.config/openclaw |
各目录不存在 |
| systemd用户服务 | systemctl --user status clawd |
显示不存在 |
| 端口监听 | ss -tlnp | grep -E '8080|3000' |
无输出 |
| Docker资源 | docker ps -a | grep -i claw |
无输出 |
| Shell引用 | grep -n clawd ~/.bashrc |
无输出 |
8.2 环境层面：变量和缓存
再最后跑一遍：
bash复制env | grep -i claw
npm cache clean --force 2>/dev/null
清理npm缓存其实是顺手做的事，主要防止残留的缓存片段占用空间。到这里，这一台Ubuntu上的openclaw可以说已经从数字层面完全消失了。
9. 总结与个人实操体会
按我自己的经验，卸载openclaw最耗时的从来不是命令本身，而是“定位它到底装在哪”。这个框架设计上就很自由，既能当CLI工具全局安装，也能跑成Docker或源码部署，还能被Windows Companion从外部遥控。路径满天飞，不留心很容易漏掉某一层。建议所有做AI Agent方向、经常在不同机器上折腾部署的朋友，一开始装的时候就把安装方式和配置目录记到一个备忘录里，别等到卸载时才靠猜。
还有一点想提醒：卸载干净之后，顺手把 ~/.npm 下残留的缓存清掉，再重启一下机器。重启不是为了仪式感，而是确认没有任何隐藏在启动项里的自动拉起机制。如果你计划之后重新部署新版本openclaw，保留一份旧的配置文件压缩包是值得的，我就在几次回滚中靠它省了不少配置时间。希望这份卸载指南能帮你少踩几个坑，一次清到根。