Codex не дошёл до Slack: чему баг Computer Use учит разработчиков UI-агентов

Slack был целью задачи, но не местом сбоя

Issue #37707 открыт в официальном GitHub-репозитории openai/codex и помечен тегами bug, computer-use и windows-os. Автор указал Windows 11, пакет OpenAI.Codex_26.803.5235.0, Node.js v24.14.0 и корпоративное платное подключение. В карточке issue, доступной на момент описания, нет публично подтверждённого исправления, назначенного исполнителя или связанного pull request.

Ошибка возникла в node_repl до автоматизации десктопного Slack: Node не смог найти модуль по пути к временному kernel.js вида Temp.tmp<random>\kernel.js. При этом, по словам автора, действия Slack connector, включая просмотр и суммаризацию, продолжали работать. Проблемным оказался другой маршрут: локальное управление графическим интерфейсом Slack, в том числе сценарии со Slack Lists или Workflow Builder.

Для архитектуры это существенное различие. Коннектор обращается к определённой интеграционной поверхности и набору разрешённых операций. Computer Use должен подготовить локальный runtime, запустить вспомогательный процесс, получить доступ к экрану и только затем работать с курсором и вводом. В описанном случае отказала подготовка локального слоя, а не доступ к Slack как сервису и не интерпретация пользовательской задачи моделью.

Поэтому некорректно говорить, что Codex «сломал Slack» или выполнил ошибочное действие в мессенджере. Согласно баг-репорту, Slack не был открыт. Точнее сказать так: в одной описанной конфигурации Windows runtime Computer Use не прошёл bootstrap до первого UI-действия. Случай не позволяет оценить частоту проблемы, но полезен как пример раннего инфраструктурного отказа.

• Подтверждён один публично описанный сбой в конкретной конфигурации.
• Не подтверждены массовость дефекта, единая причина и наличие исправления.
• Не произошло открытие Slack, поиск UI-элементов, клик, ввод или изменение данных.

Цитата в переводе

«Действия через Slack connector работают, например просмотр и суммаризация Slack.»

У UI-агента длинная цепочка до первого действия

Путь от текстовой команды к операции в интерфейсе состоит из нескольких независимых этапов. Оркестратор выбирает инструмент, подготавливает и передаёт временные артефакты, запускает helper и sandbox, проверяет жизнеспособность процесса. Затем агент может открыть приложение, определить состояние экрана, найти нужный объект, выполнить операцию и проверить результат. Модель участвует в планировании, но готовность runtime обеспечивается детерминированными программными проверками.

В Issue #37707 сбой произошёл между подготовкой временного скрипта и попыткой Node-процесса его использовать. Это ранняя граница отказа: модель ещё не могла перепутать канал с личным сообщением, неверно прочитать модальное окно или нажать не ту кнопку. Однако система уже пыталась запустить компонент, которому позднее могли быть предоставлены возможности взаимодействия с пользовательским приложением.

Для диагностики это принципиально. Общий статус «агент не выполнил задачу» направляет команду к промпту, модели или описанию интерфейса, хотя причина может лежать в упаковке runtime либо запуске локального процесса. Состояние runtime_not_ready позволяет отделить инфраструктурную проблему от ошибки рассуждения или навигации по UI и выбрать другой путь восстановления.

Computer Use рассматривается как инструмент работы с приложениями на компьютере. В материале Ars Technica background computer use описывался как работа агента через отдельный курсор. Сообщения о поддержке функции в Windows не означают, что запуск будет успешен во всех сочетаниях ОС, версий и локальных политик.

• Выбор инструмента и планирование задачи.
• Bootstrap: staging файлов, запуск helper, sandbox и health-check.
• Read-only проверка приложения, учётной записи и объекта.
• Ограниченное действие, независимая проверка результата и аудит.

Цитата в переводе

«Runtime управления десктопным Slack завершился с ошибкой до того, как Slack удалось открыть.»

Гипотеза о race condition остаётся гипотезой

Автор issue заметил, что после неудачного запуска временный kernel.js и другие staged-файлы всё же появлялись в ожидаемой папке. На этом основании он предположил, что Codex запускает Node до полного завершения подготовки временного скрипта. Это похоже на знакомый класс ошибок, при котором один процесс начинает использовать ресурс до того, как другой сделал его доступным.

Однако превращать это наблюдение в подтверждённый разбор первопричины нельзя. Симптом MODULE_NOT_FOUND может быть связан не только с очередностью запуска, но и с очисткой временного каталога, построением пути, видимостью файлов между процессами, защитным ПО либо иной ошибкой упаковки. Автор сообщал о перезагрузке Windows, пересборке Computer Use runtime, проверке прав Temp-каталога и отсутствии релевантных событий Microsoft Defender. Эти шаги не исключают всех альтернатив.

Точная редакционная оговорка такова: гипотеза автора согласуется с наблюдаемой последовательностью, но OpenAI публично её не подтвердила. Для команды-потребителя конкретная причина важна при исправлении поставщиком; защитная архитектура при этом остаётся одинаковой. Инструмент нельзя считать готовым, пока он не прошёл проверяемый запуск.

Системные материалы OpenAI подчёркивают роль изоляции и ограничений для агентных систем, использующих инструменты. Sandbox может снизить риск нежелательных действий, но добавляет ещё один слой в цепочку запуска. Ответом не должно быть отключение защит или выдача максимальных привилегий: нужны наблюдаемость и явный отказ, если какой-либо слой не готов.

• Факт: Node не нашёл временный kernel.js в описанной конфигурации.
• Гипотеза автора: Node мог стартовать до окончания staging.
• Неустановленный вывод: race condition является подтверждённой причиной дефекта.
• Архитектурное следствие: readiness проверяется независимо от предполагаемой причины.

Цитата в переводе

«Это указывает на то, что Codex запускает Node до полного завершения подготовки временного скрипта.»

Preflight: сначала подтвердить готовность, затем разрешать доступ

Распространённая ошибка в UI-автоматизации состоит в том, чтобы считать инструмент доступным сразу после вызова launcher. Сам запуск процесса ничего не доказывает: helper может немедленно завершиться, временный файл может не читаться, sandbox может ожидать недоступного повышения привилегий, а целевое приложение может быть закрыто или открыто не в том рабочем контексте. Эти состояния нужно обработать до того, как планировщик включит GUI-инструмент в цепочку действий.

Для этого нужен preflight, или bootstrap health gate: отдельный детерминированный этап перед работой с интерфейсом. На нём следует проверить, что staging завершён, ожидаемый артефакт существует и читается, минимальный вызов node_repl возвращает штатный статус, а дочерний процесс остаётся живым в контрольном окне. В зависимости от реализации также проверяются совместимость версий, состояние sandbox и корректная обработка запроса на дополнительные права.

Успешный preflight не означает, что агенту сразу нужен широкий доступ к рабочему столу. Безопаснее выдавать короткоживущее разрешение на конкретный инструмент и задачу. Его можно связать с пользователем, целевым workspace, допустимым типом операции и сроком действия. Если gate не пройден, агент должен получить структурированный результат computer_use_unavailable: runtime_not_ready, а не неопределённое указание повторить действие.

После bootstrap нужен dry run без изменений: открыть приложение, определить активный workspace, считать имя канала или найти объект. Лишь затем допустимо менять состояние. Read-only шаг не должен быть формальностью: его результат необходимо связать с последующей операцией, иначе между просмотром и кликом может измениться контекст или сам объект.

• Проверять итог staging, а не только создание временной папки.
• Проверять чтение ожидаемого артефакта и минимальный health-check runtime.
• Логировать версии Codex, Node.js и ОС, PID, exit code и статус запуска.
• Выдавать ограниченное разрешение на UI-операцию только после успешного preflight.

Ретраи запуска полезны, ретраи мутаций опасны

Ретрай не является универсальным способом повысить надёжность. Повторить staging, запуск helper, health-check процесса или безопасный поиск элемента на обновлённом экране обычно допустимо: такие операции не меняют бизнес-состояние либо могут быть изолированы. Для них нужны ограниченное число попыток, задержки между ними и понятные причины в журнале.

Иной класс составляют действия с последствиями. Нельзя вслепую повторять отправку сообщения, публикацию workflow, изменение прав, создание списка или приглашение пользователя, пока не установлен результат первой попытки. При частичном успехе повтор может создать дубликат, дважды разослать сообщение или изменить объект, который человек уже успел исправить вручную. Ранний сбой bootstrap в #37707 ничего не изменил в Slack, но ошибочный recovery-путь способен создать риск позднее.

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

Полезно разделять bootstrap timeout, timeout наблюдения за UI, timeout действия и timeout проверки результата. Когда все причины объединены в сообщение «агент не справился», невозможно понять, что именно требуется: перезапустить runtime, обновить экран, запросить подтверждение или закрыть задачу без изменений.

• Автоматически повторять запуск runtime, health-check и безопасное чтение UI.
• Не повторять вслепую отправку, публикацию, изменение прав и создание сущностей.
• Перед повтором мутации проверять результат предыдущей попытки.
• При неоднозначном исходе выбирать fail closed: остановку без нового действия.

Для Slack и других рабочих систем GUI должен быть последним маршрутом

Сам Issue #37707 показывает полезную модель деградации: действия через Slack connector работали, когда desktop-control runtime не запускался. Поэтому «работа со Slack» не должна быть одним неделимым инструментом. Архитектура может различать чтение и суммаризацию через коннектор, подготовку черновика, поддерживаемую интеграционную операцию и отдельный capability для функций, доступных только через графический интерфейс.

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

Fallback не означает, что то же действие нужно выполнить любой ценой. Если health gate не пройден, безопасным итогом может быть задача в очереди, готовый, но не отправленный текст или пошаговый runbook для оператора. Для необратимых и плохо проверяемых операций нужен human-in-the-loop: человек подтверждает объект и финальное действие, а система сохраняет факт решения.

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

• Чтение и суммаризация: коннектор без запуска GUI.
• Подготовка текста: черновик и подтверждение перед отправкой.
• Поддерживаемая операция: API или коннектор с проверкой объекта.
• GUI-only задача: Computer Use после preflight, с журналом и контрольной точкой.
• Необратимая или неоднозначная операция: человек либо явный отказ.

Наблюдаемость должна отвечать на вопрос: действие вообще началось?

В кейсе #37707 ключевое значение имеют логи, позволяющие отделить отказ запуска от ошибки в интерфейсе. Для расследования нужны сведения о версии приложения и runtime, ОС, идентификаторе запуска, staging-пути, времени готовности артефакта, PID дочернего процесса, exit code и состоянии sandbox. Иначе инженер не отличит проблему упаковки от несовместимости среды, прав доступа или ошибки оркестратора.

Отдельно следует вести журнал решений: какой инструмент был выбран, прошёл ли preflight, какая read-only проверка выполнена, какой fallback сработал и была ли разрешена мутация. Тогда можно ответить не только на вопрос «почему задача не завершилась», но и на более важный: «изменилось ли что-то в реальном workspace». В описанном баг-репорте ответ отрицательный: Slack не был открыт.

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

• Разделять технические события bootstrap и бизнес-события мутаций.
• Связывать действие с задачей, пользователем, объектом, разрешением и результатом проверки.
• Фиксировать, был ли открыт целевой интерфейс и начиналась ли мутация.
• Минимизировать чувствительные данные, сохраняя диагностируемость.

Один issue не приговор платформе, а тест зрелости архитектуры

Из одного GitHub-репорта нельзя судить о качестве всей платформы Codex, частоте дефектов на Windows или надёжности Computer Use в целом: для этого нет выборки, телеметрии и независимой статистики. Но кейс позволяет сделать более узкий вывод: локальная UI-автоматизация зависит от длинной цепочки компонентов, и отказ каждого из них должен быть штатно предусмотрен системой.

Демонстрация агента, который видит экран и нажимает кнопки, показывает возможность работы в подготовленной среде. Производственная зрелость определяется другим: как система распознаёт неготовый runtime, какой fallback выбирает, может ли повтор продублировать операцию и кто разрешает необратимое действие. Issue #37707 ценен именно потому, что поднимает эти вопросы ещё до визуальной ошибки в интерфейсе.

OpenAI объявляла общую доступность Codex и развивала рабочие сценарии продукта. По мере расширения инструментов всё важнее становятся проверяемые предусловия, ограниченные разрешения, идемпотентность и независимая валидация результата. Это условия безопасного применения агентных систем в среде с реальными данными и последствиями.

• Демо подтверждает возможность, production требует контролируемого отказа.
• Runtime health является задачей инфраструктуры, а не промпта.
• Чем шире доступ агента, тем уже и прозрачнее должны быть разрешения.
• Открытый issue является поводом проектировать защиты, но не статистикой массового сбоя.

Что это означает на практике

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

• Запускайте Computer Use только после отдельного preflight: staging-артефакт, чтение файла, health-check helper, sandbox и совместимость версий должны быть проверены до доступа к UI.
• Разделяйте статусы runtime_not_ready, ui_not_found, action_failed и postcondition_failed: у них разные причины, тайм-ауты и пути восстановления.
• Ретрайте запуск и read-only операции; мутации повторяйте только после проверки фактического результата и с идемпотентным способом выполнения.
• Стройте матрицу инструментов: коннекторы и API для структурированных задач, GUI для исключений, человек для необратимых и неоднозначных действий.
• Выдавайте короткоживущие разрешения, привязанные к задаче и типу операции, вместо постоянного широкого доступа к рабочему столу.
• Сохраняйте технический trace запуска и журнал решений, минимизируя чувствительные данные в логах и скриншотах.

Вывод

Issue #37707 не доказывает массовую ненадёжность Codex Computer Use. Он показывает меньшее, но существенное: UI-агент может не дойти даже до старта, а отказ произойдёт в инфраструктурном слое задолго до первого клика.

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

Источники

• OpenAI Codex Issue #37707
• Ars Technica: New Codex features include the ability to use your computer in the background
• OpenAI Help Center: ChatGPT Business release notes
• OpenAI: GPT-5.3-Codex System Card
• OpenAI: Codex Maxxing white paper
• OpenAI: Codex is now generally available

Частые вопросы

Доказывает ли Issue #37707, что Codex Computer Use ненадёжен?

Нет. Это один публично описанный случай в конкретной конфигурации Windows, Codex и Node.js. По нему нельзя оценить частоту дефекта, его единую причину или надёжность платформы в целом.

Что произошло в кейсе со Slack?

Локальный runtime Computer Use завершился в node_repl с ошибкой загрузки временного kernel.js до открытия Slack. По описанию issue, поиск элементов интерфейса, клик, ввод и изменение данных не начались.

Почему нельзя бездумно повторять действия UI-агента?

Повтор запуска runtime или безопасной read-only проверки обычно можно изолировать. Повтор отправки сообщения, изменения прав или создания объекта без проверки первой попытки способен создать дубликаты и другие нежелательные последствия.

Что должно входить в preflight для Computer Use?

Минимальный gate проверяет завершение staging, существование и чтение ожидаемого артефакта, штатный health-check runtime и жизнеспособность дочернего процесса. В зависимости от реализации также нужны проверка sandbox, версий и прав.

Практический чек-лист

Чек-лист: запуск UI-агента в рабочем интерфейсе

Памятка для команды, которая готовит Computer Use или другой UI-агент к работе с реальными данными. PDF-версия предназначена для сохранения и использования при внедрении.

До доступа к интерфейсу

• Проверить завершение staging и наличие ожидаемого артефакта.
• Проверить чтение временного файла и штатный health-check runtime.
• Проверить жизнеспособность helper-процесса в контрольном окне.
• Зафиксировать версии приложения, runtime, Node.js и операционной системы.
• Проверить sandbox, требуемые права и совместимость среды.

Перед изменяющей операцией

• Провести read-only проверку приложения, workspace и целевого объекта.
• Связать результат проверки с последующим действием.
• Выдать короткоживущее разрешение только на задачу и допустимый тип операции.
• Определить idempotency-ключ или другой способ исключить дублирование.
• Задать независимую проверку postcondition.

При сбое

• Разделить runtime_not_ready, ui_not_found, action_failed и postcondition_failed.
• Повторять только запуск, health-check и безопасные read-only шаги.
• Не повторять мутацию, пока не проверен результат предыдущей попытки.
• Выбрать fallback: коннектор, API, черновик, очередь или человек.
• Зафиксировать, был ли открыт интерфейс и начиналось ли реальное действие.