Середовище виконання обв’язки Codex

Ця сторінка документує runtime-контракт для проходів Codex harness. Для налаштування й маршрутизації почніть із Codex harness. Поля конфігурації див. у довіднику Codex harness.

​

Огляд

Режим Codex — це не OpenClaw з іншим викликом моделі під капотом. Codex володіє більшою частиною нативного циклу моделі, а OpenClaw адаптує свої поверхні Plugin, інструментів, сесій і діагностики навколо цієї межі. OpenClaw і далі володіє маршрутизацією каналів, файлами сесій, доставленням видимих повідомлень, динамічними інструментами OpenClaw, погодженнями, доставленням медіа та дзеркалом транскрипту. Codex володіє канонічним нативним тредом, нативним циклом моделі, нативним продовженням інструментів і нативною Compaction. Маршрутизація промптів дотримується вибраного runtime, а не лише рядка провайдера. Нативний прохід Codex отримує developer instructions сервера застосунку Codex, тоді як явний маршрут сумісності OpenClaw зберігає звичайний системний промпт OpenClaw навіть тоді, коли використовує Codex-подібну автентифікацію або транспорт OpenAI. Нативний Codex зберігає базові інструкції та інструкції моделі, що належать Codex, а також поведінку project-doc відповідно до активної конфігурації треду Codex. OpenClaw запускає та відновлює нативні треди Codex із вимкненою вбудованою персональністю Codex, щоб файли персональності робочої області та ідентичність агента OpenClaw лишалися авторитетними. Легкі запуски OpenClaw і далі зберігають наявне приглушення project-doc. Developer instructions OpenClaw охоплюють runtime-питання OpenClaw, як-от доставлення у вихідний канал, динамічні інструменти OpenClaw, делегування ACP, контекст адаптера та активні файли профілю робочої області агента. Каталоги Skills OpenClaw і маршрутизовані через інструменти вказівники MEMORY.md проєктуються як обмежені проходом developer instructions для співпраці в нативному Codex. Активний вміст BOOTSTRAP.md і повне fallback-вставлення MEMORY.md і далі використовують довідковий контекст вхідних даних проходу.

​

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

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

​

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

Коли прямий прохід або прохід чату джерела виконується через Codex harness, видимі відповіді за замовчуванням автоматично доставляються як фінальна відповідь асистента для внутрішніх поверхонь WebChat. Це узгоджує Codex із контрактом промпта Pi harness: агенти відповідають звичайно, а OpenClaw публікує фінальний текст у вихідну розмову. Установіть messages.visibleReplies: "message_tool", коли прямий чат або чат джерела має навмисно тримати фінальний текст асистента приватним, якщо агент не викличе message(action="send"). Проходи Codex Heartbeat також за замовчуванням отримують heartbeat_respond у пошуковому каталозі інструментів OpenClaw, щоб агент міг записати, чи пробудження має лишатися тихим, чи сповіщати, не кодувавши цей потік керування у фінальному тексті. Спеціальні для Heartbeat настанови щодо ініціативності надсилаються як developer instruction режиму співпраці Codex у самому проході Heartbeat. Звичайні проходи чату відновлюють режим Codex Default, замість того щоб переносити філософію Heartbeat у свій звичайний runtime-промпт. Коли існує непорожній HEARTBEAT.md, інструкції режиму співпраці Heartbeat вказують Codex на файл, а не вбудовують його вміст.

​

Межі хуків

Codex harness має три шари хуків: OpenClaw не використовує проєктні або глобальні файли Codex hooks.json для маршрутизації поведінки Plugin OpenClaw. Для підтримуваного мосту нативних інструментів і дозволів OpenClaw вставляє конфігурацію Codex для кожного треду для PreToolUse, PostToolUse, PermissionRequest і Stop. Коли погодження сервера застосунку Codex увімкнені, тобто approvalPolicy не є "never", стандартна вставлена конфігурація нативних хуків пропускає PermissionRequest, щоб рецензент сервера застосунку Codex і міст погоджень OpenClaw обробляли реальні ескалації після review. Оператори можуть явно додати permission_request до nativeHookRelay.events, коли їм потрібен relay сумісності. Інші хуки Codex, як-от SessionStart і UserPromptSubmit, лишаються контролями рівня Codex. Вони не відкриті як Plugin-хуки OpenClaw у контракті v1. Для динамічних інструментів OpenClaw OpenClaw виконує інструмент після того, як Codex запитує виклик, тому OpenClaw запускає поведінку Plugin і middleware, якою він володіє, в адаптері harness. Для нативних інструментів Codex Codex володіє канонічним записом інструмента. OpenClaw може дзеркалити вибрані події, але не може переписувати нативний тред Codex, якщо Codex не відкриває цю операцію через сервер застосунку або callbacks нативних хуків. Події PreToolUse у report-mode сервера застосунку Codex відкладають запити погодження Plugin до відповідного погодження сервера застосунку. Якщо хук OpenClaw before_tool_call повертає requireApproval, тоді як нативне навантаження задає режим погодження report (openclaw_approval_mode дорівнює "report"), relay нативних хуків записує вимогу погодження Plugin і не повертає нативного рішення. Коли Codex надсилає запит погодження сервера застосунку для того самого використання інструмента, OpenClaw відкриває запит погодження Plugin і відображає рішення назад у Codex. Події Codex PermissionRequest є окремим шляхом погодження і все ще можуть маршрутизуватися через погодження OpenClaw, коли runtime налаштовано для цього мосту. Сповіщення item сервера застосунку Codex також надають асинхронні спостереження after_tool_call для завершень нативних інструментів, які ще не покриті нативним relay PostToolUse. Ці спостереження призначені лише для телеметрії та сумісності Plugin; вони не можуть блокувати, затримувати або змінювати нативний виклик інструмента. Проєкції Compaction і життєвого циклу LLM походять зі сповіщень сервера застосунку Codex і стану адаптера OpenClaw, а не з команд нативних хуків Codex. Події OpenClaw before_compaction, after_compaction, llm_input і llm_output є спостереженнями рівня адаптера, а не побайтовими знімками внутрішнього запиту Codex або payload Compaction. Нативні сповіщення сервера застосунку Codex hook/started і hook/completed проєктуються як події агента codex_app_server.hook для траєкторії та налагодження. Вони не викликають Plugin-хуки OpenClaw.

​

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

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

​

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

Для PermissionRequest OpenClaw повертає лише явні рішення дозволити або відхилити, коли це вирішує політика. Результат без рішення не є дозволом. Codex трактує його як відсутність рішення хука та переходить до власного шляху guardian або затвердження користувачем. Режими затвердження сервера застосунку Codex за замовчуванням пропускають цей нативний хук. Ця поведінка застосовується, коли permission_request явно включено до nativeHookRelay.events або коли його встановлює сумісне середовище виконання. Коли оператор вибирає allow-always для запиту нативного дозволу Codex, OpenClaw запам’ятовує точний fingerprint провайдера/сеансу/вхідних даних інструменту/cwd для обмеженого вікна сеансу. Запам’ятоване рішення навмисно працює лише за точним збігом: змінена команда, аргументи, payload інструменту або cwd створюють нове затвердження. Запити затвердження інструментів Codex MCP маршрутизуються через потік затвердження Plugin в OpenClaw, коли Codex позначає _meta.codex_approval_kind як "mcp_tool_call". Промпти Codex request_user_input надсилаються назад до початкового чату, а наступне повідомлення відповіді з черги відповідає на цей нативний запит сервера, замість того щоб спрямовуватися як додатковий контекст. Інші MCP-запити завершуються із закритою відмовою. Для загального потоку затвердження Plugin, який переносить ці промпти, див. Запити дозволів Plugin.

​

Спрямування черги

Спрямування черги активного запуску відображається на turn/steer сервера застосунку Codex. Із типовим messages.queue.mode: "steer" OpenClaw групує повідомлення чату в режимі steer протягом налаштованого тихого вікна та надсилає їх як один запит turn/steer у порядку надходження. Перевірка Codex і ходи ручного Compaction можуть відхиляти керування в тому самому ході. У такому разі OpenClaw чекає завершення активного запуску, перш ніж запускати запит. Використовуйте /queue followup або /queue collect, коли повідомлення мають типово ставати в чергу замість керування. Див. Черга керування.

​

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

Коли /diagnostics [note] схвалено для сеансу з використанням нативного середовища Codex, OpenClaw також викликає feedback/upload app-server Codex для відповідних потоків Codex. Надсилання просить app-server включити журнали для кожного зазначеного потоку та породжених підпотоків Codex, коли вони доступні. Надсилання проходить через звичайний шлях відгуків Codex до серверів OpenAI. Якщо відгуки Codex вимкнено в цьому app-server, команда повертає помилку app-server. Завершена відповідь діагностики перелічує канали, ідентифікатори сеансів OpenClaw, ідентифікатори потоків Codex і локальні команди codex resume <thread-id> для потоків, які було надіслано. Якщо ви відхилите або проігноруєте схвалення, OpenClaw не виводить ці ідентифікатори Codex і не надсилає відгук Codex. Надсилання не замінює локальний експорт діагностики Gateway. Див. Експорт діагностики щодо схвалення, приватності, локального пакета й поведінки в груповому чаті. Використовуйте /codex diagnostics [note] лише тоді, коли вам потрібне саме надсилання відгуку Codex для поточного підключеного потоку без повного пакета діагностики Gateway.

​

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

Коли вибрана модель використовує середовище Codex, нативний Compaction потоку належить app-server Codex. OpenClaw не виконує попередній Compaction для ходів Codex, не замінює Compaction Codex на Compaction context-engine і не переходить до підсумовування OpenClaw або публічного OpenAI, коли нативний Compaction Codex неможливо запустити. OpenClaw зберігає дзеркало транскрипту для історії каналу, пошуку, /new, /reset і майбутнього перемикання моделі або середовища. Явні запити Compaction, як-от /compact або запитана Plugin операція ручного compact, запускають нативний Compaction Codex через thread/compact/start. OpenClaw тримає запит і оренду спільного клієнта відкритими, доки Codex не видасть відповідний завершальний елемент contextCompaction, а потім повідомляє хід Compaction як завершений. Якщо цей кінцевий хід перевищує налаштований час очікування Compaction, OpenClaw запитує нативне переривання ходу. Оренда та fence Compaction для окремого потоку залишаються утриманими, доки Codex не повідомить кінцевий стан або не підтвердить RPC переривання. Якщо Codex не підтвердить у межах пільгового періоду переривання, OpenClaw виводить з’єднання з обігу перед звільненням fence. Віддалені з’єднання також від’єднують відповідну прив’язку потоку, щоб подальша робота не могла накластися на непідтверджений віддалений хід. Інші ходи на виведеному з обігу з’єднанні завершуються помилкою й можуть повторитися на новому клієнті. Закриття клієнта, скасування запиту або невдалий хід Compaction повертає невдалу операцію. Коли context engine запитує проєкцію початкового завантаження потоку Codex, OpenClaw проєктує назви й ідентифікатори викликів інструментів, форми вхідних даних і відредагований вміст результатів інструментів у новий потік Codex. Він не копіює сирі значення аргументів викликів інструментів у цю проєкцію. Дзеркало містить запит користувача, фінальний текст асистента та легковагі записи міркувань або плану Codex, коли app-server їх видає. OpenClaw записує початок нативного Compaction і кінцевий стан, але не надає зручного для читання людиною підсумку Compaction або придатного для аудиту списку записів, які Codex зберіг після Compaction. Оскільки Codex володіє канонічним нативним потоком, tool_result_persist наразі не перезаписує нативні записи результатів інструментів Codex. Він застосовується лише тоді, коли OpenClaw записує результат інструмента транскрипту сеансу, що належить OpenClaw.

​

Медіа та доставка

OpenClaw і далі володіє доставкою медіа та вибором медіапровайдера. Зображення, відео, музика, PDF, TTS і розуміння медіа використовують відповідні налаштування провайдера/моделі, як-от agents.defaults.imageGenerationModel, videoGenerationModel, pdfModel і messages.tts. Текст, зображення, відео, музика, TTS, схвалення та вивід інструментів повідомлень і далі проходять звичайним шляхом доставки OpenClaw. Генерування медіа не потребує застарілого runtime. Коли Codex видає нативний елемент генерування зображення із savedPath, OpenClaw пересилає саме цей файл через звичайний шлях reply-media, навіть якщо хід Codex не має тексту асистента.

​

Пов’язане

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