OpenClaw卸载不干净？一份从进程到缓存的完整清理指南

OpenClaw这种跑在大模型边上的自动化助手，装的时候能折腾一整天——git clone、npm install、docker compose up、配Ollama、写API Key，每一步都有坑。等你想卸载的时候才发现，这坑比安装还深。我在Windows和Linux上分别部署过OpenClaw，后来因为换方案要清理环境，光是卸载就来回折腾了三个晚上，最后总结出这么一套从程序文件到模型缓存、从系统服务到环境变量的完整卸载流程。这篇就是给那些正在被“卸载OpenClaw”折磨的人看的，不管你是docker跑的、npm装的还是源码clone的，照着思路走，基本能把自己的机器恢复成部署前的样子。

1. 安装方式决定拆卸顺序：先认清楚OpenClaw到底装在哪

很多人卸载不干净，不是因为卸载动作没做，而是因为压根不知道自己当时把OpenClaw装到哪了。我自己第一次卸载时就踩了这个坑：以为它是npm全局包，npm uninstall跑完就觉得完事，结果发现还有一整套Docker容器在后台跑着，端口还占着，等于白忙活。

1.1 常见部署形态与落盘位置

在Windows/Linux上部署OpenClaw，我见过最多的是这么几种形态，你可以对照一下自己属于哪种：

判断自己属于哪种方式，最快的方法是执行这几条命令：

# 看有没有compose文件 ls docker-compose.yml # 看全局包里有没有openclaw npm list -g --depth=0 # 看有没有系统服务 systemctl status openclaw # 看有没有相关进程 ps aux | grep -i openclaw

Windows下对应的是在PowerShell里跑npm list -g --depth=0、sc query type= all state= all | findstr /i openclaw，或者直接看Docker Desktop的容器列表。

1.2 卸载前必须备份的三样东西

不管用什么方式安装，有一样数据是删了就很难重建的：对话记录。OpenClaw这种Agent类工具会把对话历史、任务执行日志、技能配置存到本地数据库或配置目录里。如果你之后还想参考之前的自动化流程，或者打算换一种部署方式接着用，先备份：

# Linux/macOS mkdir -p ~/openclaw-backup cp -r ~/openclaw/data ~/openclaw-backup/ cp ~/openclaw/.env ~/openclaw-backup/

# Windows PowerShell Copy-Item -Path C:\openclaw\data -Destination D:\backup\openclaw -Recurse Copy-Item -Path C:\openclaw\.env -Destination D:\backup\openclaw\

如果你是用Docker跑的，更好的做法是直接把整个volume导出成压缩包：

docker run --rm -v openclaw-data:/data -v $(pwd):/backup alpine tar czvf /backup/openclaw-data.tar.gz -C /data .

备份时要留意.env文件里的API Key，导出的压缩包如果准备上传网盘或共享给别人，建议先加密或至少把.env单独挑出来另外存放。

1.3 先停用、别急着删除的理由

我的习惯是：卸载前先“停用”观察几天。把服务停了、把端口释放了，但是数据和文件先保留。确认自己确实不需要它了，再走完整的删除流程。这不只是保险起见，还有个原因是有些项目依赖OpenClaw的API或者它拉起的本地模型服务，一旦你直接删掉程序文件，关联项目启动时立刻报错，到时候你想找回来都难。

停用的操作比卸载简单得多：Docker方式跑一下docker compose down（注意别加-v，加上-v就会连数据卷一起删了）；systemd方式跑sudo systemctl stop openclaw；源码方式直接停掉node进程。观察几天，确认没有影响，再进入下面的正题。

2. Windows卸载实操：三层清理缺一不可

Windows上卸载OpenClaw和Linux不一样，它至少分三层：第一层是应用本身，第二层是Windows系统层面的自启动项、注册表、环境变量，第三层是WSL2里可能残留的Linux侧文件。只处理第一层是最常见、也是最典型的半吊子卸载。

2.1 应用层清理：按部署方式拆解

如果你用的是Docker Desktop跑容器，先在PowerShell里把OpenClaw相关容器列出来：

docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Status}}" | findstr /i openclaw

确认没有业务依赖之后，再停掉并删除：

# 先进入compose文件所在目录，或者用 -f 指定路径 docker compose -f C:\openclaw\docker-compose.yml down -v

这里-v要慎重。它会把compose文件里声明的volumes一并删除。如果你之前把对话数据直接存在容器数据卷里，而且没做备份，那-v就是致命操作。稳妥的做法是先docker compose down不带-v，然后单独把volume里的数据复制出来，最后再删volume。

如果你用的是npm全局安装，查看并卸载：

npm list -g --depth=0 npm uninstall -g openclaw

如果是源码clone的目录，先确认进程再删目录：

tasklist | findstr /i node taskkill /PID <进程ID> /F Remove-Item -Recurse -Force C:\openclaw

用taskkill时要小心，它会杀掉所有符合过滤条件的进程，一般按PID精确处理更安全，不然同一个node进程可能跑着别的服务，你一起结束了就麻烦了。

2.2 Windows系统层残留：自启动项、注册表、任务计划

OpenClaw这类工具为了方便使用，经常会在安装时注册自启动。最常见的四个位置：

• 启动文件夹：%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup
• 当前用户注册表Run键：HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• 本地机器注册表Run键：HKLM\Software\Microsoft\Windows\CurrentVersion\Run
• 任务计划程序

PowerShell里逐项检查：

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /s | findstr /i openclaw reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /s | findstr /i openclaw schtasks /query /fo LIST /v | findstr /i openclaw sc.exe query type= all state= all | findstr /i openclaw

找到相关项后，删除方式按类型区分：启动文件夹直接用Remove-Item删快捷方式；注册表用reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v OpenClawStart /f；任务计划用schtasks /delete /tn "任务名" /f；服务用sc.exe delete 服务名。

这里有个很容易踩的坑：有些安装脚本不会在注册表里写OpenClaw这个名字，而是写在clawdbot、openclaw-agent之类的名字下。如果上面几条命令都没搜到，可以只搜claw或agent关键词，再结合路径、命令行参数判断是不是它。另外，搜不到就直接跳过，不要为了“彻底”去手动扫描整个注册表，那反而容易误删系统配置。

2.3 WSL2中的残留：Windows卸载最容易漏掉的部分

Windows上还埋伏着第三层，就是WSL2。如果你当初是在WSL发行版里部署的OpenClaw，或者在Docker Desktop配置过WSL集成，那么就算Windows侧全部清理干净，Linux侧的目录、进程和数据可能还占着好几GB空间。

先看有没有相关发行版：

wsl --list --verbose wsl --status

进入发行版检查常用残留路径：

wsl -d <发行版名> -- bash -lc "ls -d ~/openclaw ~/.openclaw ~/.config/openclaw /opt/openclaw 2>/dev/null"

确认里面没有其他重要数据后，直接删除：

wsl -d <发行版名> -- bash -lc "rm -rf ~/openclaw ~/.openclaw ~/.config/openclaw /opt/openclaw"

如果当初创建这个WSL发行版就是为了跑OpenClaw，里面没有别的东西，也可以注销整个发行版：

wsl --shutdown wsl --unregister <发行版名>

这里必须重复一遍警告：wsl --unregister会把这个发行版里的所有数据全部清空，包括你日常用到的其他Linux环境。如果你拿不准，宁可多花几分钟进发行版里手工删目录，也别图省事直接unregister。

3. Linux卸载实操：进程、包管理、配置按顺序来

Linux上的卸载思路可以概括成四步：先停进程，再卸应用本体，再清配置目录，最后查环境变量和定时任务。顺序很重要，因为进程可能还在写文件，你先把文件删了，磁盘空间不一定释放，还容易出现各种奇怪的错误提示。

3.1 第一步：让所有OpenClaw进程先停下来

如果是systemd管理的系统级服务：

sudo systemctl stop openclaw sudo systemctl disable openclaw

如果是systemd用户级服务：

systemctl --user stop openclaw systemctl --user disable openclaw

如果你当初用了pm2这类进程守护工具：

pm2 stop openclaw pm2 delete openclaw pm2 save

最后用兜底命令检查有没有漏网进程：

ps aux | grep -i openclaw ss -tlnp | grep -E '3000|4000'

端口号这里不一定准，换成你docker-compose.yml或config文件里实际配置的就行。如果搜索进程时没发现openclaw，但端口还占着，多半是有docker容器没停或者systemd服务被重启拉起了。这种情况下继续排查systemctl list-units | grep openclaw和docker ps -a。

3.2 第二步：按部署方式卸载应用本体

Linux下的卸载命令要分场景走：

# npm/pnpm全局安装 npm uninstall -g openclaw # 如果带scope，先查名字再删 npm list -g --depth=0 pnpm remove -g openclaw # Docker容器方式 docker ps -a | grep openclaw docker compose -f /path/to/docker-compose.yml down -v docker images | grep openclaw docker rmi <镜像ID> docker volume ls | grep openclaw docker volume rm <卷名> # git clone源码方式 rm -rf ~/openclaw

如果是走pip或conda装的Python版本，命令则是：

pip uninstall openclaw conda env remove -n openclaw

需要说明的是，包管理器的全局目录不要手动去删node_modules里的文件，直接用npm uninstall即可，它会自动处理依赖引用关系，手动删反而可能破坏其它全局包。

3.3 第三步：家目录与系统目录中的配置文件

这一步往往是卸载主体完成后最常被漏掉的。OpenClaw运行时会往家目录写配置、日志和数据库文件，常用路径大致是这些：

• ~/.openclaw
• ~/.config/openclaw
• ~/.local/share/openclaw
• ~/.cache/openclaw
• /opt/openclaw（如果你之前有系统级安装）
• /var/lib/openclaw、/var/log/openclaw

清理前还是先看一眼有哪些目录实在存在：

ls -d ~/.openclaw ~/.config/openclaw ~/.local/share/openclaw ~/.cache/openclaw /opt/openclaw 2>/dev/null

确认没有自己需要保留的数据后，一次性删除：

rm -rf ~/.openclaw ~/.config/openclaw ~/.local/share/openclaw ~/.cache/openclaw

如果个别目录你需要留下，比如想保留日志进行分析，那就先cp到别处再删原目录，不要自己赌它不重要。

3.4 第四步：环境变量、shell别名与定时任务残留

安装脚本有时会把OpenClaw的bin目录写进PATH，或者添加OPENCLAW_HOME之类的环境变量。检查这些地方：

grep -i openclaw ~/.bashrc ~/.zshrc ~/.profile /etc/environment /etc/profile.d/* 2>/dev/null

如果确实搜到了，用文本编辑器打开对应的文件删掉那一行，不建议直接写一条sed命令全自动删除，因为有些行可能是注释或者只是一处极短的路径片段，直接替换容易误伤其他配置。

定时任务也不能漏：

crontab -l | grep -i openclaw

有的话执行crontab -e，把对应行删掉保存。另外还要检查一下系统级cron目录，/etc/cron.d和/etc/crontab里可能也藏着配置。

4. 模型与缓存清理：真正占空间的往往不是程序本身

程序本体其实没多大，真正让磁盘轻松少掉十几二十GB的，是模型权重文件和安装缓存。

4.1 Ollama模型：几个GB到几十GB的隐藏占用

OpenClaw这类大模型应用经常配合本地Ollama来跑推理。Ollama的模型默认放在~/.ollama/models，一个7B参数的量化模型大概要4到5GB，更大的模型十几GB很常见。卸载OpenClaw不会自动清理这些模型。

先看看本机下载了哪些模型：

ollama list

输出里会列出模型名、标签和大小。判断哪些是OpenClaw专用、哪些是你还在跑其他任务要用的，然后精确删除：

ollama rm qwen2.5 ollama rm llama3.1

这里我特别建议：如果你平时还用Ollama跑其他项目，模型不要全删。我见过有人卸载OpenClaw时顺手把Ollama整个数据目录都清了，结果其他项目跑起来全部报模型缺失，又得重新下载，白白浪费时间和带宽。

4.2 Docker镜像与npm缓存：另一个重量级来源

Docker跑OpenClaw时，镜像本身、构建缓存和数据卷可能占掉很多空间。清理时先看体积：

docker images | grep openclaw docker system df

确认要删哪些镜像，用docker rmi删除对应的镜像ID。数据卷用docker volume rm一个个删，不要用docker volume prune一把梭，那会把其他容器也在用的卷全部清掉。

npm和pnpm的缓存也要查：

ls ~/.npm/_npx # npx临时包可能残留 pnpm store prune # pnpm的全局store清理

~/.npm/_npx目录里经常堆着一堆临时安装包，如果OpenClaw是通过npx openclaw启动过，这里大概率有残留，直接在确认后删除对应目录就能腾出几百MB。

4.3 别用一把梭的命令清空全部缓存

写到这里必须提醒一句：npm cache clean --force、docker system prune -a、rm -rf ~/.ollama这种命令看起来很解气，但副作用极大。npm cache clean --force会清掉npm整个缓存，后续装任何项目都得重新下载依赖；docker system prune -a会把所有没在运行的镜像全删了，你机器的其他容器环境直接被重置到最原始状态。我的原则是：只清理跟OpenClaw明确相关的文件，绝不顺手清全局缓存。

5. 卸载完成不代表干净了：一份可执行的自检清单

很多时候你以为卸载完了，其实只是表面功夫做完了。我建议按照下面的顺序逐项自检，任何一个步骤没过关，都要回头查一下对应的残留。

5.1 命令行与包管理器层面验证

# Linux/macOS which openclaw npm list -g --depth=0 2>/dev/null | grep -i openclaw

# Windows PowerShell Get-Command openclaw -ErrorAction SilentlyContinue npm list -g --depth=0 | Select-String -Pattern openclaw

预期结果是：command not found，或者没有任何匹配输出。如果还能找到命令，说明某个目录还留在PATH里或者全局包没删干净。

5.2 服务、端口与自启动项验证

检查服务和端口字面意义上的“没有”：

systemctl status openclaw systemctl --user status openclaw ss -tlnp | grep -E '3000|4000'

sc.exe query type= all state= all | findstr /i openclaw netstat -ano | findstr 3000 schtasks /query /fo LIST /v | findstr /i openclaw

预期结果是服务不存在、端口没有监听。如果端口还在，先查是什么进程占用，再判断是不是OpenClaw的残留；如果是stoppped状态但服务还在，别管，直接删service文件并执行daemon-reload。

5.3 配置目录与模型文件残留验证

检查目录是否存在：

# Linux ls -d ~/.openclaw ~/.config/openclaw ~/.local/share/openclaw ~/.cache/openclaw 2>/dev/null # Windows PowerShell Test-Path $HOME\.openclaw Test-Path $HOME\.config\openclaw

模型文件检查：

ollama list

预期结果是所有OpenClaw相关路径都返回不存在或空值。下面这个检查清单可以打印出来对照着勾：

6. 卸载OpenClaw的常见坑与我的建议

最后聊几个我实际踩过的坑，有些是热词里也频繁出现的，这里一并写清楚。

6.1 关于“OpenClaw无法安全验证”：残留服务的排查思路

如果你在Windows上已经“卸载”了OpenClaw，但某个检测工具或相关应用仍然提示“OpenClaw无法安全验证”，不用怀疑，八成不是卸载工具的问题，而是还有残留的东西在运行。我遇到过的情况有三种：

第一种，WSL里还有服务进程在跑。Windows侧的程序删了，但WSL发行版里的OpenClaw还挂在后台，端口映射也还在，自然会被检测到。解决方式就是回到2.3，进WSL按Linux流程清一遍。

第二种，Docker容器只是被停止，没有被删除。docker ps -a里还能看到容器记录，Docker Desktop重启后它又自动启动了。解决方式是docker rm把容器删掉，注意是删容器，不只是停止。

第三种，注册表里的Run键还在，开机又把某个脚本拉起来了。处理方式回到2.2，注册表和启动项彻底清理干净。

如果上述都查过了还是报验证失败，那大概率是你机器上还有另一个Agent工具与OpenClaw有关联，或者运行日志里写了固定的校验路径。这时候把检测工具的日志打开，直接看它访问的是哪个路径或端口，顺着地址定位残留，比瞎猜快得多。

6.2 我最后建议的卸载顺序

经过这几轮折腾，我自己现在卸载这类大模型工具的标准动作是固定顺序的：

• 先停用，导出配置、对话数据和API Key备份；
• 再卸载应用本体，这里区分Docker、npm、源码三种情况；
• 然后清理配置文件目录和日志；
• 接着检查systemd、cron、环境变量、注册表和自启动项；
• 最后才清模型缓存和Docker镜像。

这个顺序能保证一件事：哪怕你中途后悔了，数据还在；哪怕某个步骤出了问题，最多也只是重装一遍应用，不会落到“资料全没了、服务还占着”这种两头空的局面。我自己第一次卸载就是因为顺序反了，先清了模型和镜像，又删了配置目录，最后才想起来没备份对话记录，折腾半小时也没找回来。

卸载这种事，看起来比安装简单，实际上比安装更需要耐心。希望这篇记录能帮你少走几步弯路，至少下一次换方案或者清理机器的时候，不用再对着残留文件发懵。