写这篇之前先说个背景我之前在 WSL 里部署过 OpenClaw接了 Microsoft Teams 频道还把 qwen2.5-3b 挂到了本地推理链路上跑了大半个月。后来因为目录规划变动需要彻底卸载重装结果官方卸载命令跑完进程还在、服务还在、端口还占着甚至 Teams 里那个 bot 账号都留着历史会话记录。折腾了一晚上才逐层清干净。这篇文章就把我排查和手动卸载的全过程整理出来包括为什么官方命令不可靠、哪些残留容易被漏掉、每一步怎么验证以及清理完怎么确认环境真正恢复原状。如果你也遇到卸载命令失效或者只是想把 OpenClaw 从机器上彻底抹干净这篇应该能帮你省掉不少弯路。1. 卸载命令翻车的现场还原与根因定位我先说结论官方卸载命令失效绝大多数情况不是命令写错而是安装方式跟卸载逻辑对不上。OpenClaw 的官方脚本默认假设你是用npm install -g openclaw或者一键脚本装的标准路径但实际部署时很多人的做法是把仓库 clone 到自定义目录、用node server.js直接拉起、再通过.service文件注册成常驻服务。这时候卸载脚本只能删掉它认识的那几样东西其他自定义路径一概不管。1.1 官方卸载流程为何会失效OpenClaw 的卸载逻辑一般做这几件事停掉由 it 自己管理的 Node 进程、删除按约定路径安装的全局命令、移除版本目录。只要你的部署偏离了约定就必然出现命令执行成功但东西还在的诡异状态。我这边遇到的情况是这样的OpenClaw 跑在 WSL 的 Ubuntu 22.04 里安装时图省事直接把整个项目放到了/opt/openclaw用 systemd 用户级服务挂了个openclaw-gateway.service同时为了让 Teams 回调能通过还额外起了个反向代理服务进程。官方卸载脚本执行后控制台提示 uninstall complete但我接着查端口8080 依然在监听顺手 curl 一下本机地址结果服务照样返回响应头。这就是典型的卸载脚本只删了 npm 包引用、没动运行中的服务和配置文件的案例。另一个常见翻车场景是版本残留。如果你从 npm 全局安装过旧版后来换了源码部署卸载脚本可能只认全局路径对源码目录毫无感知。更隐蔽的是 npm 本身会生成.node_modules缓存和package-lock.json这些文件不会因为卸载脚本执行就自动消失重新检查时会被误判为还在运行。1.2 卸载失败的三种典型表现根据我查资料和实操的观察卸载失败的表现基本可以归成三类表现典型现象直接原因进程残留ps auxgrep openclaw 仍然有 node 进程文件残留/opt/openclaw、~/.openclaw目录仍在卸载脚本未覆盖自定义安装路径集成残留Microsoft Teams 里 bot 仍可收到消息或注册表/环境变量有旧路径服务注册、环境变量、外部 API 凭据未被回收第一类最常见第二类紧随其后第三类最容易被忽略。尤其是 Teams 集成卸载脚本只负责本地文件根本不具备权限去删除你在 Azure Bot Service 里注册的 bot 身份所以即使本地代码删干净Teams 里的 bot 依然能收到消息并尝试转发请求——如果你只是换装这会直接导致新旧实例冲突。2. 卸载前的环境盘点先画一张残留地图在动手删任何东西之前先花十分钟盘点环境。这一步不是为了走形式而是为了避免误删数据尤其是模型缓存、会话记录这类不可再生的内容。我实践中发现最稳妥的方式是同时检查 Windows 侧和 WSL 侧因为 OpenClaw 的部署链路往往是两边都有痕迹。2.1 Windows 侧的静态检查打开 PowerShell管理员权限先执行一段基础检查# 检查 OpenClaw 相关的环境变量 [Environment]::GetEnvironmentVariable(OPENCLAW_HOME, User) [Environment]::GetEnvironmentVariable(OPENCLAW_HOME, Machine) # 查看启动项和服务 Get-CimInstance Win32_StartupCommand | Where-Object { $_ .Command -like *openclaw* } Get-Service | Where-Object { $_.Name -like *openclaw* -or $_.DisplayName -like *openclaw* } # 检查常见安装目录 Test-Path $env:LOCALAPPDATA\Programs\openclaw Test-Path $env:APPDATA\openclaw这一步能快速定位OpenClaw 是不是在 Windows 侧装过桌面壳或者留有用户级环境变量。我遇到过的情况是安装过 Electron 版管理面板卸载程序跑了但%APPDATA%\openclaw里还有几千个缓存文件导致后续重装时反复出现配置冲突。2.2 WSL 侧的运行状态盘点WSL 侧的检查是重头戏因为真正的服务进程、依赖库、模型权重都在这边。先进入 WSL 环境然后逐项确认# 检查进程 ps aux | grep -E openclaw|node.*claw | grep -v grep # 检查监听端口常见端口8080, 3000, 5000, 7860 ss -tlnp | grep -E 8080|3000|5000|7860 # 检查 systemd 用户服务和系统服务 systemctl --user list-units | grep openclaw systemctl list-units | grep openclaw # 检查 npm 全局包 npm list -g --depth0 2/dev/null | grep openclaw npm ls -g 2/dev/null | grep -i openclaw # 检查 crontab crontab -l 2/dev/null | grep -i openclaw如果你在 WSL 里配置过wsl --status报错相关的环境那还要额外看一眼 WSL 发行版本身是否变成了异常状态。我遇到过一次因为 OpenClaw 强制占用网络端口导致wsl --shutdown之后子系统起不来的情况届时要先恢复 WSL 才能继续清理操作。2.3 数据资产的优先级判断盘点过程中如果发现以下内容先备份再动手~/.openclaw/下的data.db、session/、logs/包含聊天会话、历史消息、用户授权 token~/.openclaw/models/或/opt/openclaw/models/本地量化模型权重文件可能好几个 GB.env或config.json包含 Teams 应用 ID、tenant ID、API key我的处理习惯是把整个.openclaw目录先打一个 tar 包丢到/mnt/c/backup/再开始清理。这样即使后面误删了想要的数据也能恢复不会因为卸载搞出数据事故。3. 手动卸载主程序与配套文件逐目录清理环境盘点完就可以正式进入手动卸载流程。这部分的总体思路是先停服务、再删程序、再清配置、最后做全盘搜索兜底。3.1 先停进程和系统服务一定要先停服务再删文件否则删着删着进程又把文件句柄占住后面想删都删不掉。按顺序执行以下命令# 停止 systemd 服务如果有 systemctl --user stop openclaw-gateway.service 2/dev/null systemctl stop openclaw.service 2/dev/null # 禁用服务防止开机自启 systemctl --user disable openclaw-gateway.service 2/dev/null systemctl disable openclaw.service 2/dev/null # 如果存在 .service 文件删除它们 rm -f ~/.config/systemd/user/openclaw*.service sudo rm -f /etc/systemd/system/openclaw*.service # 强制终止残留进程 pkill -f openclaw 2/dev/null pkill -f node.*claw 2/dev/null # 等待 2 秒后再次确认 sleep 2 ps aux | grep -E openclaw|node.*claw | grep -v grep如果你的服务不是 systemd 管理的而是用nohup或pm2起的那就单独处理# pm2 方式 pm2 delete openclaw 2/dev/null pm2 save 2/dev/null # nohup 方式查找 PID 并 kill lsof -i :8080 -t | xargs -r kill -9这里有个容易踩的坑systemd 的--user服务在某些 WSL 配置下根本不会自动启动所以明明systemctl --user list-units查不到服务进程却还在跑。处理方式就是不要只看服务状态直接用ps aux和端口监听来判断。3.2 删除源码目录、全局命令与 npm 包进程清干净后开始删文件。这一步要分清楚源码安装和 npm 全局安装两种情况。如果是 npm 全局安装# 卸载 npm 全局包 npm uninstall -g openclaw 2/dev/null # 检查是否还有残余命令 which openclaw 2/dev/null # 如果有输出直接删掉软链 rm -f $(which openclaw 2/dev/null)如果是从源码部署比如/opt/openclaw或自定义目录# 删除源码目录 rm -rf /opt/openclaw rm -rf ~/openclaw rm -rf ~/OpenClaw # 删除用户数据目录如果确定不需要保留 rm -rf ~/.openclaw rm -rf ~/.config/openclaw rm -rf ~/.cache/openclaw rm -rf ~/.local/share/openclaw # 删除 npm 缓存中的 claw 相关项注意这里只示例实际路径以 npm 配置为准 rm -rf ~/.npm/_npx/*openclaw* 2/dev/null如果你在部署时把模型文件或 Python 虚拟环境放在了/opt/openclaw/venv或~/.openclaw/venv别犹豫一起删掉。这类虚拟环境动辄数百 MB留着纯占空间而且换版本之后往往不可复用。3.3 清理 WSL 里的可执行文件软链接OpenClaw 升级时我习惯把可执行文件链接到/usr/local/bin/openclaw方便全局调用。卸载时这个软链不会自动消失需要手动处理# 查找可能的软链位置 ls -l /usr/local/bin/*claw* 2/dev/null ls -l /usr/bin/*claw* 2/dev/null ls -l ~/.local/bin/*claw* 2/dev/null # 确认是软链后删除 rm -f /usr/local/bin/openclaw rm -f ~/.local/bin/openclaw这个细节很容易漏。软链文件本身可能只有几十字节但留着会干扰后续安装时的路径判断让安装器以为 OpenClaw 还存在于系统里。4. 清理 Linux 侧的运行残留环境变量、Shell 配置与端口占用删除主程序目录不算结束WSL 里至少还有三处残留必须清理Shell 环境变量、Cron 定时任务、网络端口占用的内部虚拟配置。4.1 Shell 配置注入项清理当时我部署 OpenClaw 时为了图方便在~/.bashrc末尾加过这么几行# OpenClaw 快捷命令 export OPENCLAW_HOME~/.openclaw alias clawopenclaw --interactive卸载时这几行不会被脚本自动清掉。更糟糕的是如果你后续重装这些残留的 alias 和 export 会和新的配置打架导致命令行为非常诡异。清理方式很简单# 打开配置文件手工注释或删除相关行 vi ~/.bashrc重点检查这几个文件~/.bashrc~/.bash_profile~/.profile~/.zshrc/etc/profile.d/openclaw.sh系统级配置用 sudo 删除删完后重新加载配置source ~/.bashrc然后验证环境变量是否还在env | grep -i openclaw没有任何输出就说明清干净了。4.2 Cron 定时任务和 systemd 定时器OpenClaw 这类常驻服务在部署时常会被搭配一个守护进程重启脚本用 Cron 每五分钟检查一次进程状态发现挂了就拉起。这个设计在运行期很可靠但卸载时就成了最顽固的残留——即使主程序已删除Cron 还是会尝试执行重启脚本报错刷屏事小严重时会把一个不完整的进程重新拉起来。# 查看当前用户的 crontab crontab -l # 如果看到 openclaw 相关任务编辑删除 crontab -e还需要检查 root 用户的 crontab如果你当时用 sudo 部署过服务sudo crontab -l | grep -i claw如果在里面发现了重启脚本同样进入sudo crontab -e删除。删除后建议等一分钟确认没有进程再次被拉起这是检验 Cron 是否清理干净的唯一可靠方式。4.3 残留的 Node.js 与 Python 侧依赖OpenClaw 的依赖横跨 Node.js 和 Python 两个生态。Node 这边主要是node_modules和全局包Python 这边有时会用到transformers、sentencepiece等组件做模型加载这些依赖通常装在虚拟环境或用户级目录里。# 删除用户级 Python 缓存如果确定不再需要 pip uninstall openclaw -y 2/dev/null pip3 uninstall openclaw -y 2/dev/null # 删除 npx 缓存中可能存在的 claw 脚手架 rm -rf ~/.npm/_npx 2/dev/null这里我必须提醒一句rm -rf ~/.npm/_npx是一种激进清理会清掉所有用 npx 一键运行过的工具缓存不只是 OpenClaw 的。确定没有其他常用 npx 工具再执行或者更稳妥的做法是进目录手工删除带 claw 关键字的子目录。4.4 WSL 内部的端口与虚拟网卡残留检查部署 OpenClaw 接 Teams 时为了回调接入经常会在 WSL 里配置端口转发或虚拟网络适配器。卸载后这些底层配置不会自动还原。检查方法# 查看 WSL 网络代理和端口转发规则 cat /etc/wsl.conf 2/dev/null | grep -i openclaw cat ~/.wslconfig 2/dev/null | grep -i openclaw # 查看残留端口监听确认没有进程占用 ss -tlnp | grep -E 8080|3000|5000 || echo no listening ports如果wsl.conf里加了自定义的[network]或[interop]配置卸载后建议恢复默认。这一步做完Linux 侧基本上就干净了。5. 清理 Windows 侧的蝴蝶效应Electron、Teams 缓存与注册表残留OpenClaw 这类工具虽然核心跑在 WSL 里但 Windows 侧的残留往往更隐蔽、更烦人。我拆过它的安装行为发现至少有三条路径会在 Windows 侧留下痕迹Electron 外壳的本地存储、Teams 集成的登录态缓存、以及环境变量和快捷方式。5.1 Electron 本地存储目录清空如果你用过 OpenClaw 的桌面管理面板那 Windows 侧一定会有 Electron 的 Local Storage 数据。路径一般在%APPDATA%\openclaw\ %LOCALAPPDATA%\openclaw\ %APPDATA%\OpenClaw\这里存的是 UI 配置、登录凭据、窗口状态甚至还有可能缓存了部分 API 响应数据。清空方式Remove-Item -Recurse -Force $env:APPDATA\openclaw -ErrorAction SilentlyContinue Remove-Item -Recurse -Force $env:LOCALAPPDATA\openclaw -ErrorAction SilentlyContinue如果你装过桌面版会额外有一个OpenClaw.exe文件连同其所在目录一块删掉Get-ChildItem $env:LOCALAPPDATA\Programs -Filter *openclaw* | Remove-Item -Recurse -Force注意 PowerShell 通配符路径末尾的反斜杠不要加错位置否则可能会把%LOCALAPPDATA%整个目录当成目标。这个坑我踩过一执行就把无关程序的配置目录也删了后来靠回收站才找回。5.2 Microsoft Teams 集成的身份凭据回收Teams 接入是 OpenClaw 卸载时另一个官方命令管不着的地方。Teams 侧的 bot 是通过 Azure Bot Service 注册的本地卸载脚本不可能去调用 Azure API 删除应用注册。如果不手动处理会出现两个问题旧的 bot 凭据会一直留在 Teams 客户端里收到消息时还会尝试往本地端口转发重装 OpenClaw 时新 bot 和旧 bot 并存你根本分不清哪个是新的我的建议是在卸载完成前先进入 Azure 门户找到对应的 Bot 服务资源删除整个 bot 实例然后在 Teams 管理后台删除对应的应用权限。如果只是临时卸载还想保留 bot那就至少把 client secret 轮换掉防止旧凭据被滥用。5.3 环境变量、开始菜单与注册表残留Windows 侧的注册表残留主要来自安装包或之前手动添加的系统环境变量。检查方式# 检查用户级和系统级 PATH 是否包含 openclaw 相关路径 $userPath [Environment]::GetEnvironmentVariable(Path, User) $systemPath [Environment]::GetEnvironmentVariable(Path, Machine) $userPath -split ; | Where-Object { $_ -like *openclaw* -or $_ -like *claw* } $systemPath -split ; | Where-Object { $_ -like *openclaw* -or $_ -like *claw* } # 处理方式移除对应的 Path 条目后重新写回 $newUserPath ($userPath -split ; | Where-Object { $_ -notlike *openclaw* }) -join ; [Environment]::SetEnvironmentVariable(Path, $newUserPath, User)注册表方面重点搜这几个根键Get-ChildItem HKCU:\Software | Where-Object { $_.PSChildName -like *openclaw* } Get-ChildItem HKLM:\Software | Where-Object { $_.PSChildName -like *openclaw* }找到对应的键直接删除。删除注册表前务必先导出备份因为注册表不像文件系统有回收站概念。5.4 清理快捷方式和 WSL 发行版快照最后一步收尾检查 Windows 侧# 删除桌面和开始菜单快捷方式 Remove-Item $env:PUBLIC\Desktop\OpenClaw*.lnk -ErrorAction SilentlyContinue Remove-Item $env:USERPROFILE\Desktop\OpenClaw*.lnk -ErrorAction SilentlyContinue # 检查 WSL 发行版列表确认是否需要卸载 wsl --list --verbose如果你决定不用 WSL 了可以把对应发行版直接注销wsl --unregister Ubuntu需要高度警惕的是wsl --unregister会清空该发行版内所有数据不只是 OpenClaw 的数据。如果这个 WSL 发行版里还有其他项目就不要执行这步只清理 OpenClaw 相关内容就好。6. 卸载后的自检清单与恢复误删数据的补救办法所有清理操作做完别急着宣布卸载成功跑一遍自检才是关键。不夸张地说我见过太多人清理到一半然后因为漏了一个环境变量导致重新部署时怎么跑怎么报错。6.1 全链路自检命令自检分 Windows 侧和 WSL 侧两组命令。先做 WSL 侧# 1. 确认没有进程 ps aux | grep -E openclaw|claw | grep -v grep || echo PASS: no process # 2. 确认没有端口监听 ss -tlnp | grep -E 8080|3000|5000|7860 || echo PASS: no ports # 3. 确认没有命令映射 which openclaw || echo PASS: no command # 4. 确认没有目录残留 ls -d ~/.openclaw /opt/openclaw 2/dev/null || echo PASS: no dirs # 5. 确认没有环境变量 env | grep -i openclaw || echo PASS: no env vars # 6. 确认没有 cron crontab -l | grep -i claw || echo PASS: no cron再做 Windows 侧# 1. 确认没有环境变量 if ([Environment]::GetEnvironmentVariable(OPENCLAW_HOME, User)) { FAIL: env exists } else { PASS: no env } # 2. 确认没有目录残留 $paths ($env:APPDATA\openclaw, $env:LOCALAPPDATA\openclaw, $env:LOCALAPPDATA\Programs\openclaw) foreach ($p in $paths) { if (Test-Path $p) { FAIL: $p exists } else { PASS: no dir } } # 3. 确认没有服务 if (Get-Service | Where-Object { $_.Name -like *openclaw* }) { FAIL: service exists } else { PASS: no service }6.2 常见残留症状与对应处理自检中如果发现异常参考下表快速定位症状可能原因处理办法ps aux仍有 node 进程systemd 服务未禁用或 Cron 拉起重新执行 3.1 的停止命令检查 crontabss -tlnp端口仍占用WSL 内其他服务占用或端口转发残留fuser -k 8080/tcp强制释放which openclaw仍找到命令软链路径未删干净执行 3.3 的软链清理Windows 侧 Teams 仍可收发消息Azure Bot 未注销去 Azure 门户删除 bot 实例重装时报configuration already exists~/.openclaw或%APPDATA%\openclaw残留配置强制删除后再重装特别说一下端口占用这个问题它最容易误判。有次我以为 OpenClaw 没清干净结果用lsof -i :8080一看是我 Docker Desktop 里挂着的一个测试容器占的端口跟 OpenClaw 没有半点关系。所以看到端口占用时先确认进程归属别为了清理 OpenClaw 把不相干的服务也杀了。6.3 误删关键数据的补救建议手动卸载最大的风险就是误删。我建议在动手之前至少做两层准备第一层把~/.openclaw整个目录打包备份tar -czf openclaw-backup.tar.gz ~/.openclaw第二层把 Windows 侧的相关目录也复制一份到安全位置Copy-Item $env:APPDATA\openclaw D:\backup\openclaw-appdata -Recurse如果已经误删且没有备份那要看删的是什么。配置文件和日志基本救不回来模型权重如果是从 Hugging Face 或 ModelScope 下载的可以重新下载只是费时间如果是 Teams 的 bot 凭据去 Azure 门户看有没有保留历史版本没有的话只能重建。我在实际清理过程中发现还有一个很容易忽略的恢复点WSL2 的 ext4.vhdx 虚拟磁盘文件。如果你之前没有执行过wsl --unregister即使文件被删了底层磁盘块可能还没被覆盖理论上可以用 ext4 恢复工具抢救。但实操性价比极低与其赌运气不如一开始就做备份。6.4 彻底卸载后要不要处理 WSL 发行版最后回答一个很多人纠结的问题OpenClaw 卸载完之后要不要把整个 WSL 发行版注销我的看法是如果这个 WSL 发行版上只有 OpenClaw那注销一了百了最干净。执行wsl --shutdown wsl --unregister Ubuntu但如果有其他项目共享这个发行版就别动发行版级操作只清理 OpenClaw 相关目录和配置即可。之前看到一个案例用户为了卸载 OpenClaw 直接注销了整个 Ubuntu 发行版结果里面还跑着一个 MySQL 测试库几星期的工作量直接归零。这种损失完全可以避免——手动卸载本身就分发行版级和应用级两种按需选择就好。说回我自己这边的操作我最后保留了两个 WSL 发行版其中一个专门用于跑 OpenClaw 相关实验所以卸载时只清了应用级的数据发行版本身留着用于后续其他项目另一个全新发行版则完全和 OpenClaw 无关。这样既避免互相污染又不至于因为一次卸载就损失整个 Linux 环境。手动卸载这件事最核心的思维就是官方命令只能处理它预期你安装出来的样子你真正安装成什么样子只有你自己清楚。把每一条自定义部署的路径、每一个手动加的配置都当作残留候选逐个确认、逐个清理才能真正做到干净卸载。