OpenClaw 主实例迁移到新主机后，旧主机上的清理工作同样重要。
很多迁移事故并不是发生在复制文件时，而是发生在迁移之后：旧服务还在、旧命令还能执行、旧配置目录仍然存在、shell 里还保留 alias 或 PATH。表面上看主实例已经迁走，实际上旧主机仍然残留一个“半可用”的 OpenClaw 实例。
这种状态非常危险。因为一旦旧实例被误启动，就可能出现两个 OpenClaw 同时存在的情况：
新主机上的 OpenClaw：
- 作为正式主实例运行
- 接收消息通道请求
- 保存新的状态和记忆
旧主机上的 OpenClaw：
- 残留旧配置
- 残留旧服务
- 可能仍然监听旧端口
- 可能仍然引用旧 workspace
清理旧实例的目标，不是简单删除几个目录，而是让旧主机彻底退出 OpenClaw 主运行链路。
旧实例清理的核心原则
迁移完成后，系统里应该只有一个 OpenClaw 主实例。
旧主机可以继续作为扩展资源主机，例如提供浏览器、图形环境、大型项目目录或临时计算能力，但它不应该再保留可启动的 OpenClaw gateway，也不应该再保留容易误用的 OpenClaw 命令入口。
清理的目标可以概括为：
保留：
- 明确需要的扩展目录
- 明确需要的浏览器 profile
- 明确需要的大型项目目录
删除或禁用：
- 旧 OpenClaw 安装目录
- 旧状态目录
- 旧 systemd user service
- 旧命令入口
- 旧 shell alias
- 旧 PATH
- 旧 completion
- 旧迁移临时目录
最重要的是，不要让旧主机继续具备“像主实例一样启动 OpenClaw”的能力。
区分安装目录和状态目录
清理旧实例时，第一个容易混淆的问题是：OpenClaw 的安装目录和状态目录不是一回事。
常见结构大致如下：
旧软件安装目录：
<old-host-app-install-dir>
旧状态目录：
<old-host-openclaw-state-dir>
旧工作区：
<old-host-workspace-dir>
软件安装目录通常包含 OpenClaw 程序本体、Node runtime、工具链、dist 文件等。状态目录则包含配置、session、插件状态、浏览器 profile、缓存、认证引用等内容。工作区则保存用户交互产生的文件、memory、projects、output、plans 等。
如果只删除状态目录，而保留安装目录和命令入口，旧实例仍然可能被启动。
如果只删除安装目录，而保留状态目录，旧配置、旧 session、旧浏览器 profile 和旧缓存仍然会留在系统里。
如果只清理 workspace，而不清理 systemd 服务，旧服务可能在某次登录或重启后继续尝试启动，并产生新的错误日志。
因此，清理旧实例必须同时检查三类内容：
1. 程序本体是否还在
2. 状态目录是否还在
3. 启动入口是否还在
停止旧 systemd user service
旧主机上最需要优先处理的是 systemd user service。
如果旧 OpenClaw 曾作为用户级服务运行，那么即使手动退出过程序，systemd 仍然可能在登录、重启或服务恢复时尝试重新拉起它。
需要检查的内容包括：
- 是否存在 openclaw-gateway.service
- 是否 enabled
- 是否 active
- 是否还有 drop-in override
- ExecStart 是否指向旧安装目录
- Environment 是否引用旧 PATH 或旧配置
理想状态是：
旧 OpenClaw gateway service：
- 不存在，或 disabled
- 不 active
- 没有残留 symlink
- 没有残留 drop-in
- systemctl --user status 显示 not-found 或 inactive
清理时，不应只执行 stop。因为 stop 只影响当前运行状态，不能阻止下次自动启动。更稳妥的顺序是：
1. disable
2. stop
3. 删除 service 文件和 drop-in
4. systemctl --user daemon-reload
5. 再次确认 service 不存在或不可启动
这一步的目的，是让旧主机不再具备自动启动旧 OpenClaw gateway 的能力。
处理旧命令入口
除了 systemd 服务，命令入口也是常见残留。
旧主机上可能曾经配置过：
openclaw
oc
openclaw tui
openclaw gateway
这些入口可能来自：
- ~/bin/openclaw
- ~/.local/bin/openclaw
- 自定义 symlink
- shell alias
- PATH 中的旧安装目录
- completion 脚本
清理时需要确认：
command -v openclaw
type -a openclaw
command -v oc
type -a oc
如果这些命令仍然指向旧主机上的 OpenClaw 安装目录，就说明旧实例仍然有被误用的风险。
尤其要注意 shell alias。即使文件已经删除，当前 shell 会话中仍然可能保留 alias。例如：
alias oc='openclaw tui ...'
这类 alias 可能只存在于当前 shell，会在新终端消失；也可能写在 shell 配置文件中，未来每次启动终端都会恢复。
因此需要同时检查：
- 当前 shell 中是否还有 alias
- shell 配置文件中是否还有 alias
- PATH 中是否还有旧 OpenClaw 安装路径
- completion 中是否还有旧 OpenClaw 配置
清理完成后，旧主机上执行 OpenClaw 命令应该无法找到旧实例，或者明确指向新的远程管理方式，而不是旧本地安装。
清理旧安装目录
确认旧服务和命令入口都已停止后，才能处理旧安装目录。
旧安装目录通常体积较大，可能包含：
- OpenClaw 程序文件
- bundled runtime
- node_modules
- tools
- 插件依赖
- 旧版本文件
删除前需要确认两点：
1. 新主机上的 OpenClaw 主实例已经正常运行
2. 旧主机不再需要本地 OpenClaw 程序本体
如果旧主机未来只作为扩展资源主机，例如提供浏览器/CDP 或大型项目目录，就不需要保留旧 OpenClaw 程序本体。
保留旧安装目录的坏处是：
- 容易误启动
- 容易混淆当前主实例
- 占用磁盘空间
- 后续排查时不知道哪个实例有效
因此，迁移完成并验证新主机可用后，旧安装目录应该删除或至少移出 PATH。
清理旧状态目录
旧状态目录包含更多敏感和历史状态，因此不能一开始就粗暴删除。
它可能包含：
- config
- secrets 引用
- sessions
- transcripts
- plugins
- npm managed plugins
- browser profile
- cache
- workspace attestation
清理旧状态目录前，应先确认：
- 主配置已经迁移到新主机
- sessions / transcript 没有丢失
- dashboard 和消息通道已在新主机恢复
- 需要保留的浏览器 profile 已经单独迁出或重建
- 旧状态目录不再被任何服务引用
如果旧状态目录里包含浏览器 profile，而浏览器能力仍然需要保留在旧桌面机上，就不能直接删除整个目录。更好的做法是把浏览器 profile 迁到一个新的、明确命名的专用目录中，例如：
<old-host-browser-cdp-dir>/user-data
这样，浏览器 profile 从旧 OpenClaw 状态目录中剥离出来，成为一个独立的扩展资源，而不是旧实例残留。
清理旧状态目录的最终目标是：
旧状态目录不存在
新浏览器 profile 目录存在
旧服务不再引用旧状态目录
旧命令入口不再引用旧状态目录
保留必要的扩展资源
旧主机不再作为主实例，并不意味着旧主机上所有 OpenClaw 相关目录都要删除。
迁移后可以保留两类资源：
第一类是浏览器/CDP 专用目录。
<browser-cdp-dir>/user-data
这个目录只用于远程浏览器能力，不代表旧 OpenClaw 实例仍然存在。它应该被明确记录为“外部工具资源”。
第二类是大型项目目录。
<old-host-workspace>/projects/<large-project>
如果新主机容量有限，大型项目可以暂时保留在旧主机上，由主实例在需要时通过 SSH 调用。
这类目录的关键是命名和边界要清楚。旧主机上保留的是扩展资源，不是旧主实例。
清理 shell 配置残留
很多迁移清理会漏掉 shell 配置。
旧主机上可能在以下文件中留下 OpenClaw 相关内容：
~/.bashrc
~/.zshrc
~/.profile
~/.bash_profile
~/.config/fish/config.fish
残留内容可能包括：
- PATH 追加旧安装目录
- alias openclaw
- alias oc
- completion source
- 环境变量
- 旧 gateway 地址
- 旧 workspace 路径
这些内容未必会立刻报错，但会让后续排查变得混乱。尤其当 type -a 显示当前 shell 仍然有 alias，而配置文件里已经删除时，需要区分“当前会话缓存”和“长期配置残留”。
清理完成后，应重新打开一个 shell，再检查命令解析结果，而不只依赖当前 shell。
迁移临时目录和归档
迁移过程中通常会产生临时目录，例如：
- migration bundle
- before restore backup
- final before delete archive
- old service backup
- audit report
这些目录不应该和正式工作区混在一起。
比较稳妥的处理方式是：
- 短期保留迁移归档
- 把旧 service 文件归入 Archives
- 把审计报告保存在新主机
- 确认迁移无误后再逐步删除大体积归档
迁移刚完成时，不建议立刻删除所有归档。因为如果发现历史会话、插件配置、浏览器 profile 或 memory 文件有问题，归档可能是最后的恢复来源。
但也不应该长期让归档散落在旧主机的工作目录中。它们应该被明确标记为 archive，而不是可运行实例的一部分。
清理后的验收标准
旧实例清理完成后，应达到以下状态：
旧主机：
- 没有旧 openclaw gateway service
- 没有旧 OpenClaw 安装目录
- 没有旧 OpenClaw 命令入口
- 没有旧 shell alias / PATH 残留
- 没有旧状态目录作为主实例存在
- 不监听旧 gateway 端口
- 不再接收消息通道请求
新主机：
- OpenClaw gateway 正常运行
- Dashboard 可访问
- 消息通道正常回复
- 插件正常加载
- 主工作区和状态目录为唯一事实来源
旧主机保留：
- 明确命名的浏览器/CDP 目录
- 明确命名的大型扩展项目目录
- 必要的归档或审计报告
这组验收标准比“旧程序删了”更可靠。因为它从服务、命令、状态、端口、工作区和保留资源多个角度确认旧实例已经退出运行链路。
旧实例清理的经验
这次清理最重要的经验是：不要把 OpenClaw 旧实例理解成一个目录。
它至少包括：
- 安装目录
- 状态目录
- 工作区
- systemd 服务
- drop-in override
- 命令 symlink
- shell alias
- PATH
- completion
- 迁移临时目录
- 旧浏览器 profile
如果只删除其中一部分，就可能留下一个半残状态。
迁移后的旧主机清理，本质上是在回答一个问题：
这台旧主机是否还可能被误认为 OpenClaw 主实例？
只要答案仍然是“有可能”，清理就还没有完成。
小结
OpenClaw 主实例迁移后，旧主机清理是必不可少的一步。
真正安全的清理不是简单删除 .openclaw 或某个安装目录，而是确认旧主机已经不再具备主实例能力：
- 不能自动启动
- 不能手动误启动
- 不能继续监听 gateway
- 不能继续保存主状态
- 不能混淆新旧 workspace
- 不能让 shell 命令指向旧实例
同时，旧主机仍然可以保留明确边界的扩展资源，例如浏览器/CDP profile 和大型项目目录。关键在于：这些资源必须从旧 OpenClaw 实例中剥离出来，成为新主机按需调用的外部能力。
这样清理完成后，系统结构才真正清楚：
新主机负责 OpenClaw 主实例。
旧主机只提供被明确授权的扩展资源。
这一步完成后，迁移才不只是“新主机能跑”，而是“旧主机不会再干扰”。