Как развернуть VS Code Agent Host на облачном Mac? Руководство 2026

Клиент VS Code закрывается, а долгий Agent-задача обрывается или оставляет непонятные изменения в Xcode-проекте.

Самое быстрое решение: разместите Agent Host как отдельный удалённый процесс на облачном Mac рядом с репозиторием и инструментами Xcode, подключайтесь по SSH или через Dev Tunnels, а каждую задачу запускайте в изолированном Git worktree; после этого отдельно проверьте продолжение, синхронизацию окон и откат.

Последняя проверка актуальности: 3 сентября 2026 года. Сведения сверены с архитектурной документацией VS Code, документацией удалённых Agent-сессий, справочником настроек AI, материалами по SSH и Dev Tunnels, а также официальными документами Apple по Xcode.

Эта статья для вас, если вы запускаете Copilot, Claude или Codex в проектах для iOS и macOS и хотите, чтобы длительная работа продолжалась после закрытия ноутбука. Она также рассчитана на платформенных инженеров, которым нужно управлять удалёнными сессиями, worktree и учётными данными, и на руководителей AI Coding-команд, оценивающих эластичную ёмкость облачных Mac.

Сначала разделите Agent Host, модель и macOS

В архитектуре есть несколько самостоятельных компонентов, и смешивать их опасно:

• Agent Host сохраняет состояние сессии, принимает подключения клиентов, запускает Agent harness и выполняет действия в удалённой рабочей области.
• Agent harness — это конкретный исполнитель, например GitHub Copilot, Claude или Codex. У каждого могут отличаться вход через аккаунт, модель, подтверждения действий и экспериментальные настройки.
• Провайдер модели формирует ответы и решения, но не является удалённой macOS-средой.
• Клиент VS Code показывает сессию, отправляет команды и может предоставлять дополнительные инструменты.
• Облачный Mac фактически запускает shell-команды, сборку, тесты, Xcode, Simulator и доступ к файлам.

Официальная архитектура VS Code подтверждает, что Agent Host может работать как локальный процесс или как отдельный удалённый сервис, к которому подключаются несколько клиентов. Подробная схема ответственности компонентов приведена в официальном описании архитектуры Agent Host.

Это означает важное ограничение: сохранённая сессия не превращает рабочую среду в безопасную песочницу. Если процесс имеет доступ к домашнему каталогу, SSH-ключам, связке ключей macOS или секретам CI, продолжение после отключения клиента лишь сохраняет возможность выполнить опасное действие. Изоляцию нужно строить на уровне отдельного пользователя, рабочей директории, прав доступа, секретов и самого облачного Mac.

Перед запуском письменно зафиксируйте:

• какие репозитории разрешено открывать;
• какие команды Agent может выполнять без подтверждения;
• может ли он устанавливать зависимости;
• какие токены доступны и на какой срок;
• где создаются артефакты;
• кто удаляет worktree, логи и временные ключи после завершения.

Если задаче не нужны Xcode, macOS SDK, Simulator, подпись приложения или проверка поведения именно в macOS, сначала сравните её с обычным Linux- или локальным исполнением. Облачный Mac оправдан тогда, когда macOS-инструменты являются частью результата, а не просто удобным местом для запуска модели.

Опыт: отдельный Mac для долгих Agent-сессий лучше считать исполняемым узлом, а не «удалённым окном VS Code». Такая формулировка сразу заставляет проверить права, журналы, очистку и восстановление после перезагрузки.

Подготовьте узел и зафиксируйте путь подключения

Для пилота выбирайте Mac, расположенный рядом с исходным репозиторием и нужной цепочкой сборки. Если код находится в другом удалённом хранилище, проверьте не только задержку подключения, но и способ выдачи токена, скорость клонирования, доступ к пакетным реестрам и возможность загрузить артефакты без обходных копирований.

На самом Mac подготовьте отдельную учётную запись или иной административно подтверждённый контур для Agent Host. Не запускайте Host от пользователя, в чьём профиле без необходимости лежат личные ключи, профили подписи и рабочие документы. Установите поддерживаемую версию VS Code и проверьте актуальное состояние функции по официальным заметкам о релизах VS Code, прежде чем фиксировать инструкцию для команды.

SSH и Dev Tunnels: выберите один управляемый вход

Подключение Agent Host к удалённому Mac по SSH обычно проще включить в существующую корпоративную модель: вы контролируете пользователя, ключ, known_hosts, сетевой доступ и отзыв разрешений. Обратная сторона — необходимость поддерживать сетевой маршрут, правила firewall и ротацию ключей.

Dev Tunnels могут быть удобнее, когда прямой входящий маршрут до Mac нежелателен или когда доступ должен проходить через управляемую туннельную схему. При этом появляется отдельный контур идентификации и политики доступа. Настройки безопасности и ограничения такого режима нужно сверять с документацией VS Code по Remote Tunnels, а не переносить из старого SSH-runbook.

Нужен ли SSH или Dev Tunnels для Agent Host на удалённом Mac? Выбирайте SSH, если ваша команда уже умеет управлять ключами, пользователями и сетевыми правилами. Выбирайте Dev Tunnels, если основное требование — не открывать прямой сетевой вход и централизовать доступ через поддерживаемую туннельную модель. Не оставляйте оба варианта включёнными «на всякий случай»: лишний путь входа усложняет аудит и отзыв прав.

Сохраните рядом с заявкой на пилот:

• версию VS Code и статус канала обновлений;
• способ запуска Agent Host;
• имя удалённого пользователя;
• выбранный способ соединения;
• область доступа к репозиторию;
• результат первой проверки подключения;
• процедуру остановки Host и отзыва ключа или туннеля.

Стоп-условие этого этапа — отсутствие воспроизводимого способа подключить второго инженера без ручной настройки на самом Mac. В таком случае не переходите к долгим задачам: сначала исправьте идентификацию и документацию входа.

Запустите первую сессию в изолированном worktree

Сначала создайте отдельное рабочее дерево Git для одной небольшой задачи. Не отдавайте Agent сразу основную ветку и не начинайте с миграции, массового переименования или изменения схемы подписи. Хороший первый тест должен быть обратимым: небольшое изменение, локальная проверка, просмотр diff, коммит или полное удаление worktree.

Для Git worktree задайте явные правила:

• одно дерево — одна сессия и один контекст задачи;
• основной checkout не используется для фонового эксперимента;
• имя дерева содержит идентификатор задачи;
• зависимости и производные файлы не должны незаметно записываться в соседнее дерево;
• перед удалением сохраняется diff или создаётся проверенный коммит.

Изоляция не ограничивается каталогом. Проверьте, куда Agent пишет логи, временные файлы, кэш пакетов и результаты сборки. Некоторые инструменты используют домашний каталог пользователя, поэтому отдельная рабочая директория сама по себе не гарантирует разделение секретов и состояния.

При выборе harness не предполагайте одинаковое поведение:

• для GitHub Copilot проверьте, каким аккаунтом выполняется вход, какой режим Agent включён и какие подтверждения требуются;
• для Claude проверьте доступность выбранного способа авторизации и экспериментальных возможностей;
• для Codex отдельно зафиксируйте модельный вход, локальные разрешения и обработку команд.

Справочник настроек AI в VS Code следует использовать для сверки имён и состояния параметров. Если конкретная функция доступна только в Insiders или отмечена как экспериментальная, запишите это в протоколе как ограничение, а не как стабильную возможность.

Практическая последовательность первой задачи:

1. Подключите клиент к удалённому Agent Host.
2. Откройте именно созданный worktree и проверьте текущую ветку.
3. Попросите Agent сначала описать план и перечень файлов, не разрешая запись.
4. Разрешите минимальное изменение и выполните локальный тест.
5. Просмотрите diff вне контекста объяснения модели.
6. Проверьте коммит, отмену изменений и повторное открытие worktree.
7. Удалите тестовую сессию только после сохранения журнала и результата.

Как Agent Host изолирует параллельные изменения в репозитории? Он не делает это автоматически только потому, что является Host. Изоляцию задаёте вы: отдельным worktree, ограниченным пользователем, явной веткой, контролем секретов и запретом на запись в основной checkout. Если два Agent работают в одном каталоге, конфликт файлов и состояние индекса становятся вашей проблемой независимо от того, насколько хорошо модель объясняет свои действия.

Критерий остановки — Agent изменяет файлы за пределами разрешённого worktree, не удаётся определить владельца коммитов или отмена оставляет побочные артефакты. До исправления этих условий подключать параллельные сессии нельзя.

Проверьте продолжение после отключения клиента

Теперь запустите задачу, которая выполняется достаточно долго, чтобы вы успели закрыть клиент и подключиться заново. Не используйте для этого только короткую генерацию файла: такой тест проверяет редактор, но не устойчивость удалённого процесса.

Порядок проверки:

1. Запустите задачу в удалённой сессии и запишите её идентификатор.
2. Убедитесь, что в Host видны состояние, вывод терминала и ожидающие подтверждения.
3. Закройте одно окно VS Code или разорвите сетевое соединение.
4. Подождите завершения заранее выбранного этапа задачи.
5. Подключитесь из другого окна VS Code или поддерживаемого браузерного входа.
6. Сверьте состояние сессии, вывод, список изменений и запросы на подтверждение.
7. Откройте worktree и повторно проверьте diff, тесты и журналы.

Продолжит ли Agent Host работать после выключения локального компьютера? Да, если выключился только локальный клиент, а удалённый Host и облачный Mac продолжают работать. Это не означает, что задача переживёт перезапуск Mac, завершение процесса Host, потерю учётных данных или остановку зависимого инструмента. Каждый такой сценарий тестируйте отдельно.

Могут ли несколько окон VS Code одновременно принять одну Agent-сессию? Архитектура VS Code предусматривает подключение нескольких клиентов к одной сессии, но это не делает параллельное редактирование безопасным. Второе окно должно использоваться для наблюдения, продолжения и подтверждения состояния; одновременные команды из двух окон нужно исключить внутренним правилом команды.

Разделите результаты на четыре отдельных теста:

• закрытие или отключение локального клиента;
• кратковременный сетевой обрыв;
• перезапуск удалённого Mac;
• остановка и повторный запуск Agent Host.

Документируйте не только «сессия открылась», но и то, что произошло с незавершённой командой, запросом подтверждения, временным файлом и изменениями в Git. Документация VS Code по удалённым Agent-сессиям и руководство по управлению сессиями задают базовую модель, однако ваш итоговый допуск должен опираться на собственную процедуру восстановления.

Напоминание: закрытый редактор и остановленный удалённый процесс — разные аварии. Если в отчёте нет отдельной строки для каждой из них, восстановление ещё не проверено.

Подключите Xcode, браузер и MCP без ложного допуска

После проверки сессии переходите к реальному macOS-проекту, но сохраняйте низкий риск: отдельная ветка, тестовое задание и ограниченные секреты. Успешная генерация исходного кода не равна готовности проекта к поставке.

Проверка Xcode должна включать:

• установленные командные инструменты и выбранную версию Xcode;
• разрешение зависимостей;
• сборку целевого проекта;
• запуск тестов;
• расположение полученного продукта;
• обработку ошибки подписи или отсутствующего профиля;
• доступность Simulator, если он входит в рабочий процесс.

Названия команд и требования к инструментам сверяйте с официальным справочником Xcode Command Line Tools, а критерии результата — с документацией Apple по запуску и анализу тестов. Не записывайте в runbook неподтверждённые версии или параметры: они меняются при обновлении Xcode и VS Code.

Может ли удалённый Agent Host напрямую вызывать Xcode и MCP-инструменты? Host может запускать доступные удалённому пользователю команды и инструменты, но фактическая возможность зависит от прав macOS, установленного Xcode, клиента, harness и конфигурации MCP. Часть инструментов предоставляется расширением клиента и может исчезнуть после его отключения. MCP-конфигурацию сверяйте с официальным справочником MCP для VS Code.

Для MCP отдельно проверьте:

• где хранится конфигурация и кто может её изменить;
• передаются ли переменные окружения удалённому процессу;
• нужны ли интерактивные подтверждения;
• что произойдёт при недоступности браузерного инструмента;
• какие действия требуют ручного одобрения;
• не получает ли MCP больше прав, чем конкретная задача.

Остановите тест, если сборка проходит только в интерактивном окне, Agent не видит причину сбоя, MCP использует не тот профиль или подтверждение опасной операции невозможно отозвать. Результат должен быть воспроизводимым другим инженером на том же удалённом узле.

Сравните варианты подключения и среду перед расширением

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

Для оценки вместимости не подставляйте случайный объём памяти или число параллельных сессий из чужого примера. Сначала соберите собственные наблюдения: длительность задач, время ожидания модели, число вызовов инструментов, пики сборки, объём кэшей, частоту ручных подтверждений и последствия одновременного запуска Xcode. Метод выбора между общим пулом и выделенными узлами описан в руководстве по подбору Mac для удалённой разработки.

Сформируйте недельный базис эксплуатации

После успешного пилота не расширяйте доступ сразу на все репозитории. В течение первой недели ведите журнал по каждой сессии:

• время запуска и завершения;
• используемый harness и модельный вход;
• вызовы инструментов;
• неудачные попытки и повторы;
• ручные подтверждения;
• изменения в worktree;
• результат сборки и тестов;
• причина остановки;
• состояние Mac после завершения.

На основе журнала решите, подходит ли общий пул. Если конфликты появляются из-за кэшей, Simulator, подписей или интерактивных операций, проблема может быть не в Agent Host, а в чрезмерно плотном размещении задач на одном Mac. Для длительных задач сопоставьте наблюдаемые пики с рекомендациями в материале о ёмкости облачного Mac для AI Coding.

Обязательная процедура завершения должна включать:

• сохранение diff или результата коммита;
• удаление worktree;
• очистку временных артефактов;
• отзыв временных токенов;
• проверку SSH-ключей и MCP-секретов;
• архивирование журнала;
• фиксацию причины аварийной остановки.

Итоговое решение должно быть условным. Оставляйте пилот, если задачи продолжаются, изменения проверяемы, а Mac восстанавливается по документированной процедуре. Ограничьте область задач, если работает только основной сценарий, но не проверены MCP, Xcode или перезапуск Host. Расширяйте deployment лишь после того, как второй инженер повторит процедуру без устных пояснений.

Когда облачный Mac оправдан, а когда лучше другой вариант

Локальный Mac проще для интерактивной отладки, физических устройств и постоянной работы одного разработчика, но он зависит от состояния ноутбука, сна, домашней сети и личных ключей. Общая виртуальная среда может быть дешевле для чисто серверного кода, однако не заменяет macOS, Xcode, Simulator и подпись приложения. Покупка отдельного Mac разумна для стабильной круглосуточной нагрузки, но требует заранее принять капитальные затраты, обслуживание, обновления и простой.

Если вам нужны временные узлы для проверки Agent Host, короткого Xcode-пайплайна или сравнения общего и выделенного режима, аренда MacPull позволяет начать с ограниченного эксперимента, не превращая пилот в постоянную закупку оборудования. Перед выбором сопоставьте длительность Agent-задач, количество параллельных worktree и пики Xcode со своими журналами, а затем изучите варианты аренды Mac для удалённой разработки.

Именно такой порядок снижает риск: сначала подтверждаются продолжение сессии, права, рабочее дерево и откат, затем оценивается ёмкость. Если текущая схема держится на ноутбуке одного инженера, прямом доступе к его ключам и ручном восстановлении после обрыва, отдельный облачный Mac с управляемым Agent Host будет более предсказуемым вариантом для длительных AI Coding-задач — но только после прохождения описанной приёмки.