Codex обсуждает non-blocking tool output: зачем это агентным workflows OpenAI

Новостной повод

23 июля 2026 года в публичном репозитории OpenAI Codex появился issue #34895 с узким, но значимым предложением: добавить для события PostToolUse способ заменить результат инструмента, который увидит модель, не блокируя успешное выполнение tool call. Заголовок issue выглядит как внутренняя инженерная деталь. На деле за ним стоит один из ключевых вопросов агентных систем: как дать модели полезный промежуточный сигнал, не останавливая цепочку действий и не перегружая контекст сырым выводом.

Это не анонс OpenAI и не подтвержденная функция Codex. В доступном досье issue остается публичным предложением: assignee, milestone, проект или связанный pull request не зафиксированы. Корректная рамка такая: в Codex обсуждают изменение контракта tool-use, которое потенциально позволит точнее управлять тем, что модель видит после выполнения инструмента.

В этом сюжете Codex важен не как редактор кода с ИИ, а как агентная среда. Модель вызывает инструменты, получает результаты, выбирает следующий шаг и снова действует. В такой петле даже небольшая семантическая разница влияет на скорость, управляемость и качество всей цепочки: блокировать выполнение или нет, показывать полный лог или подготовленное резюме, сохранять ли исходный typed result отдельно от model-visible output.

Для читателя, который следит за OpenAI, важна именно эта инженерная рамка. Большая часть публичных новостей о моделях строится вокруг возможностей, демонстраций и сравнений. Здесь повод другой: обсуждается не то, насколько сильной стала модель, а то, каким должен быть слой между моделью, инструментом, логами и интерфейсом. В агентных продуктах этот слой быстро становится не менее важным, чем сама модель.

Что предложено в issue #34895

Issue #34895 предлагает расширить поведение PostToolUse, события после использования инструмента. В агентной петле это момент, когда инструмент уже вернул ответ, а система решает, что передать дальше модели, пользователю, логам или другим потребителям событий. В Codex такими инструментами могут быть Bash, apply_patch, MCP-инструмент или другая локальная функция.

Суть предложения: добавить универсальное поле updatedToolOutput в hookSpecificOutput для PostToolUse. Оно должно заменить только тот результат инструмента, который будет виден модели, но не превращать успешный tool call в ошибку и не останавливать дальнейшую работу агента. В досье это описано как bounded replacement: компактная, очищенная или нормализованная версия вывода вместо полного сырого результата.

Практический пример: агент запускает тесты и получает длинный лог. Полезны в нем только первые ошибки и путь к полному артефакту. Вместо того чтобы отдавать модели весь вывод или блокировать выполнение, hook мог бы подготовить короткое сообщение: какие тесты упали, где первый сбой и где хранится полный лог. Агент при этом продолжил бы работу без ручного unblock и без имитации неуспешного tool call.

В issue также указаны правила, важные для архитектуры. Если несколько hooks возвращают валидные замены, последняя валидная должна победить. updatedToolOutput должен иметь приоритет над MCP-специфичным updatedMCPToolOutput. При этом исходный typed result, по предложению автора issue, не исчезает: он остается доступным code mode, внутренним логам и потребителям transcript или events.

Речь не о стирании факта выполнения, а о разделении двух плоскостей: что произошло на самом деле и что попадет в контекст рассуждения модели. Для агентной системы это принципиально. Один и тот же tool call может быть нужен для аудита в полном виде, для интерфейса в одном виде и для следующего шага модели в другом виде. Issue предлагает сделать это различие явным в контракте hooks.

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

«PostToolUse: неблокирующая замена вывода инструмента, видимого модели.»

Почему proposal не стоит читать как roadmap

Главная редакционная ошибка в такой новости: написать, что OpenAI добавляет новую функцию. Доступные источники этого не подтверждают. Issue открыт 23 июля 2026 года и описывает предложение, но в досье нет признаков принятого roadmap: назначенного исполнителя, milestone, проекта или pull request, реализующего updatedToolOutput.

Более точная формулировка: в openai/codex обсуждается non-blocking replacement для model-visible tool output. OpenAI может принять идею, изменить ее, объединить с другой работой вокруг hooks или не реализовать. Но сам факт обсуждения показывает направление инженерного давления: агентной системе нужен более тонкий слой управления промежуточными результатами инструментов.

Контекст активности репозитория усиливает новостной повод, но не доказывает внедрение конкретного proposal. В каталоге источников есть отдельные страницы commits и releases Codex, однако релизная активность не равна подтверждению updatedToolOutput. Для аккуратной публикации это разные утверждения: репозиторий развивается, и функция уже попала в продукт.

Такая осторожность особенно важна для материалов об OpenAI. Вокруг продуктов компании быстро появляются пересказы, где issue, commit, обсуждение и релиз смешиваются в одну новость. Для технической аудитории это создает неверные ожидания. Если функция пока описана как issue, ее нужно читать как предложение или обсуждение, а не как обещание поставки.

При этом не стоит обесценивать сам issue. Публичные обсуждения низкоуровневых контрактов часто показывают, где продукт сталкивается с реальной сложностью. В данном случае сложность не в генерации кода как таковой, а в управлении тем, что модель получает после действий в среде. Для coding agents это один из центральных элементов качества.

Механизм: зачем отделять model-visible output от raw result

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

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

Поэтому model-visible output становится отдельной проекцией фактического результата. Raw или typed result: то, что реально вернул инструмент. Model-visible output: то, что попадет в контекст модели и повлияет на ее следующий шаг. Transcript, events и внутренние логи образуют еще одну плоскость, важную для интерфейса, истории и наблюдаемости.

Issue #34895 предлагает менять именно model-visible слой, не подменяя остальные каналы. Это тонкая, но полезная граница. Система не обязана делать вид, что инструмент вернул другой результат. Она может сохранить оригинал, но дать модели подготовленную версию: короче, чище, структурнее и ближе к задаче следующего шага.

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

Если hook сжимает лог тестов до трех строк, модель экономит контекст и быстрее понимает, где ошибка. Но если сжатие убрало важную деталь, следующий шаг может стать хуже. Поэтому отделение model-visible output от raw result не является автоматическим улучшением. Это новый слой управления, который требует дисциплины, понятных правил и наблюдаемости.

Почему non-blocking важен для агентных workflows

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

Предложение #34895 ищет промежуточный режим. Hook после tool call может подготовить для модели более удобный результат, но сам tool call остается успешным. Для команд, которые строят loops вокруг Codex CLI или Desktop, это принципиальная разница: иногда нужно не остановить агента, а убрать шум, свернуть длинный вывод, нормализовать формат или выделить главное.

Для OpenAI эта деталь показательна: развитие агентных продуктов зависит не только от умности модели. Даже сильная модель хуже работает, если контекст заполнен бессистемными логами или если каждое действие требует ручной развилки. Качество agent loop определяется оркестрацией: какие инструменты доступны, что считается успехом, как результат возвращается модели и где сохраняются следы выполнения.

Факт здесь ограничен: в issue предложено non-blocking replacement для результата, видимого модели. Остальное нужно формулировать осторожнее. Такой механизм укладывается в более широкий переход от бинарного показать все или заблокировать к управлению формой обратной связи после tool call.

Если контракт появится в Codex, он может стать полезным middleware-слоем для более зрелых агентных workflows. Но пока это именно если. Важно не превращать архитектурную возможность в утверждение о продукте. Сейчас можно говорить о том, что такая логика обсуждается в публичном репозитории, а не о том, что она уже доступна всем пользователям.

Практическая ценность non-blocking режима особенно заметна в задачах с повторяющимися проверками. Тесты, линтеры, сборки, поиск по проекту и диагностика окружения часто возвращают много текста. Для человека в IDE это привычный шум, который можно прокрутить глазами. Для модели это токены, внимание и риск потерять главный сигнал. Hook, который делает вывод короче без остановки работы, может улучшить именно темп агентной петли.

Безопасность: почему это не полноценная redaction-система

Proposal #34895 не стоит читать как готовое решение для compliance или защиты секретов. Предложение ограничено заменой model-visible output при сохранении исходного typed result для других потребителей. Это полезно для качества рассуждения модели и экономии контекста, но не означает, что чувствительные данные не окажутся в UI, transcript или локальных логах.

Для enterprise-сценариев различие критично. Модель не увидела секрет и секрет нигде не сохранился: это разные уровни защиты. Если сырой output уже попал в журнал, transcript или другой канал, замена только model-visible слоя не закрывает весь жизненный цикл утечки. Поэтому updatedToolOutput, даже если будет реализован, следует воспринимать как управление входом модели, а не как универсальный data-loss prevention.

Есть и вопрос аудита. Если несколько hooks могут менять model-visible output, нужно понимать порядок применения, источник каждой замены и место хранения оригинала. Правило last valid replacement should win технически простое, но в организации оно поднимает практические вопросы: какой hook был последним, кто его установил, как отладить конфликт между политиками и пользовательскими скриптами, как восстановить причину решения агента.

Наконец, есть риск качества. Сжатый вывод может оказаться слишком агрессивным: hook уберет строку, которая казалась шумом, но была важна для диагностики. Агент продолжит работу быстрее, однако следующий шаг построит на неполной информации. Поэтому non-blocking replacement требует не только механизма замены, но и наблюдаемости: разработчик должен видеть, что вернул инструмент и что именно получила модель.

В этом смысле security-контекст Codex важен как напоминание о границах ответственности. Управление видимостью для модели не равно управлению всеми копиями данных. Если организация строит процесс вокруг coding agents, ей придется отдельно описывать, где хранится raw output, кто видит transcript, какие события уходят во внешние consumers и какие данные разрешено передавать модели.

Именно здесь полезна строгая терминология. Filtering for model означает, что модель получила подготовленную версию. Redaction в полном смысле требует гарантий по всем каналам, где могли сохраниться данные. Issue #34895, согласно доступному описанию, относится к первому случаю. Подменять его вторым нельзя.

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

«Последняя валидная замена должна победить.»

Как это связано с соседними изменениями Codex

В каталоге источников рядом с #34895 есть другие низкоуровневые темы Codex. Issue #34837 от 22 июля 2026 года касается opt-in provider manifests для custom model catalogs. Это другой сюжет: не hooks и не PostToolUse, а подключение пользовательских провайдеров и каталогов моделей. Вместе эти обсуждения показывают общий вектор: Codex развивается как настраиваемая среда, а не только как единый клиент к одной модели.

Есть также отдельный источник о минимально поддерживаемой версии Computer Use в контексте Codex. Без привязки к реализации updatedToolOutput он все равно напоминает: агентные инструменты живут на стыке модели, интерфейса, локальной среды, удаленных вызовов и политик доступа. В такой системе вопрос, что видит модель после действия, становится не менее существенным, чем вопрос, какой инструмент ей разрешено вызвать.

Страница releases от 23 июля 2026 года важна как контекст живого цикла поставки. Но в доступном досье нет changelog-пункта, подтверждающего внедрение updatedToolOutput. Эту оговорку нужно сохранить, иначе статья превратит техническое обсуждение в псевдорелиз.

Отдельный issue про one-click migration, Codex Desktop Hub и Android Remote показывает еще одну сторону платформы: Codex присутствует в настольных и удаленных сценариях. Для поведения hooks это важно косвенно. Чем больше поверхностей у продукта, тем сложнее согласованно показывать результаты tool calls модели, пользователю, transcript и внешним consumers.

Поэтому разделение output-слоев выглядит не академической, а продуктовой проблемой. В одном сценарии пользователь смотрит на результат в Desktop, в другом agent loop продолжает работу через CLI, в третьем данные уходят в transcript или events. Если все эти каналы получают один и тот же сырой вывод, система проще, но менее гибкая. Если каналы получают разные представления, нужна строгая архитектура и хорошая отладка.

Соседние темы не доказывают реализацию updatedToolOutput. Они лишь помогают увидеть, в какой среде возникло предложение. Codex обсуждается как платформа с hooks, custom model catalogs, Computer Use, Desktop Hub и удаленными сценариями. В такой платформе настройка того, что именно видит модель после tool call, становится естественной частью развития.

Что это может изменить для разработчиков hooks

Если proposal примут, updatedToolOutput станет для hooks более точным инструментом, чем блокировка. Разработчик сможет не останавливать agent loop, а заменить только представление результата для модели. Инструмент сработал, оригинал сохранен, но модель получает подготовленный сигнал.

Первый сценарий: compression. Длинные логи тестов, build output, трассировки и результаты поиска по коду можно свернуть до резюме: статус, ключевые ошибки, affected files, путь к полному артефакту. Это не гарантирует правильного решения, но снижает вероятность, что важная информация утонет в шуме.

Второй сценарий: normalization. Разные инструменты возвращают разные форматы: JSON, текст, таблицы, stack trace, диагностические сообщения. Hook может привести их к структуре, удобной для следующего шага модели. В агентной петле это особенно существенно, потому что каждое действие опирается на результат предыдущего.

Третий сценарий: policy filtering для модели. Организация может решить, что модели достаточно видеть только часть вывода. Но это снова не заменяет полноценное удаление или маскирование данных во всех хранилищах. updatedToolOutput, как предложено в #34895, управляет model-visible layer, а не всем жизненным циклом данных.

Польза для отладки появится только при хорошей наблюдаемости. Если исходный typed result остается доступен логам и transcript consumers, разработчик сможет сравнить, что вернул инструмент, как hook преобразовал output и почему модель пошла дальше именно так. Без такой прозрачности замененный вывод рискует стать еще одним непрозрачным слоем.

Для команд, которые уже пишут интеграции вокруг coding agents, главный вопрос будет не только в синтаксисе поля. Важнее политика: какие hooks имеют право менять model-visible output, в каком порядке они применяются, где фиксируется оригинал, как логируется замена и кто отвечает за ошибку, если модель приняла решение на слишком урезанном сигнале.

Если таких правил нет, non-blocking replacement может быстро превратиться в источник неожиданных багов. Агент не остановился, потому что tool call считается успешным. Модель получила аккуратное резюме, но в нем не оказалось критичной строки. В интерфейсе пользователь видит одну картину, в логах лежит другая, а transcript consumers получают третью. Именно поэтому архитектура output mediation требует дисциплины, а не только удобного поля в API hooks.

Российский контекст без домыслов

Проверяемого российского контекста по issue #34895, внедрению updatedToolOutput или локальным deployment-кейсам Codex в предоставленном досье нет. Поэтому нельзя утверждать, что российские компании уже используют этот механизм, ждут именно эту функцию или столкнутся с конкретными регуляторными последствиями. Таких данных среди разрешенных источников не зафиксировано.

Допустима только практическая редакционная привязка. Для российских команд, которые используют Codex CLI или Desktop там, где это доступно и соответствует их правилам, тема относится к управлению промежуточными outputs, логами, секретами и расходом контекста. Но это не локальный рыночный факт, а следствие общей архитектуры агентных систем: если агент вызывает инструменты и получает большие результаты, нужно управлять тем, что именно попадает модели.

В этом смысле issue #34895 полезен как образовательный повод. Он показывает, какие вопросы стоит задавать при внедрении любых coding agents: где хранится сырой output, что видит модель, какие hooks могут менять данные, как устроен transcript, кто имеет доступ к логам и можно ли воспроизвести решение агента по исходным событиям.

Эти вопросы одинаково важны для разных инженерных команд, но конкретные ответы зависят от продукта, конфигурации и юридического режима. Редакционно корректная позиция: не переносить обсуждение из openai/codex на российский рынок без источников, но использовать его как повод разобрать архитектурные риски, которые возникают у агентных инструментов в любой среде.

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

Почему это важно для понимания OpenAI Codex

История с #34895 не похожа на презентацию новой модели. В ней нет демо, рейтингов и громких обещаний. Зато есть то, из чего на практике складываются зрелые агентные продукты: контракты событий, порядок hooks, видимость результатов, разделение внутренних и model-facing данных.

Codex как класс продукта находится между моделью и инженерной средой. Его успех зависит не только от способности генерировать код, но и от способности действовать в реальном проекте: читать файлы, запускать проверки, править диффы, понимать ошибки, не терять контекст и не останавливаться без необходимости. Non-blocking model-visible replacement: небольшая деталь, но она находится ровно в этой зоне.

Сильный вывод нужно формулировать осторожно. Issue #34895 не доказывает, что OpenAI уже перестраивает Codex вокруг нового слоя output mediation. Но он показывает, что в публичной инженерной повестке Codex есть запрос на более гранулярное управление результатами инструментов. Вместо грубой схемы показать все или заблокировать может появиться режим: выполнить, сохранить оригинал, показать модели подготовленную версию.

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

Эта история также помогает точнее читать будущие новости о Codex. Если в релизах появятся новые механизмы hooks или output mediation, их стоит оценивать не только по удобству. Важно смотреть, как они разделяют raw result, model-visible output и audit events, есть ли порядок применения нескольких hooks, можно ли увидеть оригинал и подготовленную версию рядом, и не смешивается ли управление контекстом модели с обещаниями безопасности.

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

Если убрать технический шум, смысл issue #34895 сводится к одному вопросу: можно ли дать модели не весь результат инструмента, а подготовленное представление, при этом не останавливая успешный tool call. Для агентных workflows это не косметика. От формы промежуточного сигнала зависит, насколько быстро агент продолжит работу и насколько хорошо он поймет следующий шаг.

Но практический вывод должен оставаться осторожным. Пока в доступном досье нет подтверждения реализации, updatedToolOutput нельзя включать в инструкции как уже существующую функцию. Его можно обсуждать как proposal и как пример того, какие контракты нужны зрелым coding agents.

• Не читать issue #34895 как релиз: пока это публичное предложение без подтвержденного PR, milestone или назначенного владельца.
• Если proposal реализуют, hooks смогут менять не сам факт выполнения tool call, а результат, который попадет в контекст модели.
• Главный выигрыш для agent workflows: меньше блокировок и меньше шумных логов в reasoning context модели.
• Для безопасности этого недостаточно: model-visible replacement не гарантирует удаления чувствительных данных из UI, transcript или внутренних логов.
• Командам стоит разделять три слоя: raw tool result, model-visible output и audit/transcript events.
• Правило последняя валидная замена побеждает потребует прозрачной отладки, особенно если hooks приходят из разных уровней.

Вывод

Issue #34895 важен не потому, что OpenAI уже выкатила новую возможность Codex. Этого доступные источники не подтверждают. Он важен как публичный снимок инженерной проблемы: агент должен видеть достаточно, чтобы продолжать работу, но не обязан получать весь сырой вывод каждого инструмента.

Если non-blocking model-visible replacement появится в Codex, это будет небольшой, но показательный шаг к более зрелому управлению агентной петлей. Модель сможет работать с подготовленным сигналом, система сохранит оригинал для внутренних потребителей, а разработчики получат новый слой контроля над промежуточными результатами.

Но вместе с пользой появятся вопросы: как не исказить реальность для модели, как отлаживать несколько hooks, как не перепутать filtering-for-model с настоящей redaction и как доказать, что агент принял решение на корректной информации. Именно на таких деталях развивается Codex: не только в способности писать код, но и в умении действовать внутри инструментальной среды без лишних остановок и потери контроля.

Для OpenAI это показательный тип продуктовой работы. Не каждый значимый шаг выглядит как новая модель или большая презентация. Иногда зрелость появляется в точке, где модель, инструмент, hook и transcript начинают жить по более точному контракту. Issue #34895 пока не доказывает, что такой контракт принят. Но он хорошо показывает, почему агентные системы требуют инженерии вокруг модели, а не только более сильной модели.

Источники

• PostToolUse: non-blocking model-visible tool output replacement · Issue #34895 · openai/codex - OpenAI GitHub
• Codex commits - GitHub - OpenAI GitHub
• Releases · openai/codex - OpenAI GitHub
• What is the minimum supported version of Computer Use? · openai/codex@1823c13 - OpenAI GitHub
• Support opt-in provider manifests for custom model catalogs · Issue #34837 · openai/codex - OpenAI GitHub
• codex-security - GitHub - OpenAI GitHub
• One-click migration omitted an existing project from Codex Desktop Hub and therefore from Android Remote - OpenAI GitHub

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

OpenAI уже добавила updatedToolOutput в Codex?

Доступные источники этого не подтверждают. В статье речь идет о публичном issue #34895 в openai/codex, где обсуждается предложение, а не о подтвержденном релизе или roadmap.

Что означает model-visible output?

Это представление результата инструмента, которое попадет в контекст модели и повлияет на ее следующий шаг. Оно отличается от raw или typed result, то есть фактического результата, который вернул инструмент.

Зачем нужен non-blocking replacement после tool call?

Он позволяет подготовить для модели более короткий или структурированный вывод инструмента, не превращая успешный tool call в ошибку и не останавливая agent loop.

Можно ли считать updatedToolOutput системой защиты секретов?

Нет. По описанию issue механизм управляет тем, что видит модель, но не гарантирует удаление чувствительных данных из UI, transcript, внутренних логов или других каналов.

Почему это важно для разработчиков coding agents?

Потому что agent workflow зависит от качества промежуточных сигналов. Если модель получает шумные логи, она теряет контекст. Если выполнение часто блокируется, агент теряет темп. Proposal #34895 предлагает промежуточный режим.

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

Памятка по оценке model-visible output в coding agents

Короткий чек-лист для команд, которые внедряют или оценивают агентные инструменты разработки. Его можно вынести в downloads/codex-model-visible-output-checklist.pdf.

Перед внедрением hooks

• Разделить raw tool result, model-visible output и audit/transcript events.
• Проверить, какие инструменты возвращают длинные или шумные результаты.
• Определить, какие hooks могут менять вывод, видимый модели.
• Зафиксировать порядок применения hooks и правило для конфликтов.
• Не считать filtering-for-model полноценной redaction-системой.

При работе с логами и тестами

• Сохранять путь к полному артефакту или исходному логу.
• Передавать модели статус, ключевые ошибки и affected files.
• Не удалять диагностические строки без понятного правила.
• Сравнивать исходный typed result и подготовленный model-visible output при отладке.
• Проверять, не ухудшилось ли качество следующих шагов агента после сжатия вывода.

Для безопасности и аудита

• Проверить, где сохраняется сырой output помимо контекста модели.
• Описать доступ к UI, transcript, events и внутренним логам.
• Логировать, какой hook изменил output и почему.
• Не обещать отсутствие утечки, если контролируется только model-visible слой.
• Проверять конфликты между пользовательскими hooks и организационными политиками.