Удалённый IDE-мост ломается предсказуемо: агент получает слишком широкие права и переписывает домашний каталог, либо шлюз OpenClaw «технически жив», но модели и пути уже в неверном состоянии — и об этом узнают post-factum. Связка «только чтение для кода + отдельная зона записи + loopback-шлюз + узкотокен + doctor и /health по расписанию» превращает сценарий в инженерную процедуру, а не в гадание по логам.

Текст рассчитан на команду, которая уже поставила OpenClaw на удалённый Mac (см. документацию · раздел OpenClaw) и работает через SSH с единым корнем рабочей области в VS Code, Cursor или аналоге. Мы дополняем тему OpenClaw и автоматизация акцентом на границу доверия и наблюдаемость: где именно разрешена запись, как аутентифицируется шлюз и как фиксируется масштаб изменений. Если на том же узле крутится локальный RAG, перенесите дисциплину путей из матрицы локального RAG. Контекст платформы — на главной; для выделенного узла под долгоживущий шлюз смотрите каталог покупки и регионы: Гонконг, Сингапур, Токио, Сеул, восток США, запад США.

Содержание

Три типичных провала без песочницы

1. Раздутый периметр записи. Когда агенту доступен весь $HOME, одна ошибочная команда может затронуть ключи SSH, личные проекты и кэши пакетных менеджеров. Откат превращается в ручной аудит десятков каталогов, а не в git revert.

2. Слепота к изменениям. Без регулярных сводок git diff --stat команда не знает, вырос ли дифф на сотни файлов из-за автогенерации или точечного рефакторинга. Ревью и постмортемы начинаются с фразы «кажется, что-то поменялось».

3. Ложное чувство стабильности. Процесс шлюза может продолжать слушать порт, пока пути к весам, кэшу или токену уже несогласованы. Без зафиксированного вывода openclaw doctor и периодического HTTP-запроса к /health деградация обнаруживается только когда IDE перестаёт отвечать.

Матрица: открытый удалённый каталог vs мост с разделением

Ниже — сжатое сравнение для сознательного выбора. «Открытый» вариант быстрее на старте, но дороже в эксплуатации при агентах и ночных джобах.

Аспект Открытая рабочая область Мост repo + scratch
Где пишет автоматизация Часто весь клон или домашний каталог Только ~/ide-bridge/scratch и явно разрешённые пути
Шлюз OpenClaw Риск привязки к 0.0.0.0 или публичному порту 127.0.0.1 + SSH reverse tunnel или приватная сеть
Токен Переменные окружения в профиле, утечки в историю Файл 0600, OPENCLAW_TOKEN_FILE, минимальные scope
Аудит изменений Разрозненные логи или их отсутствие Ежедневные файлы diff-*.log в scratch/probe
Проверка здоровья Ручной перезапуск «если что» doctor --json + launchd/curl на /health

Инвариант, который стоит защищать политикой: по умолчанию автоматизация не переписывает каноническое дерево исходников. Интерактивный разработчик может иметь отдельный клон или worktree с правами записи; учётная запись или роль шлюза — нет.

Принципы (минимальные привилегии в 2026)

  • Loopback для управляющего API. Привязывайте openclaw gateway listen к 127.0.0.1. Наружу выносите только то, что понимает ваш периметр (SSH-туннель, mTLS, zero-trust), а не «голый» TCP в интернет.
  • Токен как файл, не как стикер на мониторе. Выдавайте scope вроде чтения рабочей области и белого списка команд исполнения; храните значение в файле с правами chmod 600 и подключайте через OPENCLAW_TOKEN_FILE. Так проще ротировать секрет и не светить его в export в истории shell.
  • Два корня на диске. ~/ide-bridge/repo — представление кода для IDE и агентов в режиме только чтения; ~/ide-bridge/scratch — сборки, пробы, логи gateway, временные модели и всё, что может разрастись без контроля.
  • Статистика diff до и после. Полный текст патча в CI не всегда нужен; блок --stat даёт порядок величины изменений и годится для алертов при аномальном числе файлов.
  • Сначала doctor, потом частые пробы. Смысла опрашивать /health каждые пять минут нет, если базовая диагностика уже падает: сначала зелёный openclaw doctor, затем автоматизация мониторинга.

Шесть воспроизводимых шагов

Шаг 1 — каталоги и права. На удалённом Mac выполните:

mkdir -p ~/ide-bridge/repo ~/ide-bridge/scratch/probe # после клонирования кода в repo снимите запись (пример) chmod -R a-w ~/ide-bridge/repo

Если интерактивному пользователю нужна запись в дерево, используйте второй клон, Git worktree или ACL: интерактив пишет в своей ветке, а сервисный пользователь шлюза остаётся на только чтение. Это снижает риск «тихого» chmod, который ломает модель песочницы.

Шаг 2 — токен шлюза. Сгенерируйте токен через CLI вашей версии OpenClaw с минимально достаточными правами (имена подкоманд смотрите в release notes). Запишите в ~/.openclaw/gateway.token, выполните chmod 600. В ~/.zprofile или в словаре EnvironmentVariables plist для launchd добавьте export OPENCLAW_TOKEN_FILE="$HOME/.openclaw/gateway.token". Не коммитьте файл и не дублируйте сырое значение в hook-скриптах репозитория.

Шаг 3 — шлюз только на loopback. Пример (порт согласуйте с плагином IDE):

openclaw gateway listen \ --bind 127.0.0.1:18765 \ --token-file "$HOME/.openclaw/gateway.token"

Для устойчивости оберните команду в launchd с KeepAlive и перенаправлением stdout/stderr в ~/ide-bridge/scratch/logs/gateway.log. С ноутбука пробросьте порт, например ssh -R 18765:127.0.0.1:18765 user@remote, чтобы клиент всегда стучался в локальный интерфейс на Mac, а не в публичный bind.

Шаг 4 — корень IDE. Откройте через Remote-SSH каталог ~/ide-bridge/repo. Переменные вроде выходной директории сборки, временных каталогов тестов и кэша OpenClaw направьте в ~/ide-bridge/scratch через настройки workspace или обёртки скриптов. Так случайные артефакты не засоряют только читаемое дерево и не требуют ослаблять chmod ради одной сборки.

Шаг 5 — сводки diff. В начале и в конце точки входа автоматизации дописывайте статистику в дневной лог:

LOG=~/ide-bridge/scratch/probe/diff-$(date +%F).log { echo "=== $(date -Iseconds) pre ==="; git -C ~/ide-bridge/repo diff --stat; \ git -C ~/ide-bridge/repo diff --cached --stat; } >> "$LOG" # ... задача ... { echo "=== $(date -Iseconds) post ==="; git -C ~/ide-bridge/repo diff --stat; \ git -C ~/ide-bridge/repo diff --cached --stat; } >> "$LOG"

При пакетных правках агента по многим модулям блок --stat быстрее полного диффа и всё равно сигнализирует о всплеске изменений — удобно для порогов в мониторинге или ручного ревью.

Шаг 6 — doctor и health-пробы. После смены моделей, путей или токена сохраните базовую линию:

openclaw doctor --json > ~/ide-bridge/scratch/probe/doctor-last.json

Затем добавьте задание launchd (или cron на той же учётной записи), которое каждые пять минут выполняет:

curl -fsS -H "Authorization: Bearer $(cat ~/.openclaw/gateway.token)" \ http://127.0.0.1:18765/health \ || echo "$(date -Iseconds) health FAIL" >> ~/ide-bridge/scratch/probe/health.log

Типичные кластеры сбоев: переполненный диск, занятый порт, устаревший токен после ротации, «зависший» воркер, который отвечает TCP, но не прикладной логике. Сочетание doctor, ручного curl от того же пользователя и просмотра лимитов дескрипторов через launchctl print обычно отделяет сетевые от процессных причин. Класс CPU на странице тарифов здесь вторичен по сравнению с дисциплиной ФС и сервиса.

FAQ по устранению неполадок

/health отвечает 401 или 403. Проверьте права на файл токена, точное написание заголовка Authorization: Bearer … и перезапуск всех потребителей после ротации. Смешение старого и нового секрета в разных сессиях — частая ловушка.

IDE сообщает EROFS при сохранении. Вы пишете в только читаемый repo. Перенаправьте правки в разрешённый worktree, собирайте патчи в scratch и вливайте через пайплайн; для интерактива временно ослабляйте права только интерактивному пользователю, не учётке шлюза.

openclaw doctor ругается на кэш. Закрепите корень кэша в ~/ide-bridge/scratch/openclaw-cache в конфигурации, чтобы дефолт не указывал на сетевой home или том только для чтения.

Статистика diff пустая. Убедитесь, что git -C указывает на корень с .git. Для субмодулей добавьте отдельные вызовы git -C путь/к/субмодулю или рекурсию в скрипте.

Шлюз «висит», а /health зелёный. Зонд может быть слишком поверхностным: расширьте проверку до read-only метаданных рабочей области, сравнивайте doctor во времени, смотрите лимиты FD и throttling launchd — под нагрузкой исчерпание дескрипторов похоже на зависание.

SSH-туннель рвётся ночью. Настройте ServerAliveInterval на клиенте и ClientAliveInterval на сервере либо небольшой watchdog, который пересоздаёт reverse mapping и пишет в scratch/probe.

Кратко: минимальные привилегии — это только чтение для repo, запись в scratch, шлюз на loopback и узкий токен. Наблюдаемость — базовый doctor --json, дневные логи diff --stat и периодические пробы /health. Следуя шести шагам выше, можно держать IDE-мост на удалённом Mac без передачи всей машины одному эксперименту.