说个挺现实的事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我把常见的集中情况整理成了表格对照着看会更直观安装方式典型特征主要残留位置脚本一键安装有 openclaw / claw 命令但没有 pip 或 npm 记录安装目录、/usr/local/bin、用户目录pip 安装pip show openclaw有输出site-packages、用户配置目录Docker 部署容器列表中能看到 openclaw 相关容器Docker 镜像、卷、Compose 项目源码 clone有个仓库目录里面有 .git 文件夹仓库目录、node_modules、虚拟环境桌面图形端应用程序里有 OpenClaw / Control UI应用目录、浏览器扩展/存储这里要特别提醒一点很多人在折腾过程中会同时用多种方式安装。比如一开始用 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 openclawWindows 用任务管理器或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/claw2.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 prunedocker 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还可能有独立的桌面应用。这类组件卸载起来更隐蔽因为除了应用本体浏览器侧还会存有一堆本地数据。先看系统里有没有独立的 AppmacOS把 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。比较常见的位置如下平台路径存放内容Linux~/.openclaw/、~/.config/openclaw/主配置、模型配置、skillsmacOS~/Library/Application Support/OpenClaw/应用数据、配置、本地存储macOS~/Library/Preferences/com.openclaw.plist偏好设置Windows%APPDATA%\OpenClaw\配置、数据Windows%LOCALAPPDATA%\OpenClaw\缓存、日志跨平台~/.cache/openclaw/模型缓存、临时下载文件Linux~/.local/state/openclaw/运行状态、日志删除这些目录前先进去扫一眼看看里面有没有你自己后期添加的、超过 OpenClaw 默认内容的东西。比如有些人会把自定义模型权重放在配置目录下面你这会儿一并删了以后想找回就难了。3.2 模型缓存与本地模型目录占空间的大头这一项往往是“卸载完之后发现磁盘空间没少多少”的真正原因。OpenClaw 支持多种模型来源包括远程 API 和本地模型。本地模型尤其占地方动辄几个 GB 甚至十几 GB。常见需要清理的位置~/.cache/openclawOpenClaw 下载的临时模型文件~/.ollama/models如果你用 Ollama 跑本地模型模型都在这NVIDIA NIM 相关目录如果你配置过 NIM 后端对应的模型镜像和缓存也要单独清理项目目录下的models/文件夹源码安装时常见有些人会有疑问我只想卸 OpenClaw会不会把 Ollama 的模型删了影响其他工具答案是有可能。所以建议只删 OpenClaw 专属的那部分模型文件Ollama 全局共享的模型先看下大小确认没别的项目在用再删。3.3 日志、状态和临时文件日志这个东西平时没人注意但积累多了也是个麻烦。OpenClaw 的日志在 Linux 上通常位于~/.local/state/openclaw/logsmacOS 可能藏在~/Library/Logs/OpenClawWindows 则可能在%LOCALAPPDATA%\OpenClaw\Logs。除了日志还会有一些运行时产生的临时文件和状态文件。有洁癖的话可以用 find 命令做一次全局扫描find ~ -name *openclaw* -o -name *claw* 2/dev/null | grep -v .TrashWindows 下可以在资源管理器里搜索 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-reloadmacOS 上用的是 launchd# 停止服务 launchctl unload ~/Library/LaunchAgents/com.openclaw.plist # 删除 plist 文件 rm ~/Library/LaunchAgents/com.openclaw.plistWindows 上则是“服务”控制台WinR 输入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 prunedocker 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 -505.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 --restartalways而且 compose 文件里写的容器名称还在。他执行的是 stop不是 rm所以容器一直存在只不过处于停止状态。机器一重启docker 的--restartalways策略立刻把容器拉起来了。处理方案就是把容器彻底删掉docker rm -f如果再保险一点把整个 compose 项目和它的 volume 一起清了。这也印证了我前面反复强调的Docker 卸载的关键不是停容器而是删容器。6.2 案例二配置文件全删了环境变量还在引用另一个朋友的情况比较妖。他把~/.openclaw和/usr/local/bin/openclaw都删干净了重新安装后却遇到unknown model: deepseek的报错可是新装的配置文件里根本没有 deepseek 的配置。后来一查环境变量才发现之前安装脚本在~/.bashrc里写了一个export OPENCLAW_MODELdeepseek。这个变量在旧配置删除后依然存在新安装的 OpenClaw 会优先读取环境变量于是加载了不存在的模型配置。这种坑特别容易上“重装老手”的当因为表面看是模型配置问题实际根因在环境变量。所以卸载 OpenClaw 时把所有OPENCLAW开头的环境变量全部清掉这一步真的很重要。6.3 案例三清理依赖时误删了公共包还有一个反面教材是有人为了卸载 OpenClaw 顺便把 Node.js 和 Python 的全局环境都清了一遍结果 OpenClaw 是干净了他另外一个人项目也起不来了——因为那个项目也用同一套 Node 环境。我自己的操作习惯是卸载 OpenClaw 前先执行一次npm ls -g和pip list把当时机器上的全局包列表导出来留底。这样即便清理后发现其他项目缺了什么依赖也能根据留底快速装回去。一句话公共依赖宁缺勿删、宁留勿错。6.4 我个人的标准卸载顺序在踩过上面这些坑之后我形成了一个固定步骤基本不会再出问题分享出来先备份配置和 skills 数据停服务、杀全部相关进程按安装方式移除应用本体脚本 / pip / Docker / 源码清用户目录的配置、缓存、日志三件套清环境变量、PATH 与开机自启项删除为 OpenClaw 安装的局部依赖并核实全局依赖是否还被其他项目使用按第 5 章的四个层面做验证确认无残留这套顺序的核心逻辑是“由外到内、先停后删”。只要按照这个顺序来OpenClaw 卸载这件事就不会再有什么遗留问题。最后再提醒一句清理这种事宁可多花十分钟想清楚每一步也不要图快一刀切。不然等你重装的时候那些“幽灵报错”能让你怀疑人生。