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

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

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

​

Огляд

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

​

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

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

​

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

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

​

Межі hooks

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

​

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

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

​

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

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

​

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

Керування чергою активного запуску відображається на Codex app-server turn/steer. З типовим messages.queue.mode: "steer" OpenClaw групує повідомлення чату в черзі протягом налаштованого тихого вікна й надсилає їх як один запит turn/steer у порядку надходження. Застарілий режим queue надсилає окремі запити turn/steer. Ходи Codex review і ручної Compaction можуть відхиляти керування в межах того самого ходу. У такому випадку OpenClaw використовує чергу подальших повідомлень, коли вибраний режим дозволяє резервний варіант. Див. Черга керування.

​

Завантаження відгуку Codex

Коли /diagnostics [note] схвалено для сесії, що використовує нативний harness Codex, OpenClaw також викликає Codex app-server feedback/upload для відповідних потоків 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 і дзеркало транскрипту

Коли вибрана модель використовує harness Codex, нативна Compaction потоку делегується Codex app-server. OpenClaw зберігає дзеркало транскрипту для історії каналів, пошуку, /new, /reset і майбутнього перемикання моделі або harness. Дзеркало містить запит користувача, фінальний текст асистента та полегшені записи міркувань або плану Codex, коли app-server їх видає. Наразі OpenClaw записує лише сигнали початку й завершення нативної Compaction. Він ще не надає придатний для читання людиною підсумок Compaction або придатний для аудиту список записів, які Codex зберіг після Compaction. Оскільки Codex володіє канонічним нативним потоком, tool_result_persist наразі не перезаписує записи результатів інструментів, нативні для Codex. Він застосовується лише тоді, коли OpenClaw записує результат інструмента транскрипту сесії, що належить OpenClaw.

​

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

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

​

Пов’язане

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