1. Разбор боли: клон репозитория ≠ клон рантайма
(1) Каталог состояния и workspace: навыки, промпты и закоммиченный openclaw.json живут в git, а сессии, привязки каналов и кэши шлюза — в профиле пользователя. Перенести только git значит восстановить CLI, но получить пустые каналы или «призрачные» сессии. (2) Секреты и OAuth refresh: Slack, Discord и корпоративные мессенджеры могут хранить токены и в открытом виде, и в зашифрованных хранилищах; если сохранить один слой — будет повторная авторизация; если не остановить старый шлюз — два endpoint соревнуются за одну bot-сессию. (3) launchd и интерактивная оболочка: launchd не наследует экспорт из .zshrc; ключи только в профиле терминала и пустая plist — классика «вручную работает, демон по расписанию без переменных». (4) Границы пользователя на удалённом Mac: аккаунт Screen Sharing/SSH должен совпадать с тем, кто запускает шлюз; смесь root и логина ломает владение файлами и доступ к связке ключей.
Зафиксируйте четыре оси на одной вики-странице: версия OpenClaw, checksum архива, тикет и порядок остановки. Если подкаталоги ~/.openclaw переименовываются между релизами, запишите upstream-путь на момент снимка. При переезде с ноутбука в колокацию перепроверьте DHCP, split-tunnel VPN и DNS search — API, «вчера стабильные», меняют резолвинг и вебхуки улетают в пустоту.
Храните доказательства установки: менеджер пакетов, Node, активный compose-файл на источнике — иначе целевой хост «новее» снимка состояния и CLI дрейфует. В тикет вставьте ссылки на матрицу установки и онбординг, чтобы ревьюеры видели те же гайды.
2. Матрица: что в холодный бандл миграции (2026)
| Объект | Путь / смысл | В бандл? |
|---|---|---|
| Дерево состояния | ~/.openclaw (имена могут меняться — см. upstream) | Да: привязки, кэш, локальные секреты |
| Workspace | Скрипты, навыки, версионируемый openclaw.json | Да: тот же таймстемп снимка, что и у состояния |
| launchd | Plist шлюза в ~/Library/LaunchAgents/ | Да: пользователь, рабочий каталог, имена ENV |
| Docker-тома | Именованные тома или bind-mount | Условно: если совпадает с продакшен-Docker |
| Связка ключей macOS | Некоторые каналы кладут refresh в Keychain | Осторожно: лучше официальный re-auth, не самодельный дамп |
3. Пять шагов: заморозить → упаковать → проверить → холодный старт → пересопрячь
Шаг 1 — остановить писателей: остановите шлюз, launchd или compose на старом хосте, чтобы SQLite и блокировки не менялись во время архива; архив при активных записях даёт случайную порчу после восстановления. Зафиксируйте порядок остановки; многие гасят cron/CI, которые снова открывают state. Несколько compose-проектов останавливайте по зависимостям; сохраните docker ps как доказательство «чистого пола».
Шаг 2 — снимки парами: снимите ~/.openclaw и workspace в один момент, с lockfile; для Docker экспортируйте том или digest образа, чтобы три таймстемпа совпали. На case-sensitive томах и symlink-фермах сначала разрешите реальные пути. Решите явно, входят ли кэши pnpm/npm в бандл или пересобираются — смесь «старый state + свежие зависимости» без записи даёт гейзенбаги в смоук-тестах каналов.
Шаг 3 — проверка и зачистка: checksum перед распаковкой; замените старые хосты, абсолютные пути, LAN-only URL; обновите USB-серийники, веса моделей, smb-монты; grep по IP-литералам — домашний DHCP часто ломает вебхуки.
Шаг 4 — холодный старт шлюза: минимальная поверхность (loopback admin), openclaw doctor или лестница проекта, проверка логов, прав, слушателей по контракту plist. Первый канал не включайте, пока doctor не зелёный; OAuth наполовину заполненного ENV оставляет «полу-состояние» у вендора. Снимите базовую CPU/RAM и проверьте debug-флаги.
Шаг 5 — пересопряжение каналов: OAuth/вебхуки по правилам вендора; два активных бота с одними учётными данными обычно запрещены — полностью снимите старый инстанс перед новым, чтобы не было двойных доставок и конфликтов подписи. По возможности ротируйте app secret для аудита; после пересопряжения — скриптовые send/recv пробы, а не ручные клики.
Опционально: выпишите TTL внешнего DNS и смену провайдера туннеля, чтобы кэш не бил в старый endpoint после смены IP/хоста.
На практике полезно приложить к архиву манифест версий: вывод openclaw --version, хеш git репозитория skills, версии Node и пакетного менеджера. Эти строки стоят секунд, но экономят часы, когда новый Mac случайно получает более свежий toolchain и странные ошибки появляются только при вызове конкретного инструмента в канале.
Если вы используете облачное хранилище (iCloud Drive, Dropbox) для workspace, убедитесь, что файлы реально материализованы на диске до архивации — частично синхронизированные деревья дают «успешный» tarball с дырками, которые всплывают только на проде.
ЦИФРЫ / ПОРОГИ (ДЛЯ ЦИТИРОВАНИЯ)
① Тройка снимков: ~/.openclaw + workspace + plist (или compose + манифест томов). Не хватает одного — миграция неполная.
② Окружение: EnvironmentVariables в plist должны явно совпадать с тем, на что опираетесь в shell — API-ключи, прокси, часовой пояс.
③ Переключение канала: окно охлаждения между старым и новым ботом; тишина вендора может быть серой минутной выкладкой.
④ Удалённый Mac: пользователь SSH = пользователь шлюза; не смешивайте UID между GUI и безголовым launchd.
⑤ Откат: read-only архив старого хоста минимум один релизный цикл до удаления перезаписываемых копий.
4. Параметры: процесс «зелёный», каналы молчат
Самый обманчивый режим — здоровые процессы и пробы, но нет входящих. Bind-адреса: переход 127.0.0.1 → LAN без reverse proxy/фаервола. Вебхуки: консоли должны указывать новый туннель или статический egress; забытые Slack/Feishu — тихие потери. Время и TLS: большой сдвиг NTP или корпоративная инспекция TLS. tools.profile: белые списки с абсолютными путями бинарей — пройдите разбор sessions_spawn и расширьте allowlist осознанно.
Если неясно, соберите четыре артефакта до тикета вендора: редактированная plist, точный публичный URL, tcpdump/прокси по TLS, срез логов с полным inbound event id. Это отделяет «HTTP не пришёл» от «пришёл, подпись отвергнута». Держите мини-глоссарий полей дашборда ↔ ключей конфигурации.
Добавьте в ранбук строку про исходящие вебхуки к внутренним API за VPN: удалённый Mac должен иметь те же split-tunnel маршруты и корневые сертификаты, что и старый ноутбук — иначе TLS-ошибки маскируются под таймауты приложения.
Ежеквартально распаковывайте прошлый архив на тестовый Mac, doctor, вебхук-пробы. Команды с согласованными снимками восстанавливаются за часы; «только репозиторий» тратит дни на дифф невидимого state. Молчание трактуйте как сеть и идентичность, а не как «модель тупит». Запланируйте пятиминутный просмотр логов на новом хосте ещё до включения внешних интеграций — это дешевле, чем ночной разбор без единой строки контекста.
5. Решение: ноутбук vs выделенный удалённый Mac
Таблица обобщает компромиссы; на практике решают on-call и требования к стабильности вебхуков. Для команд, которые уже читают материал по systemd/launchd, перенос на удалённый Mac часто упрощает сопоставление расписаний перезапуска с окнами обслуживания облачных провайдеров мессенджеров.
Учитывайте также человеческий фактор: если только один инженер знает, какие переменные спрятаны в личном профиле shell, миграция превращается в bus factor. Документируйте имена переменных и их владельцев до переноса железа, иначе новый Mac будет «зелёным» в мониторинге и пустым по смыслу для остальной команды.
| Ось | Локальный ноутбук | Удалённый Mac |
|---|---|---|
| Доступность | крышка, сон, поездки | чище граница 24/7 для каналов |
| Права | удобный GUI-debug | дисциплина headless — без блокирующих prompt |
| Сеть | меняющийся residential IP | стабильный egress или tunnel-домен |
| Стоимость | скрытая амортизация | прозрачная аренда под SLA |
6. FAQ
Ниже — типовые вопросы по миграциям OpenClaw в 2026; при работе с ПДн или регулируемыми данными добавьте юридический блок про резидентность логов.
В: Синхронизировать только workspace? Для чистых CLI-экспериментов можно, категорически не рекомендуется, если важны каналы или непрерывность сессий — сожжёте больше часов, чем сэкономите на размере tarball. В: Docker → bare metal? Как смена стека плюс миграция, одна целевая форма в документации. В: API-ключи в plist открытым текстом? Работает, но гигиена слабая; защищённые env или секрет-бэкенд. В: Всегда нужен Screen Sharing? Рутина по SSH; VNC для первого OAuth или GUI-only, с тикетом. В: Стереть старый ноутбук сразу? Параллельное наблюдение хотя бы один бизнес-цикл.
В: Тестировать каналы без прода? Staging-приложения и ограниченные workspace, но пути вебхуков и TLS должны быть реалистичны. В: Смешанные Apple ID? Чётко кто владеет launchd; смены GUI логинов дают EACCES, похожие на сеть. В: Нужны ли compose overrides? Да, версионируйте рядом с архивом и укажите в тикете.
В: Апгрейд OpenClaw в том же окне? Сначала та же версия, проверка каналов, потом отдельный тикет с откатом. В: MDM-заблокированные Mac? Согласуйте plists, хелперы, сетевые расширения. В: Мультирегион? Документируйте владение логами и токенами; копирование state между регионами может нарушать резидентность.
В: Стоит ли автоматизировать распаковку архива Ansible/Terraform? Да, но только после того, как ручной прогон по этому ранбуку прошёл без сюрпризов — иначе вы закрепите ошибку в инфраструктурном коде и будете откатывать уже не Mac, а пайплайн.
В: Нужно ли менять пароли сервисных аккаунтов при миграции? Если политика безопасности требует ротации при смене хоста, запланируйте её до включения каналов — иначе вы отладите сеть дважды: сначала как инфраструктурную проблему, потом как учётную. В: Как быть с самоподписанными сертификатами для внутренних webhook? Перенесите цепочку доверия и обновите trust settings на новом Mac; недостающий корневой сертификат даёт одинаково бесполезные логи на стороне клиента и сервера.
7. Углубление: миграция переносит state и идентичность вместе
В 2026 году агенты OpenClaw оцениваются не «установился ли», а какие процессы читают/пишут state и как внешние идентичности мапятся на сессии. Код без state — переезд офиса без сейфа. openclaw.json задаёт политику; профиль хранит уже согласованные с третьими сторонами креды — оба должны переехать одной логической транзакцией, иначе doctor зелёный, каналы немые.
Раскол launchd и shell: ключи в .zshrc, пустая plist — размытые 401; перегруженная plist без владения лог-путями блокирует ротацию. Таблица крест-проверки plist / shell / CI для каждой чувствительной переменной.
Пересопряжение — не формальность: один активный endpoint; два бота дублируют доставку и триггерят abuse. Серьёзный ранбук: вывод старого инстанса, затем продвижение нового с серым окном. WeChat, Feishu, Slack, Discord — разные cooldown и IP allowlist; одного шаблона мало.
На арендованных Mac разделяйте GUI для OAuth и безголовые сервисы с автоперезапуском — Apple Silicon headless. Узлы MACGPU фиксируют топологию; ноутбук снова для творчества, а не как термально урезанный сервер — как npm vs Docker: сначала истина, потом каналы и SLA.
Операционное совершенство — квартальные репетиции сбоев: архив, doctor, пробы. «Только репо» тратит дни. Неправильный egress маскируется под «модель думает».
Сравните подход к миграции с тем, как вы разворачиваете продакшен-пайплайны из Docker-гайда: там же важны согласованные тома, переменные окружения и порядок остановки — перенос OpenClaw на новый Mac отличается лишь тем, что «оркестратором» выступает launchd и пользовательская связка ключей, а не Kubernetes.
Бэклог приёмки по каналам: ожидаемая задержка, допустимые ошибки, эскалация если вебхуки молчат дольше порога; авто-тикеты при зелёных healthcheck без реальной нагрузки. Календарь обслуживания с обновлениями Apple: неожиданный ребут без порядка plist/томов даёт ту же тишину, что и битый токен.
Наблюдаемость рано: структурированные логи с Mac, версия OpenClaw и git SHA skills на алерте, тег post-migration до конца обкатки. Ночь патча без этого — боль. Это не только файлы: восстановить доверие, выровняв токены, URL, сертификаты один раз на новом железе.
Фиксируйте коридоры ёмкости: одновременные каналы, пики вложений, unified memory рядом с другими сервисами. Недобранный удалённый Mac даёт редкие таймауты, похожие на сбой вендора. Свяжите метрики с systemd/launchd и Docker прод для общего языка при следующем железе.
Дополнительно отметьте опциональные бинарии, которые tools.profile разрешает: миграция часто вскрывает отсутствие утилиты, которая была только на старой машине.
Если в организации действует корпоративный антивирус или DLP-агент на macOS, заранее согласуйте исключения для каталогов логов и сокетов шлюза — после миграции новый профиль безопасности может блокировать локальные порты или переписывать TLS, что снова выглядит как «тишина канала». Зафиксируйте номера тикетов ИБ рядом с техническим тикетом миграции.
Для команд с несколькими средами (dev/stage/prod) полезно иметь матрицу соответствия токенов: какой client_id относится к какому ingress URL и какому Mac-аккаунту. Без неё легко включить staging-токен против production-вебхука после копирования plist между машинами — симптомы будут похожи на сетевой сбой, хотя проблема в неверной паре учётных данных.
Наконец, опишите порог отката: при каком времени простоя канала или проценте ошибок вы возвращаетесь к read-only копии старого хоста и повторно отключаете новый ingress. Это превращает миграцию из «однонаправленного прыжка» в управляемый эксперимент с заранее известной ценой отмены.
8. Финал: быстро можно только с полным чек-листом
Перед срезом трафика на новый Mac зафиксируйте контрольные суммы архива и хэш коммита skills-репозитория; при расхождении с тикетом остановите переключение и пересоберите бандл. Для смешанных сценариев (часть каналов уже на новом хосте, часть ещё на старом) опишите явный порядок переключения и окно наблюдения — иначе половина команды будет смотреть на зелёный healthcheck, а клиенты увидят дубли или тишину в зависимости от маршрута. Добавьте к ранбуку ссылку на актуальную версию CLI и заметку о том, какие переменные окружения считаются секретами и где они хранятся после миграции. Это сокращает время разбора инцидентов на следующей неделе и помогает новым участникам смены быстро войти в контекст.
(1) Ограничения: layout state меняется между major — semver рядом с архивом; compliance может запретить клон связки ключей целиком — закладывайте re-auth. (2) Почему удалённый Mac выигрывает: фиксированные пользователь, egress, класс железа сокращают хвост инцидентов «ноутбук как сервер». (3) MACGPU: репетируйте хостинг шлюза на арендованном Apple Silicon до фиксации топологии — главная, тарифы, помощь. Каждая миграция — репетиция следующей: не экономьте на бандле state — дешёвая страховка от ночных регрессов, пустых эскалаций и тикетов поддержки без сигнала. В постмортемах добавляйте ссылку на этот чек-лист и на разбор sessions_spawn, чтобы следующий сбой не начинался с чистого листа.