OpenClaw 完全卸载指南：从安装方式到残留清理一步到位

说个挺现实的事：OpenClaw 这阵子确实火，尤其是想在本地跑 Agent、接微信飞书、玩多模型组合的朋友，基本都折腾过一遍。可问题在于，这工具安装的时候是全家桶式地往你机器里塞东西，卸载的时候却没人告诉你它把零件都藏哪儿了。我见过太多人以为“拖进回收站”就算完事，结果没过多久发现磁盘空间少了几个 G、某个服务还在后台反复启动、甚至重装的时候被各种奇葩报错卡住。这篇我就把 OpenClaw 卸载这件事拆开揉碎，从安装方式、配置目录、环境变量、后台服务到验证清理，一层一层讲清楚，保证你卸完之后查不出半点残留。

这篇文章适合所有在 Windows、macOS 或 Linux 上部署过 OpenClaw 的开发者。不管你是用脚本装的、用 Docker 跑的，还是从源码 clone 下来直接启动的，下面这套清理思路都通用。核心原则只有一条：先停服务，再拆组件，最后清用户数据，千万别反过来。

1. 动手前先盘点：你到底用哪种方式装的 OpenClaw

很多人卸载失败或者卸不干净，根本原因不是操作不对，而是压根不清楚自己的 OpenClaw 是怎么装进去的。这一步如果搞错，后面所有清理动作都是盲人摸象。

1.1 快速确认自己的安装方式

别急着手动删目录，先花两分钟把下面这组命令跑一遍，确定 OpenClaw 是以什么形态存在于你的系统里。

# 检查命令行工具是否存在以及它的位置 which openclaw which claw # 如果是通过 Python 包安装的 pip show openclaw # 如果是 Docker 部署 docker ps -a | grep -i openclaw # 查看服务是否存在 systemctl list-units | grep -i openclaw launchctl list | grep -i openclaw

我把常见的集中情况整理成了表格，对照着看会更直观：

这里要特别提醒一点：很多人在折腾过程中会同时用多种方式安装。比如一开始用 Docker 试了试，后来觉得不方便又用脚本装了一遍。这种情况下，卸载时每种方式都要处理到，缺一个都不行。

1.2 卸载前的备份：这些数据重装时还能用

我知道很多人卸载就是因为不想再折腾了，但如果只是暂时不玩、以后还想装回来，或者要在另一台机器上重新部署，那下面这些数据还是值得留一份。毕竟真到重装那天你会发现，重新配置 skill、重新调模型参数、重新攒对话记录，这些时间成本远比当初装 OpenClaw 高得多。

# 备份整个配置目录（路径可能因安装方式而异） cp -r ~/.openclaw ~/openclaw-backup # 单独备份 skills 目录（如果你自己写过 skill） cp -r ~/.openclaw/skills ~/openclaw-backup-skills # 记录当前用到的模型配置 openclaw model list > ~/openclaw-model-list.txt

需要备份的东西主要是这几类：

• 配置文件：包括 config 文件、模型配置、Channel 配置（微信、飞书等接入信息）
• 自定义 skill：你自己写的或者从社区下载后改过的 skill 目录
• 工作流/剧本数据：如果拿 OpenClaw 写过小说或跑过自动化流程，相关数据单独拷出来
• 本地模型缓存清单：方便以后重装时知道该下载哪些模型，不用一个个去查

备份完再动手，这句话听起来像废话，但我真的见过太多人把配置删了之后跑来找我，问能不能恢复。有些东西你自己写了没备份，神仙也救不回来。

2. 按安装方式拆解：脚本、Docker、桌面端各有各的拆法

确认完安装方式，接下来就是正式的卸载环节。这一章我按安装方式分类，给出对应的清理方案。核心思想是：先停掉所有运行中的进程，再删除应用本体，最后才是清理残留。

2.1 命令行/PowerShell 脚本安装：先停后删

脚本安装是最常见也最容易产生残留的方式。Windows 下很多人用的是 PowerShell 安装脚本，Linux 和 macOS 上则往往是curl | bash这类形式。这类安装方式最大的问题在于：脚本不会告诉你它到底往系统里塞了哪些东西。

我的建议是按下而顺序来：

第一步，停掉正在运行的 OpenClaw 进程。终端里执行ps aux | grep -i openclaw（Windows 用任务管理器或tasklist | findstr openclaw），找到相关进程后结束掉。如果它注册了系统服务，先停服务再结束残余进程。

第二步，有卸载脚本就用卸载脚本。部分版本的 OpenClaw 自带openclaw uninstall命令，执行一下，它会顺手把注册的服务和命令入口清掉。这一步值得试试，即使不完整也能替你省不少事。

第三步，删命令行工具本体。有些是安装在/usr/local/bin/openclaw或~/.local/bin/openclaw，还有的是作为 Python 包安装的：

pip uninstall openclaw -y

但这里有个坑请务必注意：pip uninstall只能清掉 Python 包装进去的文件。对于那些脚本直接往/usr/local/bin里拷贝的可执行文件，pip 根本不知道它们的存在。所以卸载完还是要手动检查一下：

rm -f /usr/local/bin/openclaw /usr/local/bin/claw rm -f ~/.local/bin/openclaw ~/.local/bin/claw

2.2 Docker 部署：别只 docker stop 就跑

如果你是用 Docker 部署的 OpenClaw，那我要先问一句：你是不是觉得docker stop openclaw就算卸载了？如果是，那你的磁盘上大概率还躺着一整个容器的镜像层和一堆匿名卷。

Docker 部署清理的完整链路是这样的：

# 进入你的 compose 项目目录 cd ~/openclaw-docker # 换成你实际的目录 # 停止并删除容器、网络 docker compose down # 坚决要删掉数据卷，用 -v 参数 docker compose down -v # 删除镜像 docker rmi <image-id-or-name> # 最后清理悬空镜像和构建缓存 docker image prune docker system prune

docker compose down和docker compose down -v的差别是很多人没注意到的关键点。前者只删除容器和网络，Data Volume 会原封不动地留在那里；后者才会把 volume 一起删掉。如果你的是命名卷，不带-v的话，重装 OpenClaw 时它甚至还能读到旧数据。

还有一个场景，就是当初直接用docker run启动的，没写 compose 文件。这种情况下你需要手动查找并删除容器：

# 找到容器 ID docker ps -a | grep -i openclaw # 强制删除容器 docker rm -f <container-id> # 删除镜像 docker rmi <image-id> # 删除无主卷 docker volume prune

如果容器里配了restart: always策略，光 stop 是没用的，机器重启后容器就会“复活”。所以删容器的时候直接用rm -f，确保容器和它的自启策略一起消失。

2.3 桌面图形端和 Control UI 相关组件

有些版本 OpenClaw 带图形界面（Control UI），还可能有独立的桌面应用。这类组件卸载起来更隐蔽，因为除了应用本体，浏览器侧还会存有一堆本地数据。

先看系统里有没有独立的 App：

• macOS：把 OpenClaw、Control UI 从“应用程序”文件夹拖进废纸篓，顺便清一下~/Library/Application Support/OpenClaw和~/Library/Preferences/com.openclaw.*
• Windows：在“设置 -> 应用”里卸载对应程序，然后检查%APPDATA%\OpenClaw和%LOCALAPPDATA%\OpenClaw

如果你之前启动过 Control UI 但一直失败（网上这个报错非常常见：openclaw control ui did not start），大概率这个时候系统里还躺着一些半死不活的残留进程。先杀掉它们再删程序数据，不要留到后面。

2.4 从源码 Clone 运行的安装：目录里还藏着下不完的依赖

源码安装是清理起来需要最细心的一种方式。因为除了仓库目录本身，它的依赖目录才是体量最大的部分。

# 删除项目目录 rm -rf ~/openclaw-src # 你的实际路径 # 如果项目里有虚拟环境 rm -rf ~/openclaw-src/venv ~/openclaw-src/.venv # Node 项目依赖 rm -rf ~/openclaw-src/node_modules # 构建产物（如果有） rm -rf ~/openclaw-src/.next ~/openclaw-src/dist ~/openclaw-src/build

这里有个容易被忽略的地方：源码目录里往往藏着.env文件，里面可能有各种 API key、Token。如果你不打算再用这台机器部署 OpenClaw，建议连.env带整个目录一起删干净，免得密钥信息留在本机。

3. 配置、模型缓存和日志：默认卸载扫不到的地方

如果前面那步是“拆房子”，那这一步就是“打扫地基”。几乎所有卸载程序默认都只管应用本体，对于散落在用户目录里的配置、缓存和日志一律视而不见。然而 OpenClaw 这种工具恰恰是以这些零碎文件为生的。

3.1 配置文件目录：三个平台的主路径

配置文件的官方命名通常带.openclaw前缀，但也有些版本会写成OpenClaw或claw。比较常见的位置如下：

删除这些目录前，先进去扫一眼，看看里面有没有你自己后期添加的、超过 OpenClaw 默认内容的东西。比如有些人会把自定义模型权重放在配置目录下面，你这会儿一并删了，以后想找回就难了。

3.2 模型缓存与本地模型目录：占空间的大头

这一项往往是“卸载完之后发现磁盘空间没少多少”的真正原因。OpenClaw 支持多种模型来源，包括远程 API 和本地模型。本地模型尤其占地方，动辄几个 GB 甚至十几 GB。

常见需要清理的位置：

• ~/.cache/openclaw：OpenClaw 下载的临时模型文件
• ~/.ollama/models：如果你用 Ollama 跑本地模型，模型都在这
• NVIDIA NIM 相关目录：如果你配置过 NIM 后端，对应的模型镜像和缓存也要单独清理
• 项目目录下的models/文件夹（源码安装时常见）

有些人会有疑问：我只想卸 OpenClaw，会不会把 Ollama 的模型删了影响其他工具？答案是有可能。所以建议只删 OpenClaw 专属的那部分模型文件，Ollama 全局共享的模型先看下大小，确认没别的项目在用再删。

3.3 日志、状态和临时文件

日志这个东西平时没人注意，但积累多了也是个麻烦。OpenClaw 的日志在 Linux 上通常位于~/.local/state/openclaw/logs，macOS 可能藏在~/Library/Logs/OpenClaw，Windows 则可能在%LOCALAPPDATA%\OpenClaw\Logs。

除了日志，还会有一些运行时产生的临时文件和状态文件。有洁癖的话可以用 find 命令做一次全局扫描：

find ~ -name "*openclaw*" -o -name "*claw*" 2>/dev/null | grep -v ".Trash"

Windows 下可以在资源管理器里搜索 openclaw，然后逐个判断哪些是残留文件。搜索结果里出现的 node_modules 目录要特别留意，后面我会专门讲。

3.4 Skill 插件与第三方依赖残留

如果你往 OpenClaw 里装过 skill 或者扩展插件，它们的残留不仅限于 OpenClaw 自己的目录。有些 skill 会用 npm 或 pip 安装额外的依赖包，这些包会散落在全局环境中。

# 查看全局 npm 包里有没有 openclaw 相关依赖 npm ls -g | grep -i openclaw # 查看 pip 全局环境里有没有相关包 pip list | grep -i openclaw

确认是 OpenClaw 专用的依赖后可以顺手清理掉。判断标准很简单：你卸载后重装之前，这台机器上是否还需要这些包？如果答案是“不需要”，删掉；如果有其他项目在用，保留。这个度一定要把握好，我后面会专门讲一个因为误删公共依赖导致其他项目崩溃的案例。

4. 环境变量、开机服务和系统级组件：残留层的最后一公里

很多人以为把用户目录清干净就万事大吉了，其实还有一层更隐蔽的残留，藏在环境变量、开机服务和系统级依赖里。这一层不清理，OpenClaw 就只是“看起来卸载了”。

4.1 环境变量与 PATH

安装脚本为了让你在终端里直接输入openclaw就能启动，会在 shell 配置里写入 PATH。这个改动在你卸载后并不会自动撤销。

# 检查 shell 配置 grep -i openclaw ~/.bashrc ~/.zshrc ~/.profile 2>/dev/null # 检查系统级环境变量 env | grep -i openclaw

找到相关条目后，编辑对应的 rc 文件，把 OpenClaw 相关的export PATH=...行删除或注释掉。Windows 用户在“系统属性 -> 环境变量”里检查用户变量和系统变量，把 OPENCLAW 相关条目和包含 openclaw 路径的 PATH 值删掉。

还有一个经常被忽略的点：有些安装脚本还会设置OPENCLAW_MODEL、OPENCLAW_CONFIG这类自定义环境变量。这些变量会直接影响 OpenClaw 的行为，如果你重装时还留着旧的变量，新装上来的实例会莫名其妙地加载旧配置。

4.2 开机自启是“删了目录还报错”的头号原因

我见过不少朋友，明明把所有文件都删干净了，结果一重启机器，进程又出现了。这不是见鬼，是开机自启服务没有清掉。

不同平台的处理方式：

Linux 上如果注册了 systemd 服务：

# 停止并禁用服务 systemctl disable --now openclaw # 删除服务文件 rm /etc/systemd/system/openclaw.service # 重新加载 systemd systemctl daemon-reload

macOS 上用的是 launchd：

# 停止服务 launchctl unload ~/Library/LaunchAgents/com.openclaw.plist # 删除 plist 文件 rm ~/Library/LaunchAgents/com.openclaw.plist

Windows 上则是“服务”控制台（Win+R 输入services.msc）里找 OpenClaw 服务，右键停止并设置为“禁用”，或者直接用管理员权限的 PowerShell 执行：

Stop-Service -Name "OpenClaw*" sc.exe delete "OpenClaw"

如果你用的 Docker 部署，restart: always的重启策略也是一类自启机制。前面第 2 章我让你用docker rm -f而非docker stop，就是为了绕开这个问题。容器都删了，自然也就没有重启策略可言。

4.3 为了 OpenClaw 安装的运行时组件

OpenClaw 依赖 Node.js 运行时，很多安装脚本会在检测不到 Node 时自动帮你装一个。问题来了：你卸载 OpenClaw 时，这个 Node 环境不会自己消失。

典型的例子就是很多人在重装 OpenClaw 时遇到oneclaw node runtime not found这个报错，意思其实是系统找不到 Node 运行时。它可能是两种情况：

• 旧的 Node 环境被误删了，导致新装的 OpenClaw 起不来
• 旧的 Node 环境还在，但加载的路径是旧的安装目录，新装的 OpenClaw 找不到

所以在卸载时，对于 Node、Python 这些 OpenClaw 依赖的运行时，判断标准是：这台机器上还有其他项目用吗？如果 OpenClaw 是你安装 Node 的唯一理由，那可以连 Node 一起删干净。如果还有其他项目在用，千万别动，只清理 OpenClaw 自己那个局部的 node_modules 就好。

4.4 Docker 残留的系统级数据

如果你在机器上跑过 Docker 版 OpenClaw，系统里可能还残留着与 OpenClaw 相关的网络、卷和镜像。这些不清理，OpenClaw 便不算真正卸载干净。

# 查看 Docker 资源占用 docker system df # 查看所有网络 docker network ls | grep -i openclaw docker network rm <network-name> # 清理悬空镜像和构建缓存 docker image prune -a docker builder prune

docker system prune这个命令很多人用了以为万事大吉，但其实它默认不清理未使用的卷。如果你想把底层 data volume 也清掉，必须显式加--volumes参数：

docker system prune -a --volumes

不过这个命令会把 Docker 引擎下所有无主卷都删掉，如果有其他容器项目的数据卷也无主了，会被一并清理，操作前最好用docker volume ls看一眼。

5. 残留验证：怎么确认真的卸干净了

清理完之后不要急着收工。验证这一步花不了十分钟，却能帮你省下重装时几小时的排查时间。接下来我把验证分为四个层面，每一层都有对应的自查方法。

5.1 命令层验证

终端里直接执行：

which openclaw which claw openclaw --version

如果提示command not found或没有任何输出，说明命令入口已经清干净了。如果还能找到路径，那说明命令本身还在，先看它指向哪里，再回到对应位置删除。Windows 下则是打开 CMD，执行where openclaw，应显示找不到。

5.2 文件层验证

把第 3 章列出的所有目录都过一遍，确认不存在：

ls -la ~/.openclaw 2>/dev/null ls -la ~/.config/openclaw 2>/dev/null ls -la ~/.cache/openclaw 2>/dev/null ls -la ~/.local/state/openclaw 2>/dev/null

如果目录还在，先看看里面有没有数据，再决定直接删还是留着。有一次我清理一台开发机，~/.cache/openclaw里还有几个 G 的模型文件没删干净，因为当初安装脚本用的缓存路径和默认路径不一样。所以在文件验证阶段，建议顺带做一次全盘搜索。

find ~ -iname "*openclaw*" 2>/dev/null | head -50

5.3 服务与进程验证

检查系统里是否还有 OpenClaw 相关进程在运行：

ps aux | grep -i openclaw ps aux | grep -i "claw"

注意，claw这个关键词可能会搜到一些不相关的进程，比如系统里其他带 “claw” 字样的应用。别一看到输出就紧张，仔细看进程命令的完整路径。

服务层面的验证：

# Linux systemctl status openclaw # macOS launchctl list | grep -i openclaw # Windows sc.exe query OpenClaw tasklist | findstr -i openclaw

如果这些都没有输出或提示找不到对应的服务，说明服务层面已经清理干净。

5.4 端口验证

如果你之前用过 Control UI 或者其他 Web 服务，OpenClaw 会长期占用一个端口。卸载后这个端口应该释出来。验证方法如下：

# Linux / macOS lsof -i :<端口号> # Windows netstat -ano | findstr <端口号>

端口号要根据你自己的配置来定，每个人可能不一样。如果还不确定，可以在验证阶段扫描一下常见端口，比如 3000、8000、8080、8787。如果这些端口没有任何监听，说明那一层的残留也清掉了。

5.5 “卸载后重装”的干净度测试

这一步不适用于所有场景，但如果你有重装计划，建议先做个干净度测试。在确保数据已经备份的前提下，跑一次干净的重装流程，看是否能直接通过初始化和模型加载。

有人重装时碰到unknown model: deepseek这种报错，其实不是新装的问题，而是旧的模型配置或者旧的环境变量还在作祟。遇到这种情况，回头看第 4 章的环境变量清理部分，多半能找到答案。

6. 卸载后最容易踩的坑：几个真实案例

最后分享几个我在实际清理 OpenClaw 过程中遇到过的真实案例，希望能帮你避开同款问题。

6.1 案例一：删了三天，进程突然“复活”

一位朋友在 Linux 服务器上部署过 OpenClaw，用 Docker 方式跑的。他卸载时执行了docker stop，然后删了镜像，觉得大功告成。结果过了三天，服务器一重启，他又在进程列表里看到了 openclaw。

排查下来才知道，当初他用的是docker run --restart=always，而且 compose 文件里写的容器名称还在。他执行的是 stop，不是 rm，所以容器一直存在，只不过处于停止状态。机器一重启，docker 的--restart=always策略立刻把容器拉起来了。

处理方案就是把容器彻底删掉，docker rm -f，如果再保险一点，把整个 compose 项目和它的 volume 一起清了。这也印证了我前面反复强调的：Docker 卸载的关键不是停容器，而是删容器。

6.2 案例二：配置文件全删了，环境变量还在引用

另一个朋友的情况比较妖。他把~/.openclaw和/usr/local/bin/openclaw都删干净了，重新安装后却遇到unknown model: deepseek的报错，可是新装的配置文件里根本没有 deepseek 的配置。

后来一查环境变量才发现，之前安装脚本在~/.bashrc里写了一个export OPENCLAW_MODEL=deepseek。这个变量在旧配置删除后依然存在，新安装的 OpenClaw 会优先读取环境变量，于是加载了不存在的模型配置。

这种坑特别容易上“重装老手”的当，因为表面看是模型配置问题，实际根因在环境变量。所以卸载 OpenClaw 时，把所有OPENCLAW开头的环境变量全部清掉，这一步真的很重要。

6.3 案例三：清理依赖时误删了公共包

还有一个反面教材，是有人为了卸载 OpenClaw 顺便把 Node.js 和 Python 的全局环境都清了一遍，结果 OpenClaw 是干净了，他另外一个人项目也起不来了——因为那个项目也用同一套 Node 环境。

我自己的操作习惯是：卸载 OpenClaw 前先执行一次npm ls -g和pip list，把当时机器上的全局包列表导出来留底。这样即便清理后发现其他项目缺了什么依赖，也能根据留底快速装回去。一句话，公共依赖宁缺勿删、宁留勿错。

6.4 我个人的标准卸载顺序

在踩过上面这些坑之后，我形成了一个固定步骤，基本不会再出问题，分享出来：

1. 先备份配置和 skills 数据
2. 停服务、杀全部相关进程
3. 按安装方式移除应用本体（脚本 / pip / Docker / 源码）
4. 清用户目录的配置、缓存、日志三件套
5. 清环境变量、PATH 与开机自启项
6. 删除为 OpenClaw 安装的局部依赖，并核实全局依赖是否还被其他项目使用
7. 按第 5 章的四个层面做验证，确认无残留

这套顺序的核心逻辑是“由外到内、先停后删”。只要按照这个顺序来，OpenClaw 卸载这件事就不会再有什么遗留问题。最后再提醒一句：清理这种事，宁可多花十分钟想清楚每一步，也不要图快一刀切。不然等你重装的时候，那些“幽灵报错”能让你怀疑人生。