接到“卸载 openclaw”这个需求说明你已经体验过部署一套 AI 助手底层框架的滋味了 —— 从 WSL 环境、Node.js 工具链到 Windows Companion、Ollama 模型库前前后后装了一堆组件。结果用下来要么发现它和你的实际工作流不匹配要么就是折腾完新鲜劲过了想把系统恢复干净。不少人的第一反应是“直接把 openclaw 的文件夹删了不就行”但真实情况远没有这么简单。如果你曾经按部署教程装过 WSL 发行版、注册过随笔、配合过 Ollama 拉模型那卸载就不是“删除文件夹”能解决的而是一整套组件的反安装过程。这篇博文不教你安装专门讲卸载。我会按我踩坑的路径把 openclaw 在你机器上留下的每一种痕迹都列出来然后给出 Windows、WSL、Android Termux 环境下的完整卸载步骤最后再讲几个最容易在卸载过程中翻车、但网上很少有人提到的细节。文章内容基于我实际处理类似开源 AI 工具卸载的经验结合 openclaw 常见的部署方式尽量做到每一步都能照着敲。1. 动手卸载之前先给 openclaw 做一次“家底盘点”我们在卸载一个多组件工具之前最忌讳的就是只盯着主要程序目录。openclaw 这一类项目尤其是参考了 WSL Node.js Ollama 部署方案的 AI 助手通常会把大量逻辑和数据散落在系统的各个角落。如果你只删一个安装目录用过几天之后会不断发现残留痕迹开机自启项还在、WSL 发行版还在占用几个 GB、配置文件里的 API Key 还躺在你的用户目录下。我习惯把这一步叫“卸载前的家底盘点”。就像搬家之前你得先列一份所有家具和物品的清单才能知道要请几辆车、哪些要先拆。卸载 openclaw 也一样先把它的组件分布搞清楚之后的每一步才不容易漏。1.1 一张表看清 openclaw 在你机器上的组件分布下面这张表是我根据 openclaw 常见的部署方案整理的组件位置参考不同人的安装方式会有差异但大致不会超出这张表的范围组件类型常见位置Windows 侧常见位置WSL/Linux 侧说明WSL 发行版容器由wsl --install注册的发行版例如Ubuntu-22.04/home/用户名/openclaw或类似源码目录这是最大的一块可能占几个 GBNode.js 全局命令行工具npm 全局目录npm root -gWSL 内部或 Windows 上通过 nvm 管理以openclaw命名的命令行入口Windows Companion安装到用户级或系统级的应用不涉及后台驻留提供 Windows 侧的集成Ollama 模型Windows 版 Ollama 的模型目录WSL 内ollama list可见可能拉取过小模型或大模型占用单独一块空间配置与数据目录%USERPROFILE%\.openclaw、%APPDATA%\openclaw~/.openclaw、~/.config/openclaw对话记录、技能配置、API 密钥、日志都在这里开机自启与服务Windows 任务计划程序、注册表 Run 键systemd 服务或 WSL 内的启动脚本卸载后最常见的残留你对照这张表先把机器上的对应位置挨个看一眼确认哪些存在哪些是空的。特别是配置目录里通常藏着 API Key哪怕你打算重新安装也建议先备份否则卸载后一旦误删就只能重新申请密钥。1.2 先停进程再动手不要在 openclaw“运行中”的时候做反安装我最初卸载这类工具时犯过一个低级错误openclaw 的进程还在后台跑就直接执行了 WSL 发行版注销命令。结果弹了一堆“目标忙”的报错Windows Companion 也在试图重新拉起服务最后不得不重启两次才算清理干净。正确的顺序应该是在 Windows 上打开任务管理器结束所有带openclaw字样的进程包括 Companion 主程序、托盘进程和命令行 Node 进程。打开 PowerShell先查看 WSL 当前状态和运行中的发行版wsl --status wsl -l -v这条命令能看出 WSL 环境是否正常以及哪些发行版处于 Running 状态。停止所有 WSL 虚拟机这一步很关键wsl --shutdownwsl --shutdown会终止所有正在运行的 WSL 发行版避免文件锁冲突。我建议你养成习惯任何涉及删除 WSL 相关目录的操作之前先执行这一条能少踩一半的坑。如果 openclaw 在 Termux 环境还有驻留进程也先pkill -f openclaw处理掉。把这些进程全部停干净之后再往下走你会发现卸载过程的报错率低很多。现在网上很多“卸载后残留占用”的求助帖其实都是这一步没做好。2. Windows WSL 环境的标准卸载流程一条命令一条命令敲当你说“卸载 openclaw”最核心的目标就是把这个工具从你的日常开发环境中彻底移除。这一章我从 WSL 发行版、Node.js 全局工具、Windows Companion 三个层面展开这也是 openclaw 在 Windows 上最常见的三种存在形式。2.1 从 WSL 发行版开始清理wsl --unregister 是真正的“大扫除”如果你当初是按“WSL openclaw”方案部署的那一大坨空间都花在 WSL 发行版上。常见的做法是 openclaw 直接跑在一个专门的 WSL 发行版里或者跑在 Ubuntu 发行版中、把 openclaw 当作普通用户程序。首先要明确你用的是哪种方式。打开 PowerShell 输入wsl -l -v输出里如果有一个发行版名字里直接带openclaw或者你记起来当初就是为它创建的这个发行版那最简单粗暴的卸载方式就是注销整个发行版wsl --unregister openclaw这里的openclaw换成你实际看到的发行版名称。这个命令会把发行版从 WSL 的注册表里移除同时把虚拟磁盘文件也一并删掉空间立刻释放。注意它是不可逆的所以如果你有任何重要数据留在里面必须先备份出来。如果你用的是普通 Ubuntu 发行版openclaw 只是装在普通用户目录里那就不能注销发行版否则会误伤其他项目。这时候你要在 WSL 内部手动清理pkill -f openclaw rm -rf ~/openclaw rm -rf ~/.openclaw rm -rf ~/.config/openclaw同时还要把 openclaw 可能注册的服务或启动脚本移除。如果你当初配过 systemd 服务检查一下systemctl --user list-units | grep -i openclaw systemctl --user disable openclaw.service rm -f ~/.config/systemd/user/openclaw.service这一步我不建议跳过 systemctl 检查因为很多部署教程会把 openclaw 配置成后台运行的服务删了目录但服务还在WSL 每次启动都可能尝试去拉起一个已经不存在的程序日志里经常报错。2.2 清理 Node.js 侧的 CLI 工具确认全局包并卸载干净openclaw 的命令行入口通常在 npm 全局包里。不管当初是通过npm install -g openclaw还是别的包名安装的卸载时都需要反向操作。先列出全局安装了哪些包确认包名和版本npm list -g --depth0如果你在输出里找到了和openclaw相关的包名再执行卸载npm uninstall -g 包名这里有个细节需要注意openclaw 的实际 npm 包名不一定是openclaw有些项目主包叫别的名字CLI 入口又是另一个名字。你可以用命令where openclawWindows或which openclawWSL / Termux定位一下命令行所在目录基本上也就能顺藤摸瓜找到对应的包名。如果你用的是 pnpm 或 yarn命令要换成pnpm remove -g openclaw yarn global remove openclaw我遇到过一种情况全局包明明卸载成功了但openclaw命令还能输出版本号。这通常是因为还有另一个残留的可执行文件躺在非默认的 Node 全局目录里。这时候直接找到where openclaw给出的路径手动删除对应目录即可。卸载完成后再敲一次where openclaw如果输出提示找不到命令那才是真的清干净了。2.3 卸载 Windows Companion 并清理开机自启openclaw 在 Windows 侧还有一个 Companion 组件它是一个后台驻留的本地应用用来和主程序协作提供系统托盘、快捷键、自动启动等功能。这个组件的卸载相对直观但有个容易忽略的点它可能会把自己注册到启动项里即使卸载主程序后启动计划还会尝试运行残留文件。标准做法是打开 Windows 设置进入“应用 已安装的应用”搜索openclaw或Companion点击卸载。如果没有独立的卸载入口就用安装时配套的卸载脚本一般在安装目录里有uninstall.exe或者uninstall.js。打开任务管理器切到“启动”选项卡查看有没有 openclaw 相关的启动项如果有右键禁用并定位到启动脚本所在路径。打开“运行”对话框输入taskschd.msc查看任务计划程序库中有没有 openclaw 相关的计划任务一次性全删掉。另外我还建议顺手检查一下 Windows 服务sc query | findstr /i openclaw如果服务列表里有残留服务项可以用管理员 PowerShellsc.exe delete OpenClawCompanion这一套做完Windows 侧的可见组件基本就清完了。但别急着宣告胜利真正容易漏掉的还在后面。3. Termux 手机版、Ollama 模型库容易被当作“配置残留”放过的隐形尾巴很多人以为 openclaw 只装在电脑上其实它也能通过 Termux 部署到 Android 手机上。如果你试过网上流传的“Termux 安装 openclaw 手机版”那类方案那么手机上的数据也需要单独清理。与此同时Ollama 本地模型库又是一个很容易被忽略的大块头 —— 模型文件动辄几个 GB你卸载了 openclaw模型却还占着空间。3.1 Termux 端的完整卸载pkill 加目录删除Termux 环境下的 openclaw 本质是一个跑在 Android 用户空间里的 Node.js 应用。清理步骤相对简单但如果之前配过 Termux:Boot 自启脚本就需要多检查一层。在 Termux 终端里执行pkill -f openclaw pm uninstall --user 0 com.termux 2/dev/null || true这里要停一下pm uninstall那行是卸载整个 Termux 的除非你确定自己只想为 openclaw 清理环境而不再使用 Termux否则不建议执行这整条命令。如果只是要清理 openclaw删除它的目录就足够了rm -rf ~/openclaw rm -rf ~/.openclaw rm -rf ~/.config/openclaw rm -rf $PREFIX/var/lib/openclaw如果你之前通过 Termux 的包管理安装过 openclaw 的组件也可以用pkg uninstall openclaw让我特别提醒一句Termux 环境下~/就是应用数据目录敏感数据全部都在 Android 应用私有空间里如果你卸载了 Termux 本身这些数据就会被系统回收不再需要额外的手动销毁。但我见过一个反例有人手机上 Termux 装了 openclaw后来只是从桌面加载了 openclaw 的快捷方式并没有卸载 Termux结果半年后查存储空间发现 openclaw 目录还占了好几百 MB。所以如果你长期不用最好还是回到 Termux 里把专门目录删掉别只卸载桌面的快捷方式。3.2 Ollama 本地模型库卸载 openclaw 前先决定模型去留openclaw 支持通过 Ollama 接入本地算力很多人在部署时顺手就ollama pull了一些模型。这些模型文件并不属于 openclaw 本身所以卸载 openclaw 后 Ollama 依然会把模型存在磁盘里。清理前先看本地拉了哪些模型ollama list输出会显示模型名、标签和大小。比如NAME ID SIZE MODIFIED qwen2.5:7b xxxxx 4.7 GB 2 weeks ago llama3.2:3b xxxxx 2.0 GB 1 month ago如果你想彻底释放空间逐个删除ollama rm qwen2.5:7b ollama rm llama3.2:3b也可以一次性删除全部模型ollama list | awk {print $1} | tail -n 2 | xargs -I {} ollama rm {}这块归 openclaw 吗严格讲不算。但很多人的实际情况是“为了 openclaw 才装 Ollama”所以卸载 openclaw 后把模型删掉、设备彻底清爽是一个合理的选择。有一点我要提醒如果 Ollama 是你其他工具也在用的本地推理服务那不要贸然删除模型否则会影响别的项目。这时候只需要确认 openclaw 没有在 Ollama 里残留自定义的Modelfile或拉取配置就行模型本身可以留着。3.3 配置数据与对话记录的备份和销毁别把 API Key 留在用户目录里配置和日志是卸载过程中最容易产生隐私风险的部分。openclaw 的配置里通常包含 API 服务的访问密钥、鉴权 token、以及大量对话历史。如果你要彻底卸载不能只想着“我删掉程序就行”这些数据文件如果没清理干净对隐私是长期的隐患。建议现在先做一份备份放到一个安全的地方Copy-Item -Recurse $env:USERPROFILE\.openclaw D:\backup\openclaw_config备份之后如果你确定不再需要这份数据再执行删除。Windows 侧常见的配置位置是%USERPROFILE%\.openclaw和%USERPROFILE%\.config\openclawWSL 侧是~/.openclawTermux 侧是~/openclaw。还需要检查环境变量。有些部署会把 API Key 写进用户环境变量[System.Environment]::GetEnvironmentVariable(OPENCLAW_API_KEY, User) [System.Environment]::GetEnvironmentVariable(OPENCLAW_API_KEY, Machine)如果输出非空记得删除[System.Environment]::SetEnvironmentVariable(OPENCLAW_API_KEY, $null, User)这里我想多说一句备份不是可选项而是必要操作。因为它不仅包含密钥还包含你之前调教出来的技能配置、自定义行为规则。如果你只是“暂时不用了”而非“彻底放弃 openclaw”这份备份能让你以后迁移到其他环境时省掉几个小时的重配时间。删除前做一次压箱底备份永远是最稳妥的。4. 卸载半途最容易“卡死”的现场WSL 状态异常、文件占用与权限报错这一章是我最想写的部分。因为网上关于 openclaw 卸载的提问十个里有八个都卡在这些“看似很小、实际致命”的问题上。我分别拆解三种翻车现场并给出排查思路。4.1 “无法安全验证 SL2 环境”背后的根因和应对策略有网友搜到一条热词“openclaw 无法安全验证 sl2 环境。请在 powershell 中运行 wsl -- status”。这其实是在安装或运行 openclaw 过程中会遇到的一个 WSL 环境问题。可真正到了卸载环节它同样会跳出来 —— 尤其是当你试图用wsl --unregister注销发行版或者执行wsl --shutdown时PowerShell 却提示“无法安全验证 SL2 环境”让你无所适从。这个报错一般是三个原因叠加的结果WSL 没有正确初始化或者版本配置有问题比如 WSL 内核未更新。当前终端进程正在被 WSL 相关进程占用导致新的 WSL 命令无法验证运行环境。WSL 1 和 WSL 2 的参数冲突某些发行版仍使用旧版本的内核接口。应对方法很直接先用管理员身份打开 PowerShell。wsl --update wsl --status wsl --shutdown如果wsl --status依然报错可以重启一次 Windows 的 LxssManager 服务net stop LxssManager net start LxssManagerLxssManager是 WSL 的核心服务相当于 WSL 的驱动器。很多 WSL 环境异常在重启这个服务后都会恢复。之后再重新跑一次wsl -l -v大概率就能正常列出发行版列表继续执行卸载命令。如果你之前看过的教程里有“无法安全验证”的提示十有八九就是这条思路能解决。4.2 文件占用和权限拒绝谁说管理员权限就一定能删干净卸载中第二个高频翻车点是文件被占用。即使你开着管理员 PowerShell依然可能遇到“另一个程序正在使用此文件”的提示。通常分两种openclaw 的后台进程还在运行占用着安装目录或配置目录。WSL 发行版虚拟磁盘仍然挂载着文件系统里的目录无法被 Windows 侧进程直接删除。针对第一种情况可以先用任务管理器确认node.exe或openclaw.exe进程是否还在也可以更精细地从 PowerShell 查Get-Process | Where-Object { $_.ProcessName -match openclaw|node } | Stop-Process -Force注意Node 进程可能不止 openclaw 一个。如果你机器上有其他 Node 服务在跑别用这条命令无差别终止所有 node 进程。应该找到带 openclaw 路径的那个进程再精确停止Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match openclaw } | Select-Object ProcessId, CommandLine看到具体的进程 ID 后针对性地 KillStop-Process -Id 进程ID -Force针对第二种情况也就是 WSL 发行版的虚拟磁盘挂载占用了目录解法是先执行wsl --shutdown确保所有 WSL 发行版下线再去执行wsl --unregister注销。如果注销时报权限错误一般是因为你的 Windows 用户不是该发行版的所有者或者发行版由另一个管理员账户创建。此时用管理员 PowerShell 重试往往就能通过。4.3 PowerShell 执行策略与命令找不到一个被忽略的“隐形故障”还有一个问题经常在卸载流程中途爆发你的 PowerShell 命令明明敲对了但系统提示“无法加载文件因为在此系统上禁止运行脚本”。这其实和执行策略有关不是命令本身的错误。如果你看到类似这样的报错所在位置 行:1 字符:1 .\uninstall.ps1 ~~~~~~~~~~~~~ 无法加载文件 xxx.ps1因为在此系统上禁止运行脚本。常规解法是在管理员 PowerShell 中放开当前用户的执行策略Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser这条只影响当前用户不涉及系统级修改对日常开发来说足够安全。我也遇到过另一个更容易让人懵的场景执行npm uninstall -g之后再执行openclaw --version系统居然还能输出版本信息。这不是卸载失败而是你已经双击进入了别的安装路径下的可执行文件。此时用where.exe openclaw查看具体路径再手动定位删除残留文件比在npm里反复折腾更有效。之前我见过有人在“npm uninstall”和“which openclaw”之间反复横跳耽误了半天其实就是因为残留副本藏在另一个目录里。5. 卸载完成不等于“干净”几条自查命令与后续取舍流程做到这一步openclaw 的主体已经从你的系统里移除了。但“卸载完成”这四个字我建议把它定义为你执行过一轮完整的残余检查之后。这一章我给出一套可以直接复制的五步检查清单并聊聊卸载后系统该不该“一刀切”的问题。5.1 一套五步检查清单验证 openclaw 是否真的离开下面这套检查我每次卸载工具都会用不只是 openclaw检查命令行入口是否消失where.exe openclaw输出“找不到文件”或提示命令不存在说明 Windows 侧的 CLI 已清除。在 WSL 里输入which openclaw也应该没有输出。检查 WSL 发行版列表wsl -l -v如果这里清空了或者只剩余你不打算动且确实与 openclaw 无关的发行版就说明这一层清理成功。检查进程和服务Get-Process | Where-Object { $_.ProcessName -match openclaw } sc query | findstr /i openclaw进程列表为空、服务列表无匹配才算过。检查常见数据目录是否消失 用文件资源管理器依次查看%USERPROFILE%\.openclaw、%APPDATA%\openclaw、%USERPROFILE%\.config\openclaw。存在就删除不存在就跳过。检查开机自启项和环境变量 在任务管理器的“启动”栏里确认没有 openclaw在“系统属性 环境变量”里确认没有残留的OPENCLAW_API_KEY这类项。把这五步走完你的机器基本可以宣告干净了。如果只是想“暂时停用”而不是“彻底删除”那跳到最后一步时只需要禁用启动项即可不用删除配置目录。5.2 这部分值得想清楚Node.js、Ollama、WSL 是否也要一并卸载很多人卸载 openclaw 后顺手就要卸载 Node.js、Ollama 甚至整个 WSL我劝你三思。卸载工具是一门“关注代价”的活儿不值得为了收拾残局把你已经在用的基础设施也拆了。我的判断标准很简单如果你装 Node.js 的唯一目的就是跑 openclaw那卸载掉它没问题。卸载时尽量用 nvm 卸载对应版本或者去“已安装的应用”里卸载 Node.js然后手动清理%APPDATA%\npm缓存和%APPDATA%\npm-cache。Ollama 同理。如果它是你本地跑模型的主力工具建议保留。毕竟好几 GB 的模型重新拉取也要时间。如果你确实不打算再做任何本地推理就可以先删模型、再卸载 Ollama 本体。WSL 的话我更不建议卸载。即使你没有 openclawWSL 对开发环境的价值依然很大。你完全可以保留一个干净的 Ubuntu 发行版以后用得上。只为 openclaw 装的额外发行版注销掉就好。这个取舍对很多人来说比技术操作更难。但我的经验是卸载一个工具最好的状态是把它造成的增量影响消除掉而不是把整个底层环境都推倒重来。5.3 如果只是嫌 openclaw 太重有没有必要“彻底离场”最后聊一个我自己的使用体会。不是所有人都需要走到“卸载”这一步有些人其实是因为部署 OpenClaw 时碰上了环境问题、接口配置太麻烦才动了卸载的念头。如果对 openclaw 的能力还算认可只是嫌它维护成本高你完全可以选择更轻量的接入方式。比如你原本为了跑本地模型装了 Ollama但 openclaw 对所有推理任务都走外部 API不走本地算力那你完全可以裁剪掉 Ollama 这层。又比如你原本为了 GUI 集成装了 Windows Companion后来发现只想要命令行交互那 Companion 也可以单独卸掉保留核心 CLI。这一章不是劝你别卸载也不是推荐某个替代工具而是想告诉你卸载之前先定位一下自己的真实需求再决定是全量卸载还是按需裁剪。根据我个人处理工具残留的经验最高效的做法永远是“备份 → 停进程 → 逐层清 → 自查”。对 openclaw 来说WSL 发行版、Node.js 全局包、Windows Companion、Ollama 模型和配置文件都按这条主线走每一步都有明确命令可查。最容易被忽略的就是配置目录里的 API Key 和用户目录下的日志残留 —— 这些决定了你的卸载是不是真的干净。删得越彻底以后想回归时反而更容易因为你手里还留着一份完整备份随时可以从熟悉的配置继续。