如果你用过 OpenClaw，大概率已经被那个官方卸载命令坑过一次——敲完uninstall，终端回了一串看似礼貌的日志，结果打开任务管理器，进程还在跑；访问原来的端口，服务还在应答；翻翻配置目录，一堆文件原封不动躺在那里。这不是个例，OpenClaw 这种能本地部署、支持飞书和 Teams 多端接入、还能自由配置千问等模型的 AI Agent 框架，安装时一键脚本身段灵活，卸载脚本却远没有安装时那么负责。官方卸载命令失效的根本原因，说穿了就一句话：它只拆掉了自己表面那层壳，真正的运行核心都埋在系统服务、会话文件、Docker 卷和环境变量里，命令根本没碰。
这篇手动卸载终极方案，就是写给那些被卸载失败逼疯、重装被旧配置反复干扰、或者想干干净净换工具的朋友。我踩过的坑，你基本不用再踩一遍。整个方案不分操作系统、不分部署方式，从体检排查到逐项拆除再到重装避坑，按步骤抄就行。
1. 为什么官方卸载命令总是“装死”：三类残留物在作祟
很多人第一步就走错了，把希望全押在官方命令上。实际上你只要搞明白官方脚本的执行逻辑，就会意识到它失效是必然的。
1.1 官方卸载命令到底覆盖了哪些范围
OpenClaw 官方卸载脚本的逻辑非常简单，简单到有些粗暴。它的核心动作只有三件事：调用容器管理工具停止当前容器、删除自己安装目录里的二进制文件、移除它记录在案的那个 systemd 服务或守护进程。如果你用的是docker compose部署，它执行docker compose down时只会停止并删除容器本身，不会删除镜像、不会删除命名卷、不会删除你挂载出来的配置文件目录，更不会清理日志目录。如果你用的是 npm 或源码方式部署，那问题更明显——npm uninstall只会把那个包从 node_modules 里删掉，但安装时通过 postinstall 脚本注册的守护进程、写入的环境变量、生成的密钥文件，一个都不会动。
这样的设计在理想环境下没问题，但真实机器上哪有那么乖的环境。你装完 OpenClaw 之后，大概率手动改过配置、单独拉过模型加载脚本、给某个 channel 添加过飞书或者 Teams 的接入凭证，这些都是在官方脚本认知范围之外的“野数据”。卸载命令不知道它们的存在，自然也就不会去处理。
1.2 第一类残留：还在跑的进程与锁死的会话文件
卸载失败后你最常遇到的现象，就是进程根本没死。OpenClaw 运行时会有主进程、会话管理子进程、消息通道轮询进程，一套下来有十来个进程在各自忙活。官方卸载脚本在停止服务时，只对主进程发送了终止信号，结果子进程无人接管，成了一堆孤儿进程继续占着 CPU 和端口。
更麻烦的是会话文件锁。OpenClaw 每处理一个会话都会生成一份 session 文件，文件带上锁标记，防止多个进程同时写入。如果卸载时进程被不正常终止，锁标记不会自动清除，这就直接导致你重装之后反复看到agent failed before reply: session file locked (timeout 60000ms)这个报错。这行报错我调试了很久才搞明白，它不是配置写错了，也不是网络问题，纯粹就是上一个环境的进程尸体还握着那把锁，没撒手。
1.3 第二类残留：配置、缓存与数据目录
进程类残留只是表面的，文件类残留才是占磁盘大头。OpenClaw 会在用户主目录下散布至少三四个目录：一个放全局配置，一个放会话数据库，一个放 API Key 和令牌缓存，还有一个放日志文件。这些目录的名字里不一定直接带 openclaw 字眼，有些叫.claw，有些藏在.config里，用通行目录名去搜索很容易漏掉。
这些残留文件最坑人的地方在于，重装新版 OpenClaw 时，安装脚本一检测到旧的配置目录存在，就会默认继续使用它。于是你改了半天新版本设置，实际跑到飞书里的行为逻辑全是旧配置的，拦截规则、回复阈值、渠道绑定全都不对劲。还有朋友遇到过卸载重装后模型请求一直报错，排查到最后发现，旧版本在.env文件里写死了一个早被吊销的密钥，新版本还在沿用。所以不要以为删掉主程序就是卸载了，配置文件才是真正的“精神残留”。
1.4 第三类残留：系统服务、Docker 卷与自启项
系统层级的残留往往最隐蔽。OpenClaw 安装时会在 Linux 的/etc/systemd/system/下注册一个openclaw.service文件，并且执行systemctl enable把它做成开机自启。卸载脚本有时候只会执行systemctl stop，不会执行systemctl disable，更不会把 service 文件从磁盘上删掉。等你重启机器，它又自己起来了。
Docker 部署模式下情况就更丰富。你执行docker ps -a会看到一两个退出状态的容器，执行docker images会看到几份旧镜像，执行docker volume ls还会看到带 openclaw 字样的数据卷。这些卷里装的往往是长期积累的会话数据库和函数调用日志，少则几百 MB，多则几个 GB。尤其像在飞牛这种 NAS 系统上部署的朋友，自带的 Web 管理界面上点卸载按钮，只帮你删掉容器，镜像和卷全给你留着，磁盘空间肉眼可见地减少，但你根本不知道去哪删。
2. 卸载前必做：三分钟“体检”与数据备份
不管你是彻底不玩了还是准备重装，动手卸载之前先花三分钟做一次体检。这一步可以让你后面少走两小时的弯路。
2.1 用这四组命令，查明你到底装了什么
卸载前第一件事，不是急着删文件，而是把现状摸清楚。打开终端，按顺序执行下面这四组检查，每一条输出都记录下来。很多人在这一步偷懒，结果删到一半发现有些残留的源头根本不在常规路径下。
# 1. 查找正在运行的 OpenClaw 进程 ps aux | grep -i claw | grep -v grep # 2. 查看端口监听情况，默认前的三分钟自检阶段尤其重要 netstat -tlnp 2>/dev/null | grep -E '(:3000|:8080|:8688)' # 3. 查看 systemd 服务注册情况 systemctl list-units --all | grep -i claw # 4. 查看 Docker 相关的容器、镜像、卷信息 docker ps -a | grep -i claw docker images | grep -i claw docker volume ls | grep -i claw输出的每一行都有用。进程列表可以告诉你还有哪些子进程没被官方脚本处理掉；端口监听可以帮你找到服务还在跑的端口；systemd 列表决定了你后面要不要执行daemon-reload；Docker 清单则直接决定了你要额外清理哪些镜像和卷。
如果你是 Windows 环境，把第一条换成tasklist | findstr /i claw，把端口检查换成netstat -ano | findstr LISTENING。Windows 用户尤其要注意任务计划程序里的残留，打开taskschd.msc搜索关键字，OpenClaw 有时会在安装阶段写一个开机触发任务，负责拉起服务进程。
2.2 备份清单：哪些数据值得留，哪些直接扔
搞清楚现状之后，再想清楚哪些数据要留下。我不是让你一股脑全备份，那没有意义。真正值得留的只有三类：一是会话记录中还有参考价值的对话数据，二是你所有 channel 接入的 API Key 和 Webhook 配置，三是你手动调好的自定义提示词和指令集。
对应的目录一般在用户主目录下的.openclaw或.config/openclaw里，唯一要注意的是某些版本会把 session 数据单独放在~/.local/share/openclaw/下。保守起见，把主目录下所有带 claw 字样的隐藏目录都打包一份：
tar czf openclaw-backup.tar.gz ~/.openclaw ~/.config/openclaw ~/.local/share/openclaw 2>/dev/null备份是做减法，不是做加法。日志文件不用留，模型缓存不用留，临时文件不用留。这些东西重装后会自动重新生成，留着反而容易在重装时干扰新版本的文件结构。我见过有人连 node_modules 都打成包备份的，纯属给自己找麻烦。
2.3 先把服务停干净，再谈删除
备份完毕，正式动手前的最后一步，就是把所有还在跑的东西全部停下来。注意，这里不能用暴力的kill -9直接招呼。OpenClaw 的会话进程在正常退出时有机会释放锁文件、落盘会话数据和做最后的状态同步，你一次性强杀，等于把一堆半成品状态写在磁盘上，重装后大概率要继续跟 session file locked 做斗争。
正确的停止顺序是先走正规流程：
systemctl stop openclaw 2>/dev/null docker compose -f /path/to/docker-compose.yml down 2>/dev/null等这两条命令都返回了，再检查一遍ps aux | grep -i claw，确认还有没有漏网之鱼。如果发现个别进程还在，这时候再针对性地 kill。系统提示服务已停止但进程还赖着，多半是子进程进入了不可中断状态，直接 kill 主进程 ID 就好。Windows 用户则在服务管理器里执行停止，然后再去任务管理器确认进程是否全退。
这些步骤全部走完后，你的 OpenClaw 才处于“可以安全拆除”的状态。接下来就按系统分支来处理。
3. Linux 手动卸载完整实操：一步步拆到根
Linux 是 OpenClaw 最常见的部署环境，也是残留物最分散的环境。这里我以 systemd 加源码部署为主讲一遍完整流程，Docker 部署的追加步骤单独讲。
3.1 停服务、杀进程、清理 systemd 配置
进入卸载实操阶段，还是那句老话，从最外层的服务管理层开始一层层往内部清理。
# 1. 停止并禁用服务 systemctl stop openclaw systemctl disable openclaw # 2. 确认是否还有残留进程 ps aux | grep -i claw | grep -v grep # 3. 如果有残留，逐条 kill（先 SIGTERM，再 SIGKILL） pkill -f openclaw sleep 2 pkill -9 -f openclaw 2>/dev/null || true服务停掉之后要处理 systemd 服务文件。用systemctl cat openclaw可以查看该服务的配置路径，默认情况下在/etc/systemd/system/openclaw.service，也有可能在/lib/systemd/system/下。找到路径以后直接删除：
rm -f /etc/systemd/system/openclaw.service systemctl daemon-reload systemctl reset-failed 2>/dev/null有一句话我要重复三遍：删完 service 文件必须执行daemon-reload，必须执行，必须执行。不执行的话 systemd 还记着这个服务曾经存在过，下次你执行systemctl list-units时它还会出现在列表中，甚至有些版本的 systemd 在服务文件被删除后会自动重新拉取旧状态，导致卸载不彻底。reset-failed是顺带把 systemd 里标记为 failed 的历史记录清掉，免得日志里永远挂着一个刺眼的红色状态。
3.2 删目录、清环境变量，别放过日志和缓存
服务层清理完，就是文件系统的拆除。OpenClaw 文件分布有个特点，目录不带统一前缀，比如二进制装在/opt/openclaw/，配置装在~/.openclaw/，日志装在~/.local/state/openclaw/，缓存装在~/.cache/openclaw/。还有个别版本把模型加载器单独放在~/.claw/下。所以清理时不要只凭一个路径走天下，用find扫一遍才安心。
# 大规模删除前，先列出所有要删的目录，确认无误再执行 find ~ /opt /usr/local -maxdepth 4 -iname "*claw*" -o -iname "*openclaw*" 2>/dev/null确认列表没有误伤其他项目后，把安装目录、配置目录、缓存目录、日志目录和本地状态目录一次性删除：
rm -rf /opt/openclaw rm -rf ~/.openclaw ~/.claw rm -rf ~/.config/openclaw rm -rf ~/.cache/openclaw rm -rf ~/.local/share/openclaw rm -rf ~/.local/state/openclaw rm -rf /var/log/openclaw 2>/dev/null环境变量这块也很关键。打开你的~/.bashrc、~/.zshrc、/etc/profile、/etc/environment全查一遍，凡是包含OPENCLAW_HOME、OPENCLAW_API_KEY、OPENCLAW_MODEL_PATH这些字样的行，直接删掉。如果不删，新的 Shell 终端打开时还会自动加载这些变量，指向的空路径虽然不影响启动，但排查问题时会造成很大干扰。
3.3 Docker 方式部署的追加清理
如果你当初是用 Docker 部署的，上面步骤之外还得多做几件事。Docker 模式最大的特点是文件不直接落在宿主机目录里，而是躺在镜像层和命名卷中，光删目录是腾不出磁盘空间的。我之前在飞牛 NAS 上部署过测试环境，卸载后发现一个 2GB 的命名字卷还挂在系统里，就是因为我当时只执行了docker compose down没有继续清理。
# 1. 停止并删除容器 docker ps -a | grep openclaw docker rm -f <container_id> # 2. 删除相关镜像 docker images | grep openclaw docker rmi $(docker images | grep openclaw | awk '{print $3}') # 3. 删除命名字卷 docker volume ls | grep openclaw docker volume rm $(docker volume ls | grep openclaw | awk '{print $2}')命名字卷这个名字听着专业，理解成“Docker 管的持久化数据文件夹”就行。你之前所有会话数据库、模型调用记录、渠道绑定配置都放在里面。这个卷删除是不可逆的，但如果你已经做过备份，这里就可以放心大胆地清。
还有一种边界情况，你安装的时候用的是 Docker Compose 的独立项目目录，且 compose 文件在/opt/openclaw-compose/这种自定义路径下。Docker 并不知道这个文件的存在，所以卸载脚本根本不会处理它。你把这个目录也删掉，才算真正清完。
3.4 清理完成后怎么自检
卸载不是删完就算完，建议在拆除结束后再做一遍快速自检。这一遍的检查逻辑和卸载前那遍一样，但预期结果要反过来：所有命令都应该没有输出。
ps aux | grep -i claw | grep -v grep netstat -tlnp 2>/dev/null | grep -E '(:3000|:8080|:8688)' systemctl list-units --all | grep -i claw ls -la ~/.openclaw 2>&1 | head -5 docker ps -a | grep -i claw我一般还会再执行一个额外检查——端口占用。OpenClaw 跑过几百次会话后会留下一个常见的副作用，即使主程序删干净了，某个端口被别的进程占用着，那说明你机器上还有其他代理类工具抢了同一个端口。自检通过以后不要急着立刻重装，重启一次系统再装新版本。重启这个动作很关键，它能把所有文件句柄、锁标记和已删除但未释放的内存页彻底清空。
4. Windows 和 macOS 手动卸载：两套差异化的清理思路
Linux 之外的使用场景，很多人是在 Windows 上通过某种方式跑着 OpenClaw。macOS 用户相对少一些，但清理逻辑同样有自己独特的地方。
4.1 Windows：注意 WSL、任务计划与文件占用
在 Windows 上部署 OpenClaw，有两条完全不同的路径：一条是 WSL 2 里跑 Linux 版本，另一条是原生 Windows 版本。先判断你自己属于哪种，判断方法很简单，打开命令提示符，执行wsl -l -v。如果列表里有一个已安装且正在运行的发行版，那你的 OpenClaw 很可能装在里面，卸载流程直接参考 Linux 那套。
原生 Windows 版本相对简单，但有几个坑值得专门提。第一，服务注册不一定叫 openclaw，可能叫OpenClaw Session Manager或Claw Agent Worker，用服务管理器搜索时别只搜 openclaw 关键词。第二，文件锁问题比 Linux 严重得多，你明明把所有进程都关完了，删除目录时还是提示文件正在被占用，这是 Windows Search 索引服务和文件资源管理器预览进程在捣鬼。处理方法也很粗暴：把文件资源管理器窗口全部关掉，然后用 Power Shell 执行删除：
Stop-Service *claw* -Force -ErrorAction SilentlyContinue Get-Process | Where-Object {$_.Name -match 'claw|node'} | Stop-Process -Force Remove-Item -Recurse -Force "$env:USERPROFILE\.openclaw" Remove-Item -Recurse -Force "$env:APPDATA\OpenClaw"还有一个特别容易被忽略的角落——任务计划程序。OpenClaw 在 Windows 下安装时往往会在任务计划里注册一个开机自启任务，这个任务不会随程序卸载而消失，因为卸载脚本压根不知道它的存在。打开任务计划程序，在左侧导航栏点“任务计划程序库”，右侧搜索 openclaw 相关项，选中后右键删除。如果不删，下次开机系统会自动拉起来一个不存在的服务路径，向你弹一个极其烦人的错误窗口。
最后处理环境变量和注册表。在系统设置里打开“环境变量”编辑页面，把OPENCLAW_HOME、OPENCLAW_CONFIG_DIR相关项删掉。注册表方面，reg query HKCU\Software\OpenClaw有输出就删掉这个键，没有输出就不用管。这里不建议新手乱动注册表，只删和 OpenClaw 明确相关的项就好。
4.2 macOS：launchctl、Homebrew 与 Application Support
macOS 下我见过最多的是两种部署方式：Homebrew 安装和源码拉取。Homebrew 安装的卸载相对规范：
brew services stop openclaw brew uninstall openclaw但 Homebrew 卸载完，配置残留还是老问题。macOS 放配置的地方和 Linux 差异很大，你大概率能在这些位置找到残留：
rm -rf ~/Library/Application\ Support/OpenClaw rm -rf ~/Library/Logs/OpenClaw rm -rf ~/Library/Caches/com.openclaw.app rm -rf ~/.openclaw如果 OpenClaw 在 macOS 上注册过 launchd 守护进程，还要多一步操作。执行launchctl list | grep claw找到对应的 plist 标签，然后用launchctl bootout gui/$(id -u)/<label>把任务退出，再删除~/Library/LaunchAgents/下的 plist 文件。做完这些再执行killall -u 你的用户名 openclaw，确保没有漏网进程。
4.3 跨平台都要检查的浏览器 Token 与密钥环
很多人在手动清理时都会漏掉一个重要的地方：集成登录遗留在系统密钥环或浏览器存储里的令牌。你之前接入过 Microsoft Teams，那 OAuth 令牌可不仅仅是存在 OpenClaw 自己的配置文件里，Windows 的凭据管理器、macOS 的钥匙串、Linux 的 Secret Service 里都会有一份副本。
排查方式不必太复杂，最简单直观的做法是去各平台的凭据管理工具里搜索包含 openclaw 或 claw 的条目，发现后删除。如果你是通过浏览器完成过飞书或 Teams 的授权回调，浏览器的本地存储里也可能还保存着一次性的 OAuth code。虽然这个 code 已经过期，留着也不至于导致安全问题，但既然要清干净，就把它一并处理掉。
另外，还有一个文件经常被忽略：.env。OpenClaw 在安装阶段会在安装目录或者用户目录下生成一个.env文件，里面记录 API Key、Channel 的 webhook 地址、模型服务商的密钥等。我之前卸载时只删了可执行文件和配置目录，结果 .env 文件还躺在/opt/openclaw/的上级目录里，重装新版本时安装脚本自动读取了这个残留的 .env，直接把新安装搞挂了。搜索一下你的目录里有没有这个文件，找到后一并删除。
5. 常见问题与排查技巧实录：从锁文件到端口占用
清理过程中你一定会遇到各种报错，这里把我实际操作中踩过的坑和排查思路整理成了问题速查表，每一类都是真实环境中出现的，不是你想当然搬来的。
5.1 agent failed before reply: session file locked，80% 是残留进程
这条报错在相关网络讨论中出现频率极高，几乎可以称得上 OpenClaw 衍生热词的顶流了。agent failed before reply: session file locked (timeout 60000ms)翻译成人话就是：Agent 在回复之前失败了，因为会话文件被锁住，等了 60 秒没等到解锁。
排查思路优先确认进程是否残留。执行ps aux | grep -i claw，如果看到任何 openclaw 或者 node 进程还在，直接kill -9处理掉。然后查找 session 文件的实际位置，通常在~/.openclaw/sessions/或者~/.local/share/openclaw/sessions/下，进入到这个目录删除所有.session和带.lock后缀的文件。做完这两步重新启动 OpenClaw，这个问题九成以上能解决。
还有一种少见但确实存在的情况：你机器上有两个 OpenClaw 实例在同时跑，两个进程各自锁住了对方的 session 文件。这种情况多半是你卸载过一次但没清干净，重新安装了新版本后新旧进程同时存在。按上面步骤把旧进程杀掉，再检查一遍实例列表。
5.2 端口占用排查两板斧
OpenClaw 默认监听的端口就那么几个，如果你在卸载后重装时发现端口被占用，说明卸载时对应的监听进程没有被终止。Linux 下最直接的办法是用lsof找到占用进程：
lsof -i :3000 kill -9 <pid>Windows 下对应操作是：
netstat -ano | findstr :3000 taskkill /PID <进程号> /F如果杀完进程端口还显示被占用，极少数情况是 TIME_WAIT 状态导致。这种状态是 TCP 协议自己产生的，一般过几分钟会自动释放，不用特别处理。但如果你急着重装，可以用系统命令强制重置，不过我不建议新手对这个状态太较真，等一分钟再查基本就没了。
5.3 systemd 服务删了又自己回来
这个现象的朋友大多做过一步错事：只执行了rm删除 service 文件，没有执行daemon-reload。systemd 的机制是启动时读取一次单元文件，运行过程中不会动态重新扫描，所以你不执行daemon-reload，它内存中还保留着旧的单元加载记录。删除文件之后，内存里的记录还活着，一旦执行systemctl restart openclaw，systemd 尝试重新加载时发现磁盘上文件没了，就按它内存里缓存的旧配置自动生成一个新的占位单元，服务就从“已删除”变成“会重生”。
另外还有一种可能，就是 OpenClaw 安装时写过一个定时器单元，比如openclaw-update.timer，它会周期性检查主程序是否存在并尝试重新拉起服务。你要把带 timer 字样的相关文件一并找到并删除，然后再次执行daemon-reload。
5.4 卸载后重装各项异常的处理
重装后最常见的异常有三类：启动报错、飞书输出异常、模型调用失败。启动报错大概率是端口被占用，按 5.2 的方式排查。飞书输出容易被截断这个情况，很多用户以为新版本改了配置就应该自动改善了，实际上如果你重装时没有清理旧配置，新版本会沿用旧版的回复分段策略，自然没有变化。把~/.openclaw/下的旧配置真正删除后再重装，问题大概率消失。模型调用失败则有可能是 API Key 残留在环境变量里，新版本读取环境变量的优先级高于配置文件，导致你配置了新 key 却在调用旧 key。
5.5 几个容易忽略的高频坑位
最后分享几个多数人几乎不会注意到的清理坑位。第一个是系统 PATH 里残留的入口路径。打开终端执行which openclaw有输出说明 PATH 还没清理干净，找到那个残留的二进制文件删除后，再手动从 PATH 里移除对应目录，否则你重装新版本时，openclaw命令实际出来的是旧路径的版本。
第二个是 shell 历史记录和安全日志。虽然这些不影响重装，但既然想彻底卸载，把.bash_history或zsh_history里包含 openclaw 的历史命令一并清理，省得每次按上行键都翻出来一堆脏路径。
第三个是 Docker 构建缓存。如果你使用 Docker 部署，docker system df能查看构建缓存占用空间，这些缓存不直接属于 OpenClaw，但很大概率是 OpenClaw 构建镜像时产生的。执行docker builder prune -f清理一波，磁盘会有惊喜。
第四个是工作目录里的临时文件。OpenClaw 会临时生成一些工具函数文件在/tmp/下，这些文件不会自动清理，长期积累会导致磁盘空间不足。rm -rf /tmp/claw* /tmp/openclaw*收个尾，整个卸载流程才算真正闭环。
6. 写在最后：清理干净再谈下一个工具
我个人在实际操作中的体会是，OpenClaw 的卸载问题从来不是技术难度高，而是覆盖范围太散。官方命令只解决了“移除程序本体”这个问题，但用户真正想解决的是“让这台机器恢复成没装过它的状态”。所以每次看到有人一边卸载 OpenClaw 一边纠结它和 workbuddy 哪个好，我都会劝一句：先把自己机器上的旧环境清干净，再谈工具比较才有意义，不然你装什么都是带着陈年旧债在跑。
如果按照上面的步骤走完，清理后还是觉得哪里不对劲，建议直接重启一次系统再跑一遍检查清单。第二次查出来的残留往往比第一次更多，因为有些锁标记和句柄只有系统彻底重启后才会暴露。这个过程不复杂，就是需要一点耐心。真遇到拿不准要不要删除的目录，宁可先备份再删，也不要留着一个你不了解的旧目录让新版本踩坑。
