Если OpenCode 2.0 не запускает Xcode на удалённом Mac, сначала выясните, где выполняются команды и какой каталог проекта открыт: SSH-доступ не переносит рабочую среду агента на удалённую машину. На этой неделе проверьте фактический узел, копию репозитория и доступность xcodebuild под тем же пользователем, который запускает сборку. Тесты принимайте только по сохранённому результату, а не по сообщению агента.

Статья пригодится разработчикам, у которых основная машина работает под Windows или Linux, а собирать нужно iOS- или macOS-проект.
Инженеры, отвечающие за удалённый Mac CI, смогут разделить ответственность агента и узла сборки.
Технические руководители найдут способ проверить права доступа и доказательства успешного тестирования.

Последнее обновление: 24 октября 2026 года. Сведения сверены с документацией OpenCode и журналом изменений, а также с текущими материалами Apple по инструментам командной строки и тестированию.

01

Сначала установите, на каком компьютере работает агент

OpenCode запускает инструмент bash в среде исполнения проекта. Поэтому команда может успешно отработать на вашей основной машине, хотя вы ожидали запуск на Mac. SSH-соединение подтверждает, что вы можете открыть удалённую оболочку; оно само по себе не перенаправляет в неё инструменты агента. Это различие описано в документации OpenCode о работе инструментов.

В реальном сценарии разработчик подключается по SSH к Mac, видит приглашение командной строки и просит агента запустить xcodebuild. Агент отвечает, что команда не найдена. Это ещё не указывает на неисправный Xcode: сначала нужно выяснить, запускался ли xcodebuild на Mac вообще. Если в терминале агента вывод pwd показывает рабочий каталог Windows или Linux, ошибка закономерна — агент выполняет команду не там, где установлены инструменты Apple.

Соберите начальные сведения в обеих средах. В терминале OpenCode выполните:

pwd
git rev-parse --show-toplevel
git rev-parse HEAD
git status --short

Затем подключитесь к Mac тем способом, которым предполагается запуск сборки, и выполните те же проверки. Сравните корневые каталоги, идентификаторы коммитов и состояние файлов. Не ориентируйтесь только на имя каталога: одинаковое имя проекта не доказывает, что это один и тот же репозиторий или одна и та же версия.

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

Для OpenCode проверьте также, не ограничивают ли инструменты доступа к оболочке и файловой системе. В документации есть отдельные настройки разрешений инструментов. Разрешайте только те операции, которые нужны проекту; включать неограниченный доступ ко всем командам ради проверки не требуется.

02

Проблема с копией проекта: агент меняет не тот репозиторий

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

Проверяйте совпадение по трём признакам:

  • Корень репозитория. Сверьте результат git rev-parse --show-toplevel на обеих сторонах. Путь может быть разным, но он должен указывать на ожидаемую копию.
  • Коммит и ветка. Сравните git rev-parse HEAD и git branch --show-current. Если идентификаторы коммита не совпадают, это разные исходные состояния.
  • След изменения. До работы агента сохраните вывод git status --short, затем повторите проверку после правки. На Mac проверьте, появился ли тот же файл и изменение в нём.

Пользуйтесь одним понятным способом передачи состояния. Если OpenCode работает непосредственно в проекте на Mac, сборка должна читать эту же рабочую директорию. Если агент остаётся на Windows или Linux, отправляйте на Mac точно определённую ревизию или синхронизированное дерево и фиксируйте, какой именно коммит собран. Не полагайтесь на ручное копирование отдельных файлов: оно может пропустить изменённые ресурсы, настройки проекта или файлы зависимостей.

В журнале задания полезно сохранить корень репозитория, ветку, идентификатор коммита, команду сборки и код её завершения. Это позволяет отделить дефект OpenCode от ошибки синхронизации. Если результат расходится с ожидаемым, сначала повторите сборку на точно зафиксированной ревизии, а не меняйте сразу настройки Xcode.

03

Сравните схемы исполнения до исправления ошибки

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

Схема Где выполняются команды и хранятся файлы Что проверить Подходит, когда
OpenCode и проект на основной машине На Windows или Linux Там ли находится нужная копия и есть ли в этой среде требуемый инструмент Нужно редактировать или проверять задачи, не требующие Xcode
OpenCode и проект на удалённом Mac В рабочей среде Mac Учётную запись, каталог проекта, доступ к инструментам и права агента Агент должен читать те же файлы, которые собирает Xcode
OpenCode локально, команды отправляются через SSH Проект может оставаться локальным; сборочные команды выполняются на Mac Передачу нужной ревизии, удалённую рабочую директорию, статус завершения и возврат результатов Нужно сохранить локальную работу агента, но выполнять часть операций на Mac

В третьей схеме особенно легко получить «успешную команду» без проверяемой сборки: оболочка отработала, но на Mac оказался не тот проект или результаты остались на удалённом диске. Явно фиксируйте каталог, пользователя, команду, код завершения и путь к артефактам. Если ваш способ удалённого запуска не передаёт эти сведения обратно, добавьте их в обвязку задания или пересмотрите схему.

04

FAQ: выполнение bash, рабочая папка и результаты

Где выполняются команды bash из OpenCode?

Ориентируйтесь на среду исполнения проекта, а не на факт открытого SSH-соединения. Сравните вывод pwd и расположение Git-корня в терминале агента и на Mac. Если они разные, команда агента не выполняется автоматически на удалённом узле. Для работы с Xcode переместите рабочую среду на Mac либо явно организуйте удалённый запуск и передачу исходников.

Как направить OpenCode к каталогу проекта на удалённом Mac?

Проверьте, что каталог, который читает агент, совпадает с каталогом, который использует сборка. Сверьте корень Git, текущую ветку, коммит и изменения файлов. Затем выберите одно: открыть рабочую область в среде Mac или передавать на него определённую версию проекта. Простого совпадения имён папок недостаточно, чтобы подтвердить, что обе стороны работают с одной копией.

Почему SSH видит Mac, но OpenCode не находит xcodebuild?

Сначала запустите диагностику в той же оболочке и от имени той же учётной записи, которыми выполняется задача. Проверьте PATH, затем вызовите xcode-select -p и xcodebuild -version. Если команды доступны в SSH-терминале, но не агенту, вероятны различия пользователя или окружения, либо команда агента исполняется на другой машине.

Как доказать, что тестовый результат сохранён?

Проверьте статус завершения тестовой команды и наличие пакета результатов по указанному пути. Передайте этот пакет в хранилище артефактов и откройте его средствами Xcode: в нём должен быть именно нужный запуск, а не только сообщение о сборке. При повторной проверке используйте тот же коммит и сохраняйте результат в отдельное место, чтобы не смешать попытки.

05

xcodebuild не найден или выбран другой набор инструментов

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

whoami
printf '%s\n' "$PATH"
xcode-select -p
xcodebuild -version

xcode-select -p показывает активный каталог разработчика, а xcodebuild относится к инструментам командной строки Xcode. Установка и доступность компонентов зависят от состояния именно удалённого Mac; установленный на рабочей станции Xcode ничего не доказывает о сборочном узле. Сверяйте это с инструкцией Apple по установке инструментов командной строки и справочником по командам Xcode.

Если каталог разработчика не тот, который ожидает проект, не маскируйте проблему добавлением случайного пути в переменные агента. Сначала выясните, какая установка доступна удалённому пользователю, и выберите требуемую среду по правилам вашего узла. Затем повторите проверку от имени OpenCode. Журнал изменений OpenCode показывает развитие ветки 2.x, поэтому при обновлении сверяйте поведение со сведениями о текущих выпусках, а не переносите выводы о старой версии на новую.

06

Проект читается, но сборке не хватает зависимостей или прав

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

Разбирайте ошибку по её месту в журнале:

  • Ошибка доступа к репозиторию или зависимости. Проверьте, каким пользователем выполняется команда и доступны ли ему нужные учётные данные. Не вставляйте секрет в текст задания или в общедоступный лог.
  • Отказ при изменении файла. Сопоставьте путь и владельца файла с учётной записью агента. Выдайте доступ только к нужной рабочей области, а не ко всему домашнему каталогу или узлу.
  • Проблема подписи. Проверьте, должна ли конкретная задача подписывать приложение и доступна ли ей нужная учётная запись. Не расширяйте права на ключи, если задача выполняет только проверочную сборку без подписи.
  • Ограничение инструмента OpenCode. Посмотрите настройки разрешений для конкретного типа действия и сопоставьте отказ с журналом агента.

Перед изменением прав сохраните точный текст ошибки и команду, которая её вызвала. После выдачи минимально необходимого доступа повторите только этот шаг, а затем проверьте, что доступ не стал шире, чем требует задача. Для маковского CI держите секреты отдельно от исходников и не используйте личную интерактивную сессию разработчика как неявный источник полномочий.

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

07

Сборка прошла, но тестовая цель не запускается

Успешная компиляция не означает, что тесты стартовали. Проверяйте отдельно схему проекта, цель запуска и наличие подходящего симулятора или устройства. Список доступных целей на рабочей машине не является доказательством того, что такой же runtime установлен на удалённом Mac.

Начните с описания проекта:

xcodebuild -list -project <путь-к-проекту>

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

Сопоставьте фактическую доступность симулятора с документацией Apple о запуске приложений на симуляторах и устройствах. Если подходящей цели нет, сначала решите, можно ли установить или выбрать нужный runtime и разрешена ли это политика узла. Только после этого классифицируйте проблему как неисправность агента. Когда тесты должны выполняться на конкретном физическом устройстве, учитывайте, что удалённая машина должна иметь доступ именно к требуемому устройству; сборка без такого доступа не подтверждает тест на нём.

08

Результат тестов нужно сохранить отдельно от сообщения об успехе

Для приёмки macOS CI разделите три состояния: команда запущена, тесты завершились, результат сохранён и доступен для проверки. Агент может сообщить об успешной сборке, хотя тестовая цель не запускалась или пакет результатов остался на удалённом диске. Сохраните код завершения процесса, полный вывод команды и путь к артефакту.

Для тестового задания задайте путь результата через -resultBundlePath, используя уникальный каталог для конкретного запуска. Затем проверьте, что каталог создан, доступен для чтения и передан в хранилище результатов вашей системы. Apple описывает запуск тестов и интерпретацию полученных данных в официальном руководстве по результатам тестирования. Если команда завершилась ошибкой, не объявляйте проверку успешной только на основании существующего файла: убедитесь, что в пакете есть данные нужного тестового запуска.

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

09

Порядок проверки, который сокращает число ложных исправлений

Выполняйте проверки последовательно, не меняя сразу несколько слоёв конфигурации.

  1. Зафиксируйте исходный запрос. Сохраните команду, сообщение OpenCode, полный вывод терминала и момент, на котором задача остановилась.
  2. Определите место исполнения. Запустите pwd и whoami в среде агента, затем проверьте те же значения в сессии Mac. Сравните машину, пользователя и каталог.
  3. Подтвердите копию проекта. Сверьте Git-корень, ветку, коммит и рабочие изменения на источнике и узле сборки.
  4. Проверьте Apple-инструменты на Mac. Выполните xcode-select -p и xcodebuild -version от имени пользователя задания. При различиях с ожидаемой установкой разберитесь с активным каталогом разработчика.
  5. Уточните цель сборки и теста. Проверьте доступные проекту схемы, выбранную цель и наличие подходящего симулятора или устройства.
  6. Проверьте разрешения по журналу. Разделите доступ к исходникам, зависимостям, подписи и файлам агента. Выдайте только недостающие права.
  7. Повторите задачу с доказательствами. Запустите её на зафиксированном коммите, сохраните код завершения, журнал и пакет результатов, затем откройте артефакт для проверки.

Такой порядок важен: если сначала менять PATH, выдавать широкие права и обновлять проект, вы потеряете исходную причину сбоя. После каждого исправления повторяйте только соответствующую проверку. Когда она проходит, переходите к следующему слою.

10

Когда проблема уже не в Xcode, а в архитектуре запуска

Если OpenCode постоянно работает на Windows или Linux, а каждая задача требует Apple-инструментов, ручное SSH-перенаправление создаёт дополнительные точки отказа: файлы могут расходиться, переменные окружения — отличаться, а артефакты — оставаться на узле. В этом случае сравните две рабочие схемы: перенести рабочую среду агента на Mac или оставить агента локально и сделать удалённый запуск явным и проверяемым. Выбор зависит от того, где удобнее хранить исходники и как ваша система возвращает результаты.

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

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

Главный критерий прост: OpenCode должен редактировать именно ту версию проекта, которую получает xcodebuild, а тест считается проверенным только после сохранения и открытия результата. Если текущая Windows- или Linux-схема не предоставляет Apple-инструменты, используйте удалённый Mac как явно определённую среду сборки — с подтверждённым пользователем, каталогом, коммитом и артефактами.