Сначала разделите учётные записи и проверьте границы проекта: общий фоновый сервис OpenCode 2.0 не является механизмом изоляции для нескольких людей. Это решение подходит лабораториям, которые хотят оставить одну физическую машину, но готовы проверить системные аккаунты, рабочие каталоги, ключи и доступ к сервису до работы с настоящими проектами.
Руководителям исследовательских групп — если вы решаете, можно ли дать команде один Mac с OpenCode 2.0.
Администраторам лабораторий — если нужно разграничить пользователей, сервис и каталоги.
Разработчикам исследовательского ПО — если вы переносите индивидуальную рабочую среду в доступную команде конфигурацию.
Сначала определите, что именно означает «общий Mac»
У команды могут быть разные схемы работы, и слово «общий» само по себе ничего не говорит об изоляции:
- Несколько человек по очереди работают под одной учётной записью macOS. У них общий пользовательский контекст. Нельзя считать открытый сеанс, сохранённую конфигурацию или файлы этого аккаунта личными для одного участника.
- У каждого человека отдельная учётная запись macOS. Это создаёт разделение на уровне системных пользователей, но ещё не доказывает, что каталоги, общие папки, секреты и удалённый сервис настроены правильно.
- Несколько клиентов подключаются к одному экземпляру фонового сервиса OpenCode. В этом случае решающее значение имеет то, от имени какого пользователя работает сервис и к каким сеансам, настройкам и инструментам он предоставляет доступ.
Документация OpenCode V2 CLI описывает фоновый сервис как управляющий сеансами, конфигурацией, интеграциями, разрешениями и выполнением инструментов в контексте текущей учётной записи. Из этого следует важное ограничение: несколько открытых клиентских окон не означают, что у каждого человека отдельный системный пользователь или изолированное хранилище данных.
Что именно может быть общим в фоне OpenCode 2.0? Смотрите не только на экран приложения. Сопоставьте системную учётную запись, адрес подключённого сервера, доступный список сеансов и расположение конфигурации. Если несколько людей используют один macOS-аккаунт, нельзя делать вывод о персональной изоляции только по тому, что у каждого свой ноутбук или окно клиента.
В V2 предусмотрены режимы работы с локальным сервисом и подключением к указанному серверу; подробности нужно сверять с официальным описанием CLI и соединения с сервером. Версии и поведение сервиса могут меняться, поэтому перед внедрением проверьте официальный журнал изменений OpenCode. Не переносите выводы о проверенной конфигурации на обновлённую версию без повторной проверки.
Сеансы и настройки требуют проверки владельца
Общий фоновый процесс может обслуживать состояние, относящееся к аккаунту, от имени которого он запущен. Поэтому проверка должна отвечать на конкретный вопрос: какой пользователь владеет процессом и какой именно сервер видит каждый клиент? Название проекта в окне клиента не отвечает на эти вопросы.
Настройки также не следует считать безличными. Документация OpenCode V2 по конфигурации описывает параметры приложения, а документация по разрешениям — управление разрешениями при работе с инструментами. Проверяйте расположение используемых настроек, их владельца и то, к какому процессу они относятся. Не публикуйте файлы конфигурации в общем каталоге, если в них могут находиться токены или иные секреты.
Как установить, видят ли участники одни и те же сеансы? Под каждым предполагаемым пользователем отдельно запустите клиент и проверьте, к какому серверу он подключён, какие сеансы отображаются и какой аккаунт запускает сервис. Используйте отдельные тестовые сеансы без исследовательских данных. Если клиенты подключаются к одному серверу, а владелец процесса и граница доступа не установлены, считать сеансы раздельными нельзя.
Фиксируйте результат не в виде «кажется, списки разные», а по проверяемым признакам: учётная запись, адрес сервера, список сеансов, путь к настройке и результат теста доступа. После обновления OpenCode повторяйте проверку, если изменились описание сервиса, способ подключения или модель разрешений. Журнал изменений пригоден для поиска таких перемен, но сам по себе не подтверждает безопасность конкретной установки.
Пересечение проектов начинается с каталога
Изоляция сеанса OpenCode и изоляция файловой системы — разные вещи. Даже если у двух клиентов разные сеансы, они могут открыть одну рабочую копию. И наоборот: разные каталоги не гарантируют, что клиент подключён к ожидаемому серверу и использует ожидаемый аккаунт.
Для каждого проекта зафиксируйте абсолютный путь к рабочему каталогу, владельца файлов, используемую ветку Git и место, куда сохраняются результаты анализа или сгенерированные файлы. Не полагайтесь только на имя проекта в интерфейсе: похожие названия и повторно использованные рабочие копии легко перепутать.
Для параллельной работы с одним репозиторием можно рассмотреть git worktree. Документация Git объясняет, как создавать дополнительные рабочие деревья, связанные с одним репозиторием. Это помогает развести рабочие каталоги и ветки, но не заменяет системные разрешения: каждый процесс и пользователь всё ещё должны иметь корректно ограниченный доступ к файлам.
Как проверить границы проекта, не рискуя данными исследования? Создайте тестовый репозиторий без чувствительных материалов. Пусть каждый участник подключится своим предполагаемым способом, проверит путь, ветку, возможность чтения и записи, а затем создаст тестовый файл. Убедитесь, что файл появился только в ожидаемом каталоге. Проверьте также, куда попадают результаты команд и вспомогательные файлы. Если тест требует доступа к каталогу другого участника, остановитесь и выясните, какой системный пользователь выполняет команду.
На этом этапе полезно проверить и практические ошибки, не связанные с дефектом OpenCode: повторно выбранный каталог, общий рабочий клон, запуск команды из неверной директории, ветку не того проекта или общий путь вывода. Сообщение о том, что люди увидели чужой файл, ещё не доказывает наличие общей видимости сеансов: причиной может быть разрешение файловой системы или вручную выбранный общий каталог. Отделяйте наблюдение от причины, прежде чем менять конфигурацию.
Учётные данные и команды не становятся личными автоматически
Права, заданные приложению, не равны изоляции операционной системы. Если человек работает под тем же аккаунтом macOS, что и коллега, он может получить доступ к ресурсам, доступным этому аккаунту, включая файлы и секреты. Руководство Apple по учётным записям пользователей на Mac и документация Apple о правах доступа к файлам и папкам описывают системные механизмы, которые нужно проверять отдельно от разрешений OpenCode.
До подключения к реальным проектам установите, где хранятся ключи и токены, кто владеет этими файлами и какие процессы могут их читать. Проверьте переменные окружения процесса, конфигурацию инструментов и способ передачи учётных данных провайдера. Если один общий аккаунт запускает сервис, не предполагайте, что участники получают раздельные секреты только потому, что используют разные клиентские устройства.
Команды требуют такого же внимания. По документации OpenCode о разрешениях определите, что разрешено выполнять в текущей конфигурации. Затем проверьте, от имени какого пользователя запускаются команды и к каким каталогам этот пользователь имеет доступ. Разрешение приложения может ограничить отдельные действия, но оно не должно подменять системное разделение аккаунтов, файлов и секретов.
Достаточно ли настроить разрешения OpenCode для команды? Нет, если цель — разделить доступ разных людей к файлам и секретам. Сопоставьте настройку OpenCode с правами macOS, владельцем процесса, общими папками и доступом к учётным данным. Для передачи файлов между пользователями отдельно проверьте настройку общего доступа к файлам в macOS: общая папка — это намеренно открытая граница, а не доказательство того, что остальные каталоги закрыты.
Удалённый доступ меняет границу проверки
Локальное подключение, доступ внутри локальной сети и подключение извне — разные сценарии. Для каждого нужно выяснить, включён ли удалённый сервис, на каком адресе он принимает подключения, как проверяется клиент и какие источники могут подключиться. Нельзя считать сервис локальным только потому, что он изначально запускался на Mac.
Документация OpenCode по удалённому сервису описывает удалённое подключение как режим, который требуется явно включить. До его включения проверьте актуальные параметры версии, адрес прослушивания и способ аутентификации. Не полагайтесь на старые команды из заметок лаборатории, если версия OpenCode изменилась; сверяйте процедуру с документацией V2 и журналом изменений.
Пароль и шифрование соединения важны, но не заменяют правила доступа исследовательской организации. Они не определяют, кто владеет проектом, может ли пользователь прочитать общие секреты и соответствует ли доступ требованиям к данным. Если лаборатория не может подтвердить допустимый способ удалённого доступа, не выставляйте сервис в сеть ради удобства команды.
Для описания удалённой среды полезно иметь короткую запись: адрес назначения, кто может подключаться, каким способом проходит аутентификация, от чьего имени работают команды и какие каталоги открыты. Не сохраняйте секреты в общей инструкции. Изменение адреса, владельца процесса или способа аутентификации должно запускать повторную проверку.
Решение: общий аккаунт, отдельные пользователи или отдельная среда
Используйте условия выбора, а не предположение, что одна физическая машина автоматически безопасна для группы.
- Если Mac нужен одному человеку, оставьте один аккаунт и проверьте обычный локальный режим, адрес сервера, разрешения и рабочий каталог. Для личного проекта это может быть проще, чем настраивать коллективную схему.
- Если нескольким участникам нужна одна физическая машина, создайте отдельные системные аккаунты и проверьте, что каждый запускает собственный контекст. Затем испытайте каталоги, доступ к секретам и подключения на тестовом проекте.
- Если команде нужен общий репозиторий, но не общие учётные данные, определите общие папки и ветки отдельно, а секреты храните в контексте аккаунтов, которым они действительно необходимы. Совместная работа с кодом не требует автоматически общего пользователя macOS.
- Если клиентам необходимо подключаться к одному серверу, заранее подтвердите, какие пользователи и сеансы доступны каждому подключению. Если доказать отдельные границы невозможно, не используйте общий сервис для разных конфиденциальных проектов.
- Если нельзя подтвердить разделение каталогов, учётных данных или удалённого доступа, откажитесь от общей учётной записи: перейдите на отдельные системные аккаунты или выделите самостоятельную среду для проекта.
Что выбрать для рабочей среды исследовательской группы? Разделяйте аккаунты, если людям нужны разные права, секреты или проекты. Оставляйте общий доступ к конкретному репозиторию только при явном решении о том, кто может читать и изменять файлы. Размещайте проекты в самостоятельных средах, если лаборатория не может доказать границы доступа на общей машине или если требования к данным не допускают такой способ работы.
Пошаговая проверка перед запуском проекта:
- [ ] Зафиксируйте, работает ли каждый участник под отдельным пользователем macOS или используется общий аккаунт.
- [ ] Найдите процесс OpenCode и установите его владельца; сравните это с аккаунтом клиента.
- [ ] Проверьте адрес сервера и список доступных сеансов отдельно для каждого предполагаемого пользователя.
- [ ] Запишите абсолютный путь к тестовому репозиторию, ветку Git и владельца тестовых файлов.
- [ ] Проверьте чтение, запись и запуск команд на тестовых данных, а не на рабочем исследовательском наборе.
- [ ] Установите, где расположены настройки, переменные окружения и учётные данные и какие аккаунты могут их прочитать.
- [ ] Для удалённого режима проверьте адрес прослушивания, аутентификацию и разрешённые источники подключения.
- [ ] После проверки версии OpenCode повторите испытания, если изменились сервис, разрешения или способ удалённого соединения.
Эта последовательность отвечает и на вопрос о выборе аккаунтов: если участникам не нужны одинаковые файлы, полномочия и секреты, разделяйте системные аккаунты. Если проверка показывает общую рабочую копию или общие учётные данные, устраняйте это до переноса настоящих проектов. Когда технические границы невозможно продемонстрировать, изоляцию нельзя считать подтверждённой.
В удалённой среде macOS также требуется заранее выяснить модель аккаунтов, способ доступа и правила работы с данными. Мы не рассматриваем сам факт аренды удалённого Mac как гарантию многопользовательской изоляции или соответствия требованиям лаборатории. Для команд, которым нужна интерактивная macOS-машина, можно изучить справочные материалы metalvnc и варианты аренды, а затем отдельно сверить условия доступа с правилами организации.
Общий лабораторный Mac кажется удобным, но у этой схемы есть реальные издержки: общий аккаунт смешивает пользовательский контекст, общая папка упрощает случайную запись в чужой проект, а единый набор ключей затрудняет контроль доступа. Если постоянное локальное оборудование не требуется, удалённый Mac от metalvnc может быть практичным способом получить доступ к macOS без покупки отдельной машины. Выбирайте его только после проверки нужных аккаунтов, доступа к данным и режима подключения; аренда хоста сама по себе не создаёт изоляцию. Последняя проверка сведений выполнена 3 ноября 2026 года по документации OpenCode V2, описанию удалённого сервиса и официальному журналу изменений.
Разделите рабочие среды для команды на выделенных Mac от metalvnc
Арендуйте отдельный физический Mac для проекта или участника команды: ресурсы машины не используются совместно с другими клиентами.