Середовище виконання Codex harness

Контракт середовища виконання для ходів у обв’язці Codex. Відомості про налаштування та маршрутизацію див. у Обв’язка Codex. Відомості про поля конфігурації див. у Довідник обв’язки Codex.

Огляд

Codex керує власним циклом моделі, власним відновленням потоків, власним продовженням роботи інструментів і власною Compaction. OpenClaw керує маршрутизацією каналів, файлами сеансів, доставкою видимих повідомлень, динамічними інструментами OpenClaw, схваленнями, доставкою медіа та дзеркалом стенограми навколо цієї межі.

Маршрутизація запитів визначається вибраним середовищем виконання, а не лише рядком постачальника. Власний хід Codex отримує інструкції розробника app-server Codex; явний маршрут сумісності OpenClaw зберігає звичайний системний запит OpenClaw, навіть якщо використовує автентифікацію або транспорт OpenAI у стилі Codex.

OpenClaw запускає та відновлює власні потоки Codex із вимкненою вбудованою особистістю Codex (personality: "none"), щоб файли особистості робочого простору й ідентичність агента OpenClaw залишалися визначальними. В інших аспектах власний Codex зберігає базові інструкції та інструкції моделі, якими керує Codex, а також завантаження документації проєкту. Спрощені запуски OpenClaw (наприклад, cron) усе одно пригнічують завантаження документації проєкту.

Інструкції розробника OpenClaw охоплюють аспекти середовища виконання OpenClaw: доставку до вихідного каналу, динамічні інструменти OpenClaw, делегування ACP, контекст адаптера та файли профілю активного робочого простору агента. Каталоги Skills і вказівники MEMORY.md, маршрутизовані через інструменти, проєктуються як інструкції розробника щодо співпраці в межах ходу. Коли інструменти пам’яті недоступні, активний вміст BOOTSTRAP.md і повний MEMORY.md натомість передаються як звичайний вхідний контекст ходу.

Більшість динамічних інструментів OpenClaw використовують простір імен openclaw із підтримкою пошуку. Інструменти, позначені catalogMode: "direct-only", використовують openclaw_direct, який Codex залишає безпосередньо видимим моделі як DirectModelOnly, а не надає його вкладеному виконанню в режимі коду.

Прив’язки потоків і зміни моделі

Коли сеанс OpenClaw приєднано до наявного потоку Codex, наступний хід повторно надсилає app-server поточну вибрану модель, політику схвалення, пісочницю, рецензента схвалень і рівень обслуговування. Перехід з openai/gpt-5.5 на openai/gpt-5.2 зберігає прив’язку потоку, але просить Codex продовжити роботу з новою вибраною моделлю.

Контрольовані прив’язки є винятком. Засіб вибору моделі OpenClaw залишається заблокованим, а під час відновлення перевизначення моделі й постачальника не передаються, щоб Codex відновив збережені модель і постачальника канонічного потоку. Окремий власний елемент керування Codex може змінити цю збережену пару, а початковий знімок може спричинити звичайне попередження Codex про відмінність моделі; зовнішня модель OpenClaw і ланцюжок резервних варіантів ніколи не замінюють жоден із цих двох параметрів.

Контроль і безпечне продовження

Контроль Codex — це можливість того самого Plugin codex, яку потрібно ввімкнути явно. Він виявляє власні потоки через окреме з’єднання та проєктує в каталог Gateway лише неархівовані сеанси. Без явних параметрів з’єднання appServer це з’єднання використовує керований stdio домашнього каталогу користувача, тоді як звичайна обв’язка залишається обмеженою агентом. Отримання списку та читання метаданих є пасивними: вони не відновлюють потік, не підписують OpenClaw на його поточні події та не відповідають на його запити на схвалення.

Для збереженого або неактивного сеансу на комп’ютері Gateway команда Продовжити як гілку створює звичайний, прив’язаний до моделі чат і дзеркально переносить обмежену історію користувача та асистента до останнього завершеного збереженого ходу джерела включно. Перший звичайний хід чату встановлює справжні обробники схвалень і використовує тимчасове власне відгалуження, щоб зафіксувати знімок без перевизначення моделі чи постачальника. Codex App Server використовує свою поточну власну конфігурацію та повертає вибрану пару; він видає звичайне попередження, якщо ця модель відрізняється від останньої записаної моделі джерела. Через те саме контрольне з’єднання OpenClaw запускає канонічний потік обв’язки Codex із джерелом appServer у його робочому каталозі та відповідно до політики середовища виконання, використовуючи для цього початкового запуску саме повернуті модель і постачальника, впроваджує обмежену видиму історію та архівує тимчасове відгалуження. Джерело ніколи не відновлюється. Канонічний потік має повний набір інструментів обв’язки OpenClaw; міркування, виклики інструментів і результати інструментів із джерела до нього не клонуються. Приватна область з’єднання зберігається для станів прив’язки, що очікують і вже зафіксовані, тому кожен наступний хід залишається в цьому з’єднанні з власною автентифікацією та конфігурацією постачальника. Вимкнений контроль або розбіжність прив’язки чи з’єднання призводить до безпечної відмови, а не до переходу на звичайну обв’язку домашнього каталогу агента.

Початкове джерело CLI або VS Code залишається придатним для обох каталогів. Канонічна гілка є власним потоком Codex, але тип її джерела — appServer; власні клієнти можуть фільтрувати цей тип джерела, тому її відображення в Codex Desktop не гарантується.

Для активних джерел не можна створювати нову гілку або архівувати їх; наявний контрольований чат усе одно можна відкрити. notLoaded означає, що активність невідома, а не що джерело неактивне; OpenClaw дозволяє архівувати локальний рядок idle або notLoaded лише після явного підтвердження відсутності іншого виконавця та нового читання стану в межах процесу. Codex серіалізує зміни потоків у межах одного процесу App Server, але не надає ексклюзивної міжпроцесної оренди виконавця або власника схвалень, тому таке читання не може довести, що інший процес не використовує потік. OpenClaw блокує відомого активного власника прив’язки для точної цілі або будь-якого неархівованого породженого нащадка, повернутого сторінковим запитом нащадків Codex. Помилки переліку, цикли та вичерпання ліміту безпеки призводять до безпечної відмови. Власне архівування все одно може збігтися в часі з новим ходом в іншому процесі, тому підтвердження охоплює невідомих клієнтів і проміжок між читанням стану та архівуванням. Контрольований чат із фіксованою моделлю не можна видалити, доки він захищає власну прив’язку.

Каталоги спарених вузлів у початковому випуску залишаються лише метаданими. Поточна межа виклику вузла працює за схемою запит/відповідь і не може передавати довготривалі події ходу, запити на схвалення або потокове виведення, потрібні для справжньої прив’язки обв’язки Codex. Тому віддалені дії Продовжити та Архівувати залишаються недоступними, навіть коли рядок неактивний.

Відомості про налаштування оператором і видиму поведінку інтерфейсу керування див. у розділі Контроль Codex.

Видимі відповіді та Heartbeat

Прямі ходи чату або ходи чату джерела через обв’язку Codex за замовчуванням автоматично доставляють остаточну відповідь асистента до внутрішніх поверхонь WebChat відповідно до контракту обв’язки Pi: агент відповідає звичайним чином, а OpenClaw публікує остаточний текст у вихідній розмові. Установіть messages.visibleReplies: "message_tool", щоб остаточний текст асистента залишався приватним, якщо агент не викличе message(action="send").

Ходи Heartbeat Codex за замовчуванням отримують heartbeat_respond у доступному для пошуку каталозі інструментів OpenClaw, щоб агент міг записати, чи пробудження має залишитися беззвучним, чи надіслати сповіщення. Настанови щодо ініціативності Heartbeat надсилаються як інструкція розробника режиму співпраці Codex, обмежена ходом Heartbeat; звичайні ходи чату залишаються в стандартному режимі Codex. Якщо HEARTBEAT.md не порожній, інструкції Heartbeat спрямовують Codex до файлу замість вбудовування його вмісту.

Межі перехоплювачів

OpenClaw не використовує проєктні або глобальні файли Codex hooks.json для маршрутизації поведінки Plugin. Для мосту власних інструментів і дозволів OpenClaw впроваджує конфігурацію Codex для кожного потоку для PreToolUse, PostToolUse, PermissionRequest і Stop.

Коли схвалення app-server Codex увімкнено (approvalPolicy не дорівнює "never"), стандартна впроваджена конфігурація власних перехоплювачів не містить PermissionRequest, щоб рецензент app-server Codex і міст схвалень OpenClaw обробляли справжні ескалації після перевірки. Додайте permission_request до nativeHookRelay.events, щоб у будь-якому разі примусово використовувати ретранслятор сумісності. Інші перехоплювачі Codex, як-от SessionStart і UserPromptSubmit, залишаються елементами керування рівня Codex; у контракті v1 вони не надаються як перехоплювачі Plugin OpenClaw.

Для динамічних інструментів OpenClaw виконує інструмент після того, як Codex запитує виклик, тому поведінка Plugin і проміжного ПЗ виконується в адаптері обв’язки. Для власних інструментів Codex керує канонічним записом інструмента; OpenClaw може дзеркально відтворювати вибрані події, але не може переписувати власний потік, якщо Codex не надає такої можливості через app-server або зворотні виклики власних перехоплювачів.

Події PreToolUse app-server Codex у режимі звітування відкладають схвалення Plugin до відповідного схвалення app-server. Якщо перехоплювач OpenClaw before_tool_call повертає requireApproval, а власне корисне навантаження задає openclaw_approval_mode: "report", ретранслятор власних перехоплювачів записує вимогу схвалення Plugin і не повертає власного рішення. Коли Codex згодом надсилає запит app-server на схвалення для того самого використання інструмента, OpenClaw відкриває запит на схвалення Plugin і зіставляє рішення з Codex. Події Codex PermissionRequest є окремим шляхом схвалення й усе одно можуть маршрутизуватися через схвалення OpenClaw, якщо для цього мосту задано відповідну конфігурацію.

Сповіщення про елементи app-server Codex також надають асинхронні спостереження after_tool_call за завершенням роботи власних інструментів, які ще не охоплені ретранслятором власного PostToolUse. Вони призначені лише для телеметрії та сумісності; вони не можуть блокувати, затримувати або змінювати виклик власного інструмента.

Проєкції Compaction і життєвого циклу LLM надходять зі сповіщень app-server Codex і стану адаптера OpenClaw, а не з команд власних перехоплювачів Codex. before_compaction, after_compaction, llm_input і llm_output є спостереженнями рівня адаптера, а не побайтовими копіями внутрішніх запитів або корисних навантажень Compaction у Codex.

Власні сповіщення app-server Codex hook/started і hook/completed проєктуються як події агента codex_app_server.hook для траєкторії та налагодження. Вони не викликають перехоплювачі Plugin OpenClaw.

Контракт підтримки V1

Підтримується в середовищі виконання Codex v1:

Не підтримується в середовищі виконання Codex v1:

Нативні дозволи та запити MCP

Для PermissionRequest OpenClaw повертає явні рішення про дозвіл або відмову лише тоді, коли їх визначає політика. Відсутність рішення не означає дозвіл: Codex трактує це як відсутність рішення хука й переходить до власного захисника або шляху схвалення користувачем.

Режими схвалення сервера застосунку Codex типово не використовують цей нативний хук. Це діє, якщо permission_request явно не включено до nativeHookRelay.events або його не встановлює сумісне середовище виконання.

Коли оператор вибирає allow-always для запиту нативного дозволу Codex, OpenClaw запам’ятовує точний відбиток постачальника, сеансу, вхідних даних інструмента та cwd протягом обмеженого вікна сеансу. Запам’ятоване рішення навмисно застосовується лише за точного збігу: змінена команда, аргументи, корисне навантаження інструмента або cwd створюють новий запит на схвалення.

Запити на схвалення інструментів Codex MCP спрямовуються через потік схвалення плагінів OpenClaw, коли Codex позначає _meta.codex_approval_kind як "mcp_tool_call". Запити request_user_input Codex надсилаються назад до початкового чату, а наступне повідомлення у черзі відповідає на цей запит нативного сервера, замість того щоб бути спрямованим як додатковий контекст. Інші запити MCP завершуються безпечною відмовою.

Опис загального потоку схвалення плагінів, який передає ці запити, див. у розділі Запити дозволів плагінів.

Керування чергою

Керування чергою під час активного виконання відображається на turn/steer сервера застосунку Codex. За типового значення messages.queue.mode: "steer" OpenClaw об’єднує повідомлення чату в режимі керування протягом налаштованого періоду очікування та надсилає їх одним запитом turn/steer у порядку надходження.

Огляд Codex і ручні ходи Compaction можуть відхиляти керування в межах того самого ходу. У такому разі OpenClaw чекає завершення активного запуску, перш ніж почати обробку запиту. Використовуйте /queue followup або /queue collect, коли повідомлення за замовчуванням мають ставати в чергу, а не керувати поточним ходом. Див. Черга керування.

Надсилання відгуку Codex

Коли /diagnostics [note] схвалено для сеансу в нативному середовищі виконання Codex, OpenClaw також викликає feedback/upload сервера застосунку Codex для відповідних потоків Codex, включно з журналами кожного зазначеного потоку та породжених підпотоків Codex, якщо вони доступні.

Надсилання відбувається через звичайний механізм зворотного зв’язку Codex на сервери OpenAI. Якщо зворотний зв’язок Codex вимкнено на цьому сервері застосунку, команда повертає помилку сервера застосунку. У відповіді про завершену діагностику наведено канали, ідентифікатори сеансів OpenClaw, ідентифікатори потоків Codex і локальні команди codex resume <thread-id> для надісланих потоків.

Якщо ви відхилите або проігноруєте схвалення, OpenClaw не виведе ці ідентифікатори Codex і не надішле відгук Codex. Надсилання не замінює локальний експорт діагностики Gateway. Відомості про схвалення, конфіденційність, локальний пакет і поведінку в групових чатах див. у розділі Експорт діагностики.

Використовуйте /codex diagnostics [note] лише тоді, коли потрібно надіслати відгук Codex для поточного приєднаного потоку без повного пакета діагностики Gateway.

Compaction і дзеркало транскрипту

Коли вибрана модель використовує середовище виконання Codex, нативне ущільнення потоку належить серверу застосунку Codex. OpenClaw не запускає попереднє ущільнення для ходів Codex, не замінює ущільнення Codex ущільненням механізму контексту й не переходить до резервного узагальнення OpenClaw або загальнодоступного OpenAI, якщо нативне ущільнення неможливо запустити. OpenClaw зберігає дзеркало транскрипту для історії каналів, пошуку, /new, /reset і майбутнього перемикання моделі або середовища виконання.

Явні запити на ущільнення, як-от /compact або запитана Plugin операція ручного ущільнення, запускають нативне ущільнення Codex через thread/compact/start. OpenClaw утримує запит і оренду спільного клієнта відкритими, доки Codex не надішле відповідний елемент завершення contextCompaction, після чого повідомляє про завершення ходу ущільнення. Якщо цей завершальний хід перевищує налаштований час очікування ущільнення, OpenClaw запитує нативне переривання ходу. Оренда й бар’єр ущільнення для окремого потоку залишаються утриманими, доки Codex не повідомить про завершальний стан або не підтвердить RPC переривання. Якщо Codex не підтвердить його протягом пільгового періоду переривання, OpenClaw виводить з’єднання з експлуатації, перш ніж звільнити бар’єр. Для віддалених з’єднань також від’єднується відповідна прив’язка потоку, щоб подальша робота не могла перекриватися з непідтвердженим віддаленим ходом. Інші ходи через виведене з експлуатації з’єднання завершуються помилкою та можуть бути повторені через нового клієнта. Закриття клієнта, скасування запиту або невдалий хід ущільнення повертає невдалу операцію. Автоматичне ущільнення через тиск контексту виконує Codex; OpenClaw лише запускає нативне ущільнення для вручну запитаних тригерів.

Коли механізм контексту запитує проєкцію ініціалізації потоку Codex, OpenClaw проєктує назви й ідентифікатори викликів інструментів, форми вхідних даних і відредагований вміст результатів інструментів у новий потік Codex. Необроблені значення аргументів викликів інструментів до цієї проєкції не копіюються.

Дзеркало містить запит користувача, остаточний текст асистента та спрощені записи міркувань або плану Codex, коли сервер застосунку їх надсилає. OpenClaw записує початок і завершальний стан нативного ущільнення, але не надає зрозумілого людині підсумку ущільнення чи придатного для аудиту списку записів, які Codex зберіг після ущільнення.

Оскільки Codex володіє канонічним нативним потоком, tool_result_persist не перезаписує нативні записи результатів інструментів Codex. Він застосовується лише тоді, коли OpenClaw записує результат інструмента транскрипту сеансу, що належить OpenClaw.

Медіа й доставлення

OpenClaw і надалі відповідає за доставлення медіа та вибір постачальника медіа. Для зображень, відео, музики, PDF, TTS і розпізнавання медіа використовуються відповідні налаштування постачальника або моделі, як-от agents.defaults.imageGenerationModel, videoGenerationModel, pdfModel і messages.tts.

Текст, зображення, відео, музика, TTS, схвалення та вивід інструментів обміну повідомленнями й надалі проходять через звичайний шлях доставлення OpenClaw; створення медіа не потребує застарілого середовища виконання. Коли Codex надсилає нативний елемент створення зображення із savedPath, OpenClaw пересилає саме цей файл через звичайний шлях медіавкладень відповіді, навіть якщо хід Codex не містить тексту асистента.

Пов’язані матеріали

• Середовище виконання Codex
• Довідник середовища виконання Codex
• Нагляд Codex
• Нативні плагіни Codex
• Хуки Plugin
• Плагіни середовища виконання агента
• Експорт діагностики
• Експорт траєкторії