Codex с телефона: зачем следить за агентом, а не сидеть рядом с ним
Как мобильный Codex превращает телефон в control plane для long-running tasks, approvals и содержательных checkpoints.

Codex вышел с рабочего стола, но работа осталась на Mac

14 мая 2026 года OpenAI открыла в preview мобильный доступ к Codex через приложение ChatGPT. Телефон подключался к Mac с запущенным Codex App: можно было продолжить существующий thread, ответить агенту, изменить направление и подтвердить действие. Сам repository при этом не переезжал на iPhone.

Официальный changelog формулирует архитектуру довольно точно: Codex выполняется на связанном host и использует оттуда проекты, файлы, credentials, plugins, skills и configuration. Мобильное приложение показывает состояние работы и передаёт решения человека обратно.

Phone
  ↓  supervision
Codex thread
  ↓  execution
Mac host → repository → terminal → tools → tests

Поэтому релиз интересен не как «IDE на маленьком экране». Телефон здесь — remote control для инженерной работы, которая идёт в другом месте.

Мобильный интерфейс имеет смысл только для длинной задачи

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

У coding agent другой горизонт. Например:

После обновления Symfony часть пользователей теряет permissions. Найди root cause, исправь его без изменения API и добавь regression test.

На такую задачу уходит не один ответ. Агент ищет точки обновления ролей, читает voter и cache layer, воспроизводит сбой, меняет код, запускает suite, разбирает failure и повторяет проверку. Наблюдать за каждым поисковым запросом — пустая трата внимания.

Developer задаёт цель
        ↓
Agent: research → reproduce → fix → test
        ↓
важная неоднозначность
        ↓
Developer принимает решение
        ↓
Agent продолжает

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

Самый неприятный простой начинается в состоянии «нужен человек»

Представим, что Codex двадцать минут исследовал webhook bug и обнаружил два delivery mechanism. Новый обслуживает почти всех клиентов, legacy остаётся у нескольких старых интеграций. Исправление обоих расширит diff и риск.

Агент правильно не угадывает business decision и задаёт вопрос:

Исправлять оба механизма
или оставить legacy без изменений?

Если разработчик вернётся к Mac через час, worker проведёт этот час в ожидании. Ответ «только новый, legacy не меняй» с телефона занимает меньше минуты и немедленно возвращает задачу в работу.

Здесь мобильный доступ сокращает не runtime модели, а decision latency — расстояние между появлением осмысленного вопроса и человеческим решением. Для long-running agents это отдельная performance metric.

Request–response сменяется машиной состояний

Чат строится вокруг пары request → response. Долгоживущей задаче нужны состояния, к которым человек может подключиться асинхронно:

RUNNING
  ├── NEEDS INPUT    → ответить
  ├── NEEDS APPROVAL → разрешить или отклонить
  ├── FAILED         → посмотреть причину
  └── DONE           → провести review

Документация Remote connections перечисляет именно такие операции: steering активной работы, approvals, просмотр diff, test results, terminal output и screenshots, а также уведомления, когда задача закончена или требует внимания.

Хороший интерфейс supervision не заставляет читать весь transcript. Он сообщает, почему агент остановился, какое решение требуется и что произойдёт после каждого варианта.

Approval — граница полномочий, а не помеха автономности

Возможность подтвердить команду с телефона полезна только вместе с понятной policy. Я бы разделял действия как минимум на три класса:

ALLOW  читать файлы, искать код, запускать unit tests
ASK    менять dependency, выполнять migration, писать во внешний сервис
DENY   production deploy, destructive data operations

Телефон делает ASK практичным: контроль сохраняется, но разработчику не нужно сидеть у workstation. Он не превращает опасное действие в безопасное. Одобрять composer update по одной строке notification без понимания причины столь же рискованно, как нажимать Enter на незнакомой команде в terminal.

Это уже не pair programming

Pair programming предполагает постоянное совместное внимание. Один участник пишет, второй наблюдает, обсуждение идёт почти непрерывно. Мобильный Codex опирается на другую модель:

delegation
    ↓
autonomous work
    ↓
checkpoint
    ↓
human decision
    ↓
autonomous work

Это ближе к работе tech lead с самостоятельным инженером. Lead задаёт границы, не смотрит на каждый grep, подключается к архитектурной неоднозначности и позже проверяет результат.

Я уже разбирал этот переход в статье про Codex App как workspace для agent threads. Mobile добавляет следующий слой: теперь command center не привязан к тому же экрану, где выполняется workload.

Ограничивающим ресурсом становится человеческое внимание

Один разработчик может запустить несколько независимых задач: feature, bug investigation и review. Compute масштабируется проще, чем способность человека одновременно понимать три больших diff.

Agent A  RUNNING
Agent B  NEEDS INPUT
Agent C  DONE

Human attention → Agent B сейчас, Agent C позже

Поэтому agent dashboard должен сортировать работу не по количеству сообщений, а по необходимости вмешательства и риску. Question о public API важнее уведомления об успешном lint. Production approval важнее промежуточного summary.

Телефон особенно ясно показывает эту границу. На нём неудобно микроменеджерить навигацию по repository, зато удобно принять одно хорошо сформулированное решение. Сильный agent workflow экономит active attention, а не просто wall-clock time.

Для supervision нужен отчёт, а не поток tool calls

После 200 действий raw log почти бесполезен. Разработчику нужна сжатая модель состояния:

FOUND     где и почему возник bug
CHANGED   какие файлы и инварианты затронуты
TESTED    команды, результаты, непройденные проверки
DECIDED   какие assumptions сделал агент
NEEDS     что требуется от человека

Такой summary важен и на desktop, но на мобильном его качество становится очевидным. Если вопрос нельзя понять без чтения сотни terminal lines, агент плохо подготовил checkpoint.

Содержательный checkpoint уменьшает ещё один риск: разработчик отвечает на локальный вопрос, забывая общую цель. Хороший интерфейс рядом с вопросом напоминает исходные constraints и уже проверенные факты.

Меньше присутствия не означает меньше ответственности

Телефон подходит для короткого steering и approvals. Он плохо подходит для принятия изменения в 27 файлах. Финальный diff всё равно нужно изучить на нормальном экране: проверить архитектуру, assumptions, test coverage и побочные изменения.

Особенно опасна симметрия «агент написал — агент проверил». Self-verification ловит execution errors, но не гарантирует правильность исходной бизнес-предпосылки. Для большой задачи нужен независимый review — человеческий или отдельный reviewer с последующим человеческим решением. Об этом подробнее писал в разборе длинных инженерных задач и стоимости supervision.

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

Телефон превращается в control plane

В инфраструктуре control plane хранит желаемое состояние и принимает решения, а execution plane выполняет workload. Мобильный Codex воспроизводит ту же схему в разработке:

CONTROL PLANE
goal · policy · checkpoint · approval · review
                     ↓
EXECUTION PLANE
repository · terminal · tools · tests · environment

Это не отменяет IDE. Редактор остаётся лучшим местом для ручной отладки, чтения сложного diff и точечной работы. Но он перестаёт быть единственным интерфейсом AI-разработки. Для постановки цели, наблюдения за состоянием и ответа на blocker достаточно намного более компактного клиента.

Главный сигнал релиза 14 мая именно в этом. Чем дольше Codex способен работать самостоятельно, тем меньше ценности в постоянном присутствии разработчика рядом с ним. Нужен другой контракт: агент действует внутри заранее заданных границ, останавливается на действительно важных решениях и возвращает проверяемый результат.

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