Моему MacBook Air M4 с 16 ГБ памяти стало тесно в моём рабочем режиме. Постоянно открыты браузеры, Codex, несколько проектов, чаты, Notion, Linear, GitHub. Периодически добавляются Docker, локальные серверы, аудиты и длинные рабочие сессии.

Я решил обновить ноутбук и вынести длительные задачи на отдельную домашнюю машину. Так появилась конфигурация из MacBook Air M5 с 32 ГБ памяти, Mac mini M4 Pro с 48 ГБ и двух iPhone для мобильного управления.

Настраивал всё вместе со Стёпой — моим помощником в Codex. Он помогал разложить переезд на этапы, проверить состояние проектов и разобраться с доступами.

Зачем понадобились два компьютера

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

Новый MacBook с 32 ГБ памяти давал больше возможностей для повседневной нагрузки. Mac mini должен был стать постоянно включённой машиной для проектов, контейнеров и долгих проверок.

Роли распределились так:

  • MacBook — повседневная работа, браузер, созвоны, управление задачами и мобильность.
  • Mac mini — активные проекты, Codex, серверы разработки и длительные процессы.
  • iPhone — быстрый мобильный доступ.
  • NAS — сетевое хранилище.
  • GitHub — репозитории и сохранённая история изменений.
Notion image

Сначала — разобраться со старым окружением

Перед переносом мы проверили проекты в ~/Code. Нужно было понять, какие репозитории чистые, где есть незакоммиченные изменения, где локальные коммиты ещё не отправлены на GitHub, а где удалённого репозитория вообще нет.

От этого зависел способ переноса: что можно восстановить через GitHub, а что нужно отдельно сохранить в виде Git bundle или patch. Заодно разобрали, где лежит конфигурация Codex, какие доступы завязаны на Keychain и что относится к NAS, VPN, SSH и локальным инструментам.

Отдельное внимание — старым папкам. По названию каталога не всегда понятно, актуальный это проект или его давно забытая копия.

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

Переезд на новый MacBook

MacBook был первым в очереди: это моя основная повседневная машина, и её нужно было быстро подготовить к работе.

Переезд прошёл через Migration Assistant. Он перенёс пользователя, приложения и большую часть окружения. После этого начались проверки:

  • работы GitHub CLI и SSH;
  • открытия проектов в ~/Code;
  • запуска Codex;
  • доступа к Linear, Cloudflare и другим рабочим API;
  • сохранности важных локальных файлов;
  • доступности сети и NAS.

Открытый рабочий стол ещё мало что говорит о результате переезда. Мне нужно было открыть проект и продолжить задачу со всеми необходимыми файлами и доступами.

Mac mini: от покупки мышки до работы без монитора

Mac mini приехал отдельно. Первым делом выяснилось, что у меня нет клавиатуры и мышки для начальной настройки.

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

После стартовых настроек Mac mini получил:

  • имя codex-mini;
  • отдельного пользователя для разработки;
  • Remote Login через SSH;
  • Screen Sharing;
  • Tailscale/Headscale;
  • Happ как дополнительное VPN-подключение;
  • Codex Desktop и Codex CLI;
  • авторизацию GitHub;
  • Homebrew, Node, pnpm, uv, cloudflared, jq и rg;
  • Docker/OrbStack;
  • активные рабочие проекты.

SSH позволяет работать с машиной через терминал, Screen Sharing — подключаться к её рабочему столу. Это два способа доступа под разные задачи.

Затем я проверил поведение после перезагрузки: Mac mini должен вернуться в сеть, снова стать доступным по SSH и Screen Sharing, видеть NAS/Copyriot и быть готовым к работе без монитора.

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

Notion image

Как устроили сеть

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

Дома основной путь к Mac mini и NAS — локальная сеть. Tailscale/Headscale связывает устройства через частную сеть, или tailnet. Happ/VLESS используется для внешнего интернета и дополнительных маршрутов там, где это нужно.

На практике приходится учитывать, что VPN могут конфликтовать, а exit node — менять маршрут интернет-трафика. Подключение по LAN и через tailnet тоже нужно проверять отдельно: доступность устройства одним способом ещё не подтверждает работу другого.

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

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

Для чего использовать Codex на Mac mini

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

Например, сервер разработки можно запустить на Mac mini, а результат смотреть с MacBook или iPhone. Или оставить проверку проекта выполняться на домашней машине, пока ноутбук нужен для других дел. Задачи с данными на NAS тоже можно запускать рядом с хранилищем.

Для доступа к Mac mini есть Codex, SSH и Screen Sharing. Выбор зависит от того, нужно ли работать с задачей агента, выполнить команды или открыть рабочий стол.

Notion image

Два iPhone

К системе подключились два телефона: основной iPhone и старенький iPhone SE 2. Оба могут служить дополнительными точками управления.

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

Меня особенно порадовал iPhone SE. Он лежал в ящике, а здесь снова оказался полезен. Для этой роли его вполне хватило.

Что потребовало отдельной работы

При появлении второй машины пришлось точнее определить, где должны находиться проекты, настройки и доступы. Что восстанавливается через GitHub? Что остаётся локально? Какие ключи нужны на Mac mini, а какие должны храниться только на сервере?

Особенно заметной стала тема секретов. Keychain удобен в окружении одного Mac и его приложений. Для работы между MacBook, Mac mini и будущими VPS понадобился отдельный подход.

Следующим проектом я выбрал SOPS + age + mise для переносимых секретов. Его стоит разбирать отдельно: там свои требования к хранению, выдаче и использованию доступов.

Что получилось

Я перенёс повседневную работу на новый MacBook и подготовил Mac mini с активными проектами, Codex и инструментами разработки. Проверял удалённые подключения, доступ к хранилищу и возвращение Mac mini в сеть после перезагрузки. Подключил оба iPhone.

Работа стала меньше зависеть от одного ноутбука. Появилась отдельная домашняя машина, на которой можно оставлять серверы разработки и длительные процессы.

Дальше эту конфигурацию можно развивать под конкретные задачи: настроить регулярные аудиты репозиториев — проверку состояния веток, устаревших зависимостей и незакрытых TODO с подготовкой коротких отчётов, — а также автоматические проверки работоспособности, или smoke-checks.

Ещё один сценарий — передача задач Codex между компьютерами: начать на ноутбуке, продолжить на Mac mini, затем вернуться обратно и управлять этим с iPhone. Это следующие этапы.

А первый уже завершён: рабочее окружение перенесено, Mac mini стоит без монитора, настроен удалённый доступ. Можно заниматься проектами.

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

Связь со мной: t.me/pimenov · Мой канал: t.me/pimenov_ru