很多人装openclaw时顺风顺水，一条部署脚本跑完就开始配模型、调技能、接工具，等哪天想卸载反而卡住了——npm uninstall跑了、目录删了、连配置文件都清了，重启终端发现命令还在，甚至后台进程还占着端口。这不是你操作有问题，而是openclaw这类基于Node.js的AI智能体框架本身就不是"一个二进制文件"那么简单，它自带技能系统、会话存储、模型联动配置，经常还连带装了Ollama当本地推理引擎，卸载它本质上是在清理一套小型生态系统，而不是删一个包。
这篇文章把openclaw在Ubuntu下的卸载路径完整拆一遍。无论你是用npm全局装的、git clone源码部署的、脚本安装的、还是跑在WSL里的，照着下面的层次逐个清理，最后恢复成"从没装过"的状态不是问题。适合准备换机器、想重装干净版、排查异常进程或内存占用，以及单纯想把系统收拾利索的读者。
1. 卸载之前，先摸清openclaw在系统里的存在形态
很多人卸载不彻底，根本原因是不知道openclaw在系统里到底放了哪些东西。它不像apt install vim那样，卸载命令一执行，软件本体连同依赖一起消失。openclaw是一套跨组件的AI智能体框架，我先把这个"存在形态"拆清楚，后面每一步清理才会有依据。
1.1 四种安装方式对应四种清理套路
openclaw在Ubuntu上的安装方式不同，卸载方式也完全不同。我见过的最常见的四种方式，每种对应一套清理逻辑：
| 安装方式 | 典型安装命令 | 卸载重点 |
|---|---|---|
| npm全局安装 | npm install -g openclaw | 卸载npm全局包，检查软链 |
| 源码部署 | git clone+npm install | 删除整个项目目录 |
| 脚本安装 | 一段curl xxx | bash | 清理脚本写入的目录与环境变量 |
| Docker部署 | docker run openclaw | 容器和镜像移除 |
先判断自己是哪种，最简单的方式是执行这几条命令：
which openclaw type openclaw npm list -g --depth=0 | grep -i openclaw systemctl status openclaw 2>/dev/null docker ps -a | grep -i openclawwhich和type会告诉你命令实际路径在哪。如果路径在/usr/local/lib/node_modules下面，那基本就是npm全局安装；如果路径指向/opt/openclaw或~/openclaw之类的手动位置，那就是源码或脚本安装；如果有systemd服务在跑，说明你之前做了开机自启配置。把这些信息记录下来，卸载时就能精准下手。
1.2 一个完整实例的部件清单
我拿自己机器上跑过的一套openclaw举例，方便你对照排查。当时我是用npm全局安装的，连带做了一套比较完整的配置，它落地到系统里大概是这些东西：
- 主程序文件：位于
/usr/local/lib/node_modules/下的openclaw包目录（npm全局安装位置） - CLI入口软链：
/usr/local/bin/openclaw，指向包目录里的可执行文件 - 配置目录：
~/.openclaw/，里面存了config.yaml、API密钥、模型参数 - 技能目录：
~/.openclaw/skills/，存放各类自定义技能脚本 - 会话数据：
~/.openclaw/sessions/，历史对话记录和一些临时状态 - 日志目录：
~/.openclaw/logs/，运行时输出和错误日志 - systemd服务：我自己创建了
/etc/systemd/system/openclaw.service用来开机自启 - 关联依赖：
ollama服务，因为我把openclaw配成了走本地Qwen模型
这就是为什么只执行npm uninstall -g openclaw根本清不干净——npm只删了第一步的包目录和软链，其余全留在原地。下面每个章节，就是对应清理这些部件的具体操作。
2. npm全局包卸载：最主流场景的正解
大多数人装openclaw都是走npm这条路，因为它生态兼容性最好，升级也方便。这个场景下的卸载相对规范，但细节也不少。
2.1 确认全局包是否正确注册
先回到第一步，用npm list -g看一眼openclaw到底是不是以全局包形式存在的：
npm list -g --depth=0如果输出里有openclaw或@openclaw/cli这类条目，那说明它确实是npm全局包。也可以再确认一下全局安装路径：
npm root -g # 通常输出 /usr/local/lib/node_modules 或 ~/.nvm/versions/node/vX.X.X/lib/node_modules这一步的坑在于：如果你用了nvm管理Node版本，全局包是挂在某个具体Node版本目录下的，卸载的时候要确保你当前的nvm版本就是当初安装时用的那个版本。我遇到过朋友用nvm切来切去，卸载时在v20的上下文里，包实际装在v18下面，执行npm uninstall半天没反应，还以为是网络问题。
2.2 执行卸载并处理权限问题
确认没问题后，直接执行：
sudo npm uninstall -g openclaw加sudo是因为全局包目录通常是root所有，不加权限会报EPERM或EACCES。如果你用的是nvm且把全局目录权限归到了自己名下，那可以不用sudo，但用上也没坏处。
这里有个细节容易踩坑：openclaw的包名在不同版本和不同发布渠道下不太一样。有些老版本包名叫openclaw，有些版本是@openclaw/cli，还有的是openclaw-server。如果你不确定包名的准确写法，先到/usr/local/lib/node_modules/下看一眼实际存在的目录名，再照着那个名字卸载：
ls /usr/local/lib/node_modules/ # 看到 openclaw 或 @openclaw 目录，照着卸载 sudo npm uninstall -g @openclaw/cli如果卸载时报错提示包不存在，也可以手动把对应目录删掉，但要确保软链一并清理，见下一节。
2.3 卸载完之后的"残留命令"检查
执行完npm uninstall后，验证一下：
which openclaw正常情况下应该没有任何输出。但如果你执行后仍然能看到路径，有几种可能：
- 包删了，软链没删干净：
npm uninstall理论上会一起处理软链，但用pnpm或yarn装过的会有些差异，手动检查/usr/local/bin/openclaw是否存在，存在就删掉：
sudo rm -f /usr/local/bin/openclaw- shell缓存了旧命令路径：当前终端还留着之前的命令哈希缓存，执行
hash -r刷新一下即可，新开的终端不会有这个问题。 - 你机器上不止一个openclaw：我曾经排查过一个案例，用户用npm装了一个，又用脚本装了一个到
/usr/local/bin/，which命中的是脚本版本，npm卸载后命令照样能跑。所以which输出要结合路径判断，确认是哪个来源。
3. 源码部署与脚本安装：手动安装的翻新式清理
源码部署和脚本安装不像npm那么规范，清理起来更像"翻新"——所有东西都要手动找到、手动删。这个场景下的核心原则是：先停服务，再动文件。
3.1 先停进程，别让文件被占用
如果你之前在运行openclaw，或者配置了开机自启，直接删文件大概率会遇到删不掉或删完又自动重启的情况。先把进程和服务全部停下来：
# 停systemd服务（如果有） sudo systemctl stop openclaw.service sudo systemctl disable openclaw.service # 兜底：直接杀掉所有相关进程 pkill -f openclawpkill这条要注意，它会匹配命令行里包含"openclaw"字样的所有进程，如果你同时还在跑别的涉及openclaw名字的程序，一并会被干掉，属于正常现象，不用慌。停完确认一下：
ps aux | grep -i openclaw没有输出就说明进程已经清了。这里不建议用kill -9作为第一步，先走正常终止流程，确实卡住了再考虑强杀。
3.2 找到并删除项目目录与软链
源码部署通常会把项目放在某个固定目录下，常见的几个位置：
~/openclaw~/workspace/openclaw/opt/openclaw/srv/openclaw
如果记不清放在哪，用find全局搜索，但要排除掉系统虚拟目录，避免无意义的IO和权限噪音：
find / -maxdepth 5 -type d -name "*openclaw*" 2>/dev/null | grep -vE "^/proc|^/sys|^/run"找到项目目录后，还需要检查有没有创建软链到系统PATH目录：
ls -la /usr/local/bin/openclaw如果看到/usr/local/bin/openclaw -> /opt/openclaw/bin/...这种输出，说明有软链存在，先删软链再删项目目录：
sudo unlink /usr/local/bin/openclaw # 或者 sudo rm -f /usr/local/bin/openclaw sudo rm -rf /opt/openclaw这里有个实际教训：我曾经图省事先删了项目目录，结果软链变成了"不存在目标的红链"，后续排查问题的时候还以为系统里有个诡异的文件指向坏了。正确顺序永远是先删软链、再删主体。
3.3 脚本安装特有的坑
脚本安装通常是一段curl xxx | bash，这类安装器经常不按npm的规则来，它会把文件散布到多个位置。一个典型的脚本安装会写入这些东西：
- 主程序目录，如
/opt/openclaw - CLI入口，如
/usr/local/bin/openclaw - 配置文件，写到
~/.config/openclaw或~/.openclaw - 用户级systemd服务，写到
~/.config/systemd/user/openclaw.service
用脚本安装的卸载没有统一命令，全凭脚本作者写没写反安装逻辑。如果你当时保留着安装脚本，回头看一眼它到底往哪些路径写了内容，照着清理是最靠谱的。没有脚本也没关系，按下面的写法检查用户级服务和用户级二进制目录：
# 用户级systemd服务 systemctl --user stop openclaw.service systemctl --user disable openclaw.service rm -f ~/.config/systemd/user/openclaw.service # 用户级bin目录 ls -la ~/.local/bin/openclaw 2>/dev/null脚本安装还有个容易忽视的地方：它可能往~/.profile、~/.bashrc里追加了环境变量（比如OPENCLAW_HOME），这个后面章节单独讲。
4. 配置目录、systemd服务与Shell环境：残留在哪重点排查
到这里，openclaw的主程序已经删干净了，但系统里到处还留着它的"影子"。这一层不清理，过几周你可能会发现某个服务又神秘自启了、某个环境变量一直在报错，或者~目录下多出一堆不知道哪个程序写的日志。这一节就是专门处理这些隐蔽残留的。
4.1 主配置目录的备份与清除
openclaw的主配置目录是卸载流程里最该认真对待的部分。它包含了你的API密钥、模型配置、技能脚本和历史会话。如果你确认不再使用，直接删：
rm -rf ~/.openclaw但我的建议是：删之前先备份。因为openclaw的技能脚本和模型配置，重新配起来少说要半小时，如果你只是暂时不用、以后可能还要回归，备份能省掉大量重复劳动：
# 全量备份 tar -czf ~/openclaw-backup-$(date +%Y%m%d).tar.gz ~/.openclaw # 只备份技能目录（技能脚本通常是你自己写的内容，最有价值） cp -r ~/.openclaw/skills ~/skills-backup有些版本会把配置文件放到~/.config/openclaw，检查一下一并处理。主目录里的大文件（比如几个G的会话数据库或缓存），如果不需要备份，可以在备份技能后就地删掉，减小备份体积。
4.2 Shell启动文件里的环境变量
npm安装通常不会自动写环境变量，但源码部署和脚本安装很常见。他们会在~/.bashrc、~/.zshrc、~/.profile里追加类似这样的行：
export OPENCLAW_HOME="$HOME/.openclaw" export PATH="$PATH:/opt/openclaw/bin"这些行如果不删，卸载后每次打开终端都会报一长串"目录不存在"的警告。检查方法：
grep -n -i "openclaw" ~/.bashrc ~/.zshrc ~/.profile ~/.bash_profile 2>/dev/null把命中的行删掉，然后让配置生效：
source ~/.bashrc这里有个细节：grep显示可能有多行，逐一人工确认，别用sed -i批量删，避免误删注释里恰好提到"openclaw"的说明文字。我见过有人的.bashrc里保留了当初部署时的注释文档，内容是记录安装过程，那行删不删都无所谓，但如果是export语句就一定要删，否则环境变量指向一个不存在的目录，Shell启动时会反复报错。
4.3 Systemd服务文件的手动注销
如果你创建过自启服务，npm uninstall和删除项目目录都不会动它。这个文件是独立的，必须手动处理：
# 确认服务状态 systemctl status openclaw.service # 停止并禁用 sudo systemctl stop openclaw.service sudo systemctl disable openclaw.service # 删除服务文件 sudo rm -f /etc/systemd/system/openclaw.service # 重新加载守护进程配置 sudo systemctl daemon-reloaddaemon-reload这步不能省。只删文件不重载，systemd会一直记着这个服务已注册，偶尔还会在你不知情的情况下尝试拉起来。用户级服务同理，用systemctl --user前缀重复一遍。
这个环节我踩过不止一次坑：有一次删了服务文件但忘了disable，结果重启后系统提示"Failed to start openclaw.service: Unit not found"，虽然不影响开机，但每次启动都多几秒延迟，看着就很闹心。
5. 别忽略了Ollama、模型文件与WSL的同层依赖
openclaw能跑起来，经常不是它自己一个进程在工作。很多人按部署教程一步步配下来，Node.js、Ollama、模型文件、Windows下的Companion配套软件全装了个遍。这些"同层依赖"如果一起卸载，才算是真正清理干净。
5.1 Ollama是独立的，但常被当作openclaw的配套引擎
openclaw支持接入云端API（比如OpenAI、Anthropic），也支持走本地模型，而本地模型最常见的方案就是通过Ollama启动推理服务。很多人为了省API费用，都选了后者。
卸载openclaw后，Ollama本身不会自动停。它可能还在后台跑着，白吃几个G的内存。如果你确认机器上只有openclaw会调用Ollama，可以一并停掉：
# 停止 ollama 服务 sudo systemctl stop ollama.service sudo systemctl disable ollama.service # 删除ollama（如果想彻底移除） sudo rm -f /etc/systemd/system/ollama.service sudo rm -rf /usr/local/bin/ollama sudo rm -rf ~/.ollama但这里有一个决策点：删除~/.ollama意味着你所有拉取过的模型文件全部没了。像qwen2.5这种几个G的模型，重新拉又要等半天，所以我建议先ollama list看一眼你本地有哪些模型，确认不要了再删。模型文件通常存在~/.ollama/models下，如果只是想停产Ollama但保留模型，你可以只停服务不删目录。
补充说明一下：0penclaw也支持你只接API、完全不装Ollama，所以Ollama不一定是必装组件。如果你的部署环境是"纯API模式"，那这个章节完全不用看。
5.2 WSL环境下的额外清理项
一部分读者是在Windows的WSL里跑的Ubuntu，卸载逻辑和原生Ubuntu完全一致，但有几个交叉点值得单独说。
先说一个常见误区：在WSL里面卸载openclaw，只需要在WSL终端里执行普通Ubuntu的卸载命令，它不会触碰Windows侧的文件。有些用户在Windows的"应用程序"列表里找了半天openclaw，找不到就以为没法卸载，其实openclaw主程序活在WSL文件系统里，Windows面板是看不见WSL内部软件的。
但反过来，如果你在Windows侧安装过配套组件（比如openclaw windows companion），那就要到Windows的"设置->应用"里把它卸掉。WSL命令管不到Windows程序。高频搜索词里出现的"wsl --status"，那只是查看WSL运行状态的命令，不是卸载工具，别搞混。
另外WSL环境有个特殊细节：如果你在WSL里通过npm全局安装了openclaw，而WSL发行版的/usr/local/目录权限有一些历史遗留问题（比如masquerade导致文件所有者混乱），卸载时遇到EACCES，就用sudo前缀执行，实在不行再检查一下WSL存储空间，因为发行版虚拟磁盘（VHDX）不会因为删除文件而自动收缩，卸载大体积依赖之后如果在意空间占用，可以考虑用wsl --shutdown后对VHDX做压缩，那是另一个话题了，这里不展开。
6. 彻底性验证与卸载过程中的高频翻车点
最后一步是验收。我习惯卸载完任何软件都跑一遍检查，openclaw这种多组件软件更应该做全套验证，避免"表面卸载、暗里残留"。
6.1 六条验证命令，扫一遍就知道干没干净
你可以把下面这六条命令贴到终端里，当作卸载验收清单：
# 1. 命令是否还存在 type openclaw # 2. npm全局包是否还存在 npm list -g --depth=0 | grep -i openclaw # 3. systemd服务是否还在 systemctl list-unit-files | grep -i openclaw # 4. 配置文件目录是否还存在 ls -la ~/.openclaw ~/.config/openclaw 2>/dev/null # 5. 常见安装目录是否还存在 ls -la /opt/openclaw /usr/local/lib/node_modules/openclaw 2>/dev/null # 6. ollama是否还在（如果一并清理过） ps aux | grep -i ollama理想状态下，1-5没有任何输出，第6条只显示grep自身那一行。如果你的环境之前占用过某个端口，也可以顺手确认端口已经释放：
# 用你之前的端口号替换8090 sudo lsof -i :8090没有输出就说明端口完全释放了，之前配置的对外服务算是真正"下线"。
6.2 那些看着像Bug其实是正常现象的瞬间
卸载过程中的一些现象，第一次遇到会以为出问题了，实际都是正常行为。
第一个是"卸载后命令还能用"。如果你执行了npm uninstall -g openclaw之后，开一个新的终端窗口执行openclaw --version，还有输出版本号——这基本可以断定你的/usr/local/bin/openclaw是个独立入口，指向的不是npm包目录，而是某个脚本或源码目录。解决办法就是把软链或入口文件手动删掉，再执行type openclaw确认。
第二个是"部分文件删不掉"。配置文件里有大量会话数据和运行时产生的临时文件，可能被一个名为openclaw-server的进程占着。我遇到过的情形是：明明运行着服务窗口但不能直接关闭，pkill -f openclaw下去会连带杀掉好几个进程。正常现象，不用担心误杀。
第三个是"npm uninstall 提示 not installed"。如果你用nvm管理Node、且当前切换到了另外一个版本，npm全局环境变了，之前装在旧版本下的包就"看不见"了。切回对应版本再卸载，或者直接去旧版本的node_modules里手动删除。
第四个是"找不到配置文件"。有些版本的openclaw会把配置写到~/.local/share/openclaw、~/.cache/openclaw这些遵循XDG规范的位置，比较隐蔽。卸载完如果发现home目录下面有可疑的openclaw目录，逛一圈再删。
6.3 一些真实卸载后的经验补充
最后补充几条经过实际操作验证的经验，算是给这篇卸载教程收个尾。
第一，卸载前一定要先记录你当前的配置备份。openclaw的配置文件里存着API密钥，一旦删除无法找回。我自己吃过亏，卸载前忘了备份，后来想重新体验时所有密钥都要重新申请配置，非常折腾。如果你只是"想清一下缓存、腾点空间"，而不是彻底告别这个工具，建议仅备份配置文件而不删主体目录。
第二，npm卸载后顺手清理一下全局缓存。很多人不知道npm uninstall只会移除包本身，不会清掉npm缓存中下载过的压缩包，长期累积会让磁盘多出几个G的垃圾。可以执行：
npm cache clean --force第三，关于Ollama的处置我再强调一遍：先看ollama list再决定删不删模型。如果你已经删了openclaw但还保留着Ollama，它本身也是一个很好用的本地推理工具，可以配合其他项目使用。这一点不冲突，不用为了卸载openclaw而把Ollama也一并移除。
最后说个小技巧：如果你卸载时发现~/.openclaw占用空间特别大，通常不是配置文件本身，而是会话数据库或缓存文件在膨胀。哪怕你决定保留配置目录，也可以单独把日志和缓存目录清掉：
rm -rf ~/.openclaw/logs rm -rf ~/.openclaw/cache这样既保留了技能和密钥，又不至于在系统里留一堆没用的历史垃圾。
卸载这套流程走完，你再回头看最初的问题，其实"如何卸载openclaw"的本质不是找一条卸载命令，而是搞清楚一个带技能系统和模型联动的AI智能体框架，到底在Ubuntu里藏了哪些东西。把组件清单列出来，按进程、文件、配置、服务、依赖的顺序逐个清理，任何软件都能卸得干干净净。
