From 0e5f3cfee8a862944a216c2e712918b7966da892 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Sun, 26 Apr 2026 20:30:51 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/ci.md | 199 +++++---- docs/uk/plugins/codex-harness.md | 667 +++++++++++++++++-------------- 2 files changed, 461 insertions(+), 405 deletions(-) diff --git a/docs/uk/ci.md b/docs/uk/ci.md index 0ce269b41..c634c4c8b 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -2,59 +2,56 @@ read_when: - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося - Ви налагоджуєте збої перевірок GitHub Actions -summary: Граф завдань CI, обмежувальні перевірки за областю змін і локальні еквіваленти команд -title: Конвеєр CI +summary: Граф завдань CI, обмеження області перевірок і локальні еквіваленти команд +title: CI-конвеєр x-i18n: - generated_at: "2026-04-25T22:53:53Z" + generated_at: "2026-04-26T20:28:16Z" model: gpt-5.4 provider: openai - source_hash: 1a6c14f785434585f2b3a72bcd2cff3a281e51fe12cc4c14aa7613d47cd8efc4 + source_hash: e6a7499389b8bf366cd6a244ec935edf13a557a1bdd61bf346bba46a12db0f82 source_path: ci.md workflow: 15 --- -CI запускається для кожного пушу в `main` і для кожного pull request. Він використовує розумне обмеження за областю змін, щоб пропускати дорогі завдання, коли змінилися лише не пов’язані частини. +CI запускається при кожному push до `main` і для кожного pull request. Він використовує розумне обмеження області, щоб пропускати дорогі завдання, коли змінено лише непов’язані ділянки. -QA Lab має окремі доріжки CI поза основним робочим процесом із розумним обмеженням за областю змін. Робочий процес -`Parity gate` запускається для PR зі змінами, що відповідають умовам, і через ручний запуск; він -збирає приватне середовище виконання QA і порівнює агентні пакети mock GPT-5.5 та Opus 4.6. -Робочий процес `QA-Lab - All Lanes` запускається щоночі на `main` і через -ручний запуск; він розгалужує mock parity gate, live доріжку Matrix і live -доріжку Telegram як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, -а доріжка Telegram використовує оренди Convex. `OpenClaw Release -Checks` також запускає ті самі доріжки QA Lab перед затвердженням релізу. +QA Lab має окремі CI-лінії поза основним workflow з розумним обмеженням області. +Workflow `Parity gate` запускається для відповідних змін у PR і через ручний запуск; він +збирає приватне QA runtime і порівнює агентні набори mock GPT-5.5 та Opus 4.6. +Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і через +ручний запуск; він розпаралелює mock parity gate, live Matrix lane і live +Telegram lane як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, +а лінія Telegram використовує Convex leases. `OpenClaw Release +Checks` також запускає ті самі лінії QA Lab перед схваленням релізу. -Робочий процес `Duplicate PRs After Merge` — це ручний робочий процес для мейнтейнерів для -очищення дублікатів після злиття. За замовчуванням він працює в режимі dry-run і закриває лише явно -перелічені PR, коли `apply=true`. Перед внесенням змін у GitHub він перевіряє, -що злитий PR справді об’єднано, а також що кожен дублікат має або спільну згадану задачу, -або перетин змінених фрагментів. +Workflow `Duplicate PRs After Merge` — це ручний workflow для мейнтейнерів для +очищення дублікатів після злиття. За замовчуванням він працює в режимі dry-run і +закриває лише явно вказані PR, коли `apply=true`. Перед внесенням змін у GitHub +він перевіряє, що злитий PR справді merged, і що кожен дублікат має або спільне згадане issue, +або перетин змінених hunk-ів. -Робочий процес `Docs Agent` — це керована подіями доріжка обслуговування Codex для підтримання -наявної документації у відповідності до нещодавно злитих змін. Він не має окремого запуску за розкладом: -його може запустити успішний неботовий запуск CI для пушу в `main`, а -ручний запуск може запустити його напряму. Виклики через запуск робочого процесу пропускаються, -якщо `main` уже просунувся далі або якщо протягом останньої години вже було створено -інший непроігнорований запуск Docs Agent. Коли він запускається, він -переглядає діапазон комітів від вихідного SHA попереднього непроігнорованого Docs Agent до -поточного `main`, тож один щогодинний запуск може охопити всі зміни в `main`, -накопичені з часу останнього проходу документації. +Workflow `Docs Agent` — це керована подіями лінія обслуговування Codex для підтримки +наявної документації у відповідності до нещодавно злитих змін. Вона не має окремого запуску за розкладом: +її може запустити успішний неблокований ботом CI run на `main`, а ручний запуск +може запускати її напряму. Виклики через workflow-run пропускаються, якщо +`main` уже змінився або якщо інший непропущений запуск Docs Agent було створено за останню годину. +Коли вона запускається, вона перевіряє діапазон комітів від попереднього непропущеного source SHA Docs Agent до +поточного `main`, тож один щогодинний запуск може охопити всі зміни в main, +накопичені з моменту останнього проходу документації. -Робочий процес `Test Performance Agent` — це керована подіями доріжка обслуговування Codex -для повільних тестів. Він не має окремого запуску за розкладом: його може -запустити успішний неботовий запуск CI для пушу в `main`, але він пропускається, якщо -інший виклик через запуск робочого процесу вже відпрацював або працює того самого дня за UTC. -Ручний запуск обходить це щоденне обмеження активності. Доріжка будує повний -згрупований звіт продуктивності Vitest, дозволяє Codex вносити лише невеликі -зміни продуктивності тестів без втрати покриття замість широких рефакторингів, -потім повторно запускає повний звіт і відхиляє зміни, які зменшують -кількість тестів, що проходять, відносно базового рівня. Якщо в базовому стані є тести зі збоями, -Codex може виправляти лише очевидні збої, а повний звіт після роботи агента -має пройти успішно, перш ніж щось буде закомічено. Якщо `main` просувається далі до того, як -бот зможе запушити зміни, доріжка перебазовує перевірений патч, повторно запускає `pnpm check:changed` -і повторює спробу пушу; застарілі патчі з конфліктами пропускаються. Вона використовує -GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму безпечну модель без `sudo`, -що й docs agent. +Workflow `Test Performance Agent` — це керована подіями лінія обслуговування Codex +для повільних тестів. Вона не має окремого запуску за розкладом: +її може запустити успішний неблокований ботом CI run на `main`, але вона пропускається, якщо +інший виклик через workflow-run уже виконувався або виконується в той самий день UTC. +Ручний запуск обходить це денне обмеження активності. Лінія збирає повний згрупований звіт продуктивності Vitest, +дозволяє Codex вносити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, +потім повторно запускає повний звіт і відхиляє зміни, що зменшують +кількість тестів базового рівня, які проходять. Якщо в базовому стані є тести, що падають, Codex +може виправляти лише очевидні збої, і повний звіт після роботи агента має успішно пройти, перш ніж +щось буде закомічено. Коли `main` просувається далі до того, як bot push потрапить у гілку, +лінія перебазовує перевірений патч, повторно запускає `pnpm check:changed` і повторює push; +застарілі патчі з конфліктами пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex +могла зберігати ту саму безпечну політику drop-sudo, що й агент документації. ```bash gh workflow run duplicate-after-merge.yml \ @@ -65,88 +62,88 @@ gh workflow run duplicate-after-merge.yml \ ## Огляд завдань -| Завдання | Призначення | Коли запускається | -| -------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------ | -| `preflight` | Виявлення змін лише в документації, змінених областей, змінених розширень і побудова CI manifest | Завжди для недрафтових пушів і PR | -| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для недрафтових пушів і PR | -| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisory з npm | Завжди для недрафтових пушів і PR | -| `security-fast` | Обов’язковий агрегатор для швидких завдань безпеки | Завжди для недрафтових пушів і PR | -| `build-artifacts` | Збірка `dist/`, Control UI, перевірки зібраних артефактів і повторно використовувані артефакти нижчих етапів | Зміни, пов’язані з Node | -| `checks-fast-core` | Швидкі доріжки коректності Linux, як-от перевірки bundled/plugin-contract/protocol | Зміни, пов’язані з Node | -| `checks-fast-contracts-channels` | Шардовані перевірки контрактів каналів зі стабільним агрегованим результатом | Зміни, пов’язані з Node | -| `checks-node-extensions` | Повні шардовані тести bundled-plugin для всього набору розширень | Зміни, пов’язані з Node | -| `checks-node-core-test` | Шардовані основні тести Node, за винятком доріжок channel, bundled, contract та extension | Зміни, пов’язані з Node | -| `extension-fast` | Цільові тести лише для змінених bundled plugins | Pull request зі змінами в розширеннях | -| `check` | Шардований еквівалент основної локальної перевірки: production types, lint, guards, test types і strict smoke | Зміни, пов’язані з Node | -| `check-additional` | Шарди для architecture, boundary, guards поверхні extension, package-boundary і gateway-watch | Зміни, пов’язані з Node | -| `build-smoke` | Smoke-тести зібраного CLI і smoke-перевірка пам’яті під час запуску | Зміни, пов’язані з Node | -| `checks` | Верифікатор для channel-тестів зібраних артефактів плюс сумісність Node 22 лише для push | Зміни, пов’язані з Node | -| `check-docs` | Перевірки форматування документації, lint і зламаних посилань | Документацію змінено | -| `skills-python` | Ruff + pytest для Skills на основі Python | Зміни, пов’язані з Python Skills | -| `checks-windows` | Специфічні для Windows доріжки тестування | Зміни, пов’язані з Windows | -| `macos-node` | Доріжка тестів TypeScript на macOS із використанням спільних зібраних артефактів | Зміни, пов’язані з macOS | -| `macos-swift` | Swift lint, збірка і тести для застосунку macOS | Зміни, пов’язані з macOS | -| `android` | Модульні тести Android для обох варіантів плюс одна збірка debug APK | Зміни, пов’язані з Android | -| `test-performance-agent` | Щоденна оптимізація повільних тестів через Codex після довіреної активності | Успіх CI в main або ручний запуск | +| Завдання | Призначення | Коли запускається | +| --------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------ | +| `preflight` | Виявлення змін лише в документації, змінених областей, змінених extensions і побудова CI manifest | Завжди для non-draft push і PR | +| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для non-draft push і PR | +| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisories npm | Завжди для non-draft push і PR | +| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для non-draft push і PR | +| `build-artifacts` | Збирання `dist/`, Control UI, перевірки built-artifact і повторно використовувані downstream artifacts | Зміни, релевантні для Node | +| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от перевірки bundled/plugin-contract/protocol | Зміни, релевантні для Node | +| `checks-fast-contracts-channels` | Шардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node | +| `checks-node-extensions` | Повні шардовані тести bundled-plugin по всьому набору extension | Зміни, релевантні для Node | +| `checks-node-core-test` | Шардовані тести core Node, окрім ліній каналів, bundled, контрактів і extensions | Зміни, релевантні для Node | +| `extension-fast` | Цільові тести лише для змінених bundled plugins | Pull request із змінами в extension | +| `check` | Шардований еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Зміни, релевантні для Node | +| `check-additional` | Шарди архітектури, меж, guards поверхні extension, package-boundary і gateway-watch | Зміни, релевантні для Node | +| `build-smoke` | Smoke-тести зібраного CLI і smoke-тест пам’яті під час запуску | Зміни, релевантні для Node | +| `checks` | Верифікатор для built-artifact тестів каналів плюс сумісність Node 22 лише для push | Зміни, релевантні для Node | +| `check-docs` | Форматування документації, lint і перевірки на зламані посилання | Документацію змінено | +| `skills-python` | Ruff + pytest для Skills на базі Python | Зміни, релевантні для Python Skills | +| `checks-windows` | Специфічні для Windows тестові лінії | Зміни, релевантні для Windows | +| `macos-node` | Лінія тестів TypeScript на macOS із використанням спільних зібраних artifacts | Зміни, релевантні для macOS | +| `macos-swift` | Swift lint, build і тести для застосунку macOS | Зміни, релевантні для macOS | +| `android` | Android unit-тести для обох flavor плюс одна debug APK build | Зміни, релевантні для Android | +| `test-performance-agent` | Щоденна Codex-оптимізація повільних тестів після довіреної активності | Успіх main CI або ручний запуск | -## Порядок швидкого завершення при збої +## Порядок fail-fast -Завдання впорядковано так, щоб дешеві перевірки завершувалися зі збоєм раніше, ніж запустяться дорогі: +Завдання впорядковані так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запустяться дорогі: -1. `preflight` вирішує, які доріжки взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання. -2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються при збої, не очікуючи важчих матричних завдань для артефактів і платформ. -3. `build-artifacts` виконується паралельно зі швидкими доріжками Linux, щоб залежні споживачі могли стартувати одразу, щойно спільна збірка буде готова. -4. Після цього розгалужуються важчі платформні та runtime-доріжки: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, PR-only `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +1. `preflight` визначає, які лінії взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою без очікування важчих завдань матриці artifacts і платформ. +3. `build-artifacts` виконується паралельно зі швидкими Linux-лініями, щоб downstream-споживачі могли стартувати, щойно буде готова спільна збірка. +4. Після цього розпаралелюються важчі платформні та runtime-лінії: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, лише для PR `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. -Логіка обмеження за областю змін міститься в `scripts/ci-changed-scope.mjs` і покривається модульними тестами в `src/scripts/ci-changed-scope.test.ts`. -Зміни в CI workflow перевіряють граф Node CI разом із linting для workflow, але самі по собі не примушують запускати нативні збірки для Windows, Android або macOS; ці платформні доріжки, як і раніше, обмежуються змінами у вихідних кодах відповідних платформ. -Зміни лише в маршрутизації CI, вибрані дешеві зміни у фікстурах core-test і вузькі зміни в helper/test-routing для контрактів плагінів використовують швидкий шлях manifest лише для Node: preflight, security і одне завдання `checks-fast-core`. Цей шлях уникає build artifacts, сумісності з Node 22, контрактів каналів, повних шардів core, шардів bundled-plugin і додаткових матриць guard, коли змінені файли обмежуються поверхнями маршрутизації або helper, які швидке завдання перевіряє безпосередньо. -Перевірки Windows Node обмежуються специфічними для Windows обгортками process/path, helper для npm/pnpm/UI runner, конфігурацією package manager і поверхнями CI workflow, які запускають цю доріжку; не пов’язані зміни у вихідному коді, плагінах, install-smoke і зміни лише в тестах залишаються на Linux Node доріжках, щоб не резервувати 16-vCPU Windows worker для покриття, яке вже перевіряється звичайними test shards. -Окремий workflow `install-smoke` повторно використовує той самий скрипт обмеження через власне завдання `preflight`. Він ділить smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. Pull request запускають швидкий шлях для поверхонь Docker/package, змін package/manifest bundled plugin і поверхонь core plugin/channel/gateway/Plugin SDK, які використовують Docker smoke jobs. Зміни лише у вихідному коді bundled plugin, зміни лише в тестах і зміни лише в документації не резервують Docker workers. Швидкий шлях один раз збирає root Dockerfile image, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє аргумент збірки bundled extension і запускає обмежений профіль Docker для bundled-plugin із сукупним timeout команди 240 секунд, де кожен сценарій `docker run` окремо обмежений. Повний шлях зберігає QR package install і покриття installer Docker/update для нічних запусків за розкладом, ручних запусків, перевірок релізів через workflow-call і pull request, які справді торкаються поверхонь installer/package/Docker. Пуші в `main`, включно з merge commits, не примушують запускати повний шлях; коли логіка changed-scope запитує повне покриття для push, workflow залишає швидкий Docker smoke, а повний install smoke відкладає до нічної або релізної перевірки. Повільний smoke для image-provider із глобальним встановленням Bun окремо керується через `run_bun_global_install_smoke`; він запускається за нічним розкладом і з workflow перевірок релізу, а ручні запуски `install-smoke` можуть увімкнути його окремо, але pull request і пуші в `main` його не запускають. QR і installer Docker тести зберігають власні Dockerfile, орієнтовані на встановлення. Локальний `test:docker:all` попередньо збирає один спільний live-test image і один спільний built-app image з `scripts/e2e/Dockerfile`, а потім запускає live/E2E smoke lanes із ваговим планувальником і `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте типову кількість слотів основного пулу — 10 — через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а кількість слотів tail-пулу, чутливого до provider, — теж 10 — через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Обмеження для важких доріжок за замовчуванням: `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=6`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=8` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб доріжки npm install і multi-service не перевантажували Docker, поки легші доріжки все ще займають доступні слоти. Запуск доріжок за замовчуванням розноситься на 2 секунди, щоб уникнути локальних сплесків створення контейнерів у Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний агрегований запуск попередньо перевіряє Docker, видаляє застарілі OpenClaw E2E контейнери, виводить статус активних доріжок, зберігає таймінги доріжок для впорядкування за принципом «найдовші спочатку» і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для перевірки планувальника. За замовчуванням він припиняє планувати нові pooled lanes після першого збою, і кожна доріжка має резервний timeout у 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; для вибраних live/tail lanes використовуються жорсткіші індивідуальні обмеження. Повторно використовуваний live/E2E workflow віддзеркалює шаблон зі спільним image, збираючи й публікуючи один SHA-tagged GHCR Docker E2E image перед Docker matrix, а потім запускає матрицю з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Запланований live/E2E workflow щодня запускає повний Docker suite для шляху релізу. Матриця bundled update поділена за цільовим оновленням, щоб повторні проходи npm update і doctor repair можна було шардити разом з іншими bundled checks. +Логіка області дії міститься в `scripts/ci-changed-scope.mjs` і покривається unit-тестами в `src/scripts/ci-changed-scope.test.ts`. +Редагування CI workflow перевіряють граф Node CI разом із linting workflow, але самі по собі не примушують запускати нативні збірки Windows, Android або macOS; ці платформні лінії й надалі обмежуються змінами в платформному вихідному коді. +Редагування лише маршрутизації CI, вибрані дешеві зміни у фікстурах core-тестів і вузькі зміни в helper/test-routing для контрактів plugin використовують швидкий шлях manifest лише для Node: preflight, security і єдине завдання `checks-fast-core`. Цей шлях уникає build artifacts, сумісності з Node 22, контрактів каналів, повних shard-ів core, shard-ів bundled-plugin і додаткових матриць guard, коли змінені файли обмежені лише поверхнями маршрутизації або helper, які швидке завдання перевіряє безпосередньо. +Windows Node checks обмежені специфічними для Windows обгортками process/path, helper-ами npm/pnpm/UI runner, конфігурацією package manager і поверхнями CI workflow, що виконують цю лінію; не пов’язані зміни в source, plugin, install-smoke і test-only залишаються на Linux Node lanes, щоб не резервувати Windows worker із 16 vCPU для покриття, яке вже перевіряється звичайними test shards. +Окремий workflow `install-smoke` повторно використовує той самий scope-скрипт через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. Pull request запускають швидкий шлях для поверхонь Docker/package, змін package/manifest bundled plugin, а також поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише у source bundled plugin, test-only edits і docs-only edits не резервують Docker workers. Швидкий шлях один раз збирає образ root Dockerfile, перевіряє CLI, запускає CLI smoke `agents delete shared-workspace`, запускає container gateway-network e2e, перевіряє build arg для bundled extension і запускає обмежений Docker profile bundled-plugin під агрегованим таймаутом команди в 240 секунд, де кожен Docker run сценарію окремо має власне обмеження. Повний шлях зберігає покриття QR package install і installer Docker/update для нічних запусків за розкладом, ручних запусків, workflow-call release checks і pull request, які справді зачіпають installer/package/Docker поверхні. Push до `main`, включно з merge commits, не примушують повний шлях; коли логіка changed-scope на push запитує повне покриття, workflow залишає швидкий Docker smoke і переносить повний install smoke на нічну або релізну перевірку. Повільний smoke Bun global install image-provider окремо керується через `run_bun_global_install_smoke`; він запускається за нічним розкладом і з workflow release checks, а ручні запуски `install-smoke` можуть явно його ввімкнути, але pull request і push до `main` його не запускають. Тести QR та installer Docker зберігають власні Dockerfile, орієнтовані на встановлення. Локальний `test:docker:all` попередньо збирає один спільний live-test image і один спільний built-app image з `scripts/e2e/Dockerfile`, а потім запускає live/E2E smoke lanes із weighted scheduler і `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте типову кількість слотів основного пулу 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а кількість слотів tail-пулу, чутливого до provider, також 10 — через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Обмеження важких ліній за замовчуванням становлять `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=6`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=8` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб лінії npm install і multi-service не перевантажували Docker, поки легші лінії все ще займають доступні слоти. Запуски ліній за замовчуванням зсуваються на 2 секунди, щоб уникати локальних штормів створення в Docker daemon; змінюйте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний агрегат спочатку перевіряє Docker, видаляє застарілі контейнери OpenClaw E2E, виводить статус активних ліній, зберігає таймінги ліній для впорядкування від найдовших до найкоротших і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для перевірки scheduler. За замовчуванням він припиняє планувати нові pooled lanes після першої помилки, і кожна лінія має резервний таймаут 120 хвилин, який можна змінити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; окремі live/tail lanes використовують жорсткіші індивідуальні обмеження. Повторно використовуваний workflow live/E2E збирає й публікує один Docker E2E image у GHCR із SHA-тегом, а потім запускає Docker suite релізного шляху максимум у трьох chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk один раз витягнув спільний image і виконав кілька ліній. Коли для suite релізного шляху запитується Open WebUI, він запускається всередині chunk plugins/integrations замість резервування четвертого Docker worker; Open WebUI зберігає окреме завдання лише для запусків openwebui-only. Запланований workflow live/E2E щодня запускає повний Docker suite релізного шляху. Матриця bundled update розділена за цільовим оновленням, щоб повторні проходи npm update і doctor repair могли шардитися разом з іншими bundled checks. -Логіка локальних changed-lanes міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Ця локальна перевірка суворіша щодо архітектурних меж, ніж широке CI-обмеження платформ: зміни core production запускають typecheck для core prod разом із core tests, зміни лише в core tests запускають лише typecheck/tests для core test, зміни extension production запускають typecheck для extension prod разом із extension tests, а зміни лише в extension tests запускають лише typecheck/tests для extension test. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку до extension, тому що розширення залежать від цих core-контрактів. Зміни лише в release metadata з оновленням версій запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config переходять у безпечний режим і запускають усі доріжки. +Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний gate суворіший щодо архітектурних меж, ніж широка платформна область CI: зміни у production core запускають typecheck production core плюс core-тести, зміни лише в core test запускають лише typecheck/tests для core test, зміни у production extension запускають typecheck production extension плюс extension-тести, а зміни лише в extension test запускають лише typecheck/tests для extension test. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку до extension, оскільки extensions залежать від цих контрактів core. Підвищення версій лише в release metadata запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config безпечно переводять перевірку на всі лінії. -Для push матриця `checks` додає доріжку `compat-node22`, що запускається лише для push. Для pull request ця доріжка пропускається, і матриця лишається зосередженою на звичайних test/channel lanes. +На push матриця `checks` додає лінію `compat-node22`, яка запускається лише на push. У pull request цю лінію пропускають, і матриця зосереджується на звичайних test/channel lanes. -Найповільніші сімейства Node-тестів поділені або збалансовані так, щоб кожне завдання залишалося невеликим без надмірного резервування runner-ів: контракти каналів запускаються як три вагово збалансовані шарди, тести bundled plugin балансуються між шістьма worker-ами для розширень, невеликі core unit lanes поєднуються попарно, auto-reply працює на чотирьох збалансованих worker-ах із розділенням піддерева reply на шарди agent-runner, dispatch і commands/state-routing, а agentic gateway/plugin configs розподіляються по наявних source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin тести використовують власні конфігурації Vitest замість спільного універсального набору для плагінів. Extension shard jobs запускають до двох груп конфігурацій плагінів одночасно з одним Vitest worker на групу та більшим heap для Node, щоб пакетні набори плагінів із важкими import не створювали зайвих CI jobs. Широка доріжка agents використовує спільний планувальник паралельності файлів Vitest, оскільки в ній домінують import/планування, а не один повільний тестовий файл. `runtime-config` запускається разом із shard `infra core-runtime`, щоб спільний runtime shard не ставав хвостовим. Include-pattern shards записують дані про таймінг, використовуючи ім’я CI shard, тож `.artifacts/vitest-shard-timings.json` може розрізняти цілу конфігурацію і фільтрований shard. `check-additional` тримає package-boundary compile/canary роботу разом і відокремлює архітектуру runtime topology від покриття gateway watch; shard boundary guard запускає свої невеликі незалежні guard паралельно в межах одного завдання. Gateway watch, channel tests і shard support-boundary для core виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи їхні попередні імена перевірок як полегшені verifier jobs і водночас уникаючи двох додаткових Blacksmith worker-ів і другої черги споживачів артефактів. -Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Для third-party flavor немає окремого source set або manifest; його доріжка модульних тестів усе одно компілює цей flavor з прапорцями BuildConfig для SMS/call-log, водночас уникаючи дублювання завдання пакування debug APK на кожен Android-релевантний push. -`extension-fast` працює лише для PR, тому що push-запуски вже виконують повні shard-и bundled plugin. Це зберігає швидкий зворотний зв’язок для review змінених плагінів, не резервуючи зайвий Blacksmith worker у `main` для покриття, яке вже є в `checks-node-extensions`. +Найповільніші сімейства Node-тестів розділено або збалансовано так, щоб кожне завдання залишалося невеликим без надмірного резервування runner-ів: channel contracts запускаються як три зважені shard-и, bundled plugin tests балансуються між шістьма worker-ами extension, невеликі core unit lanes об’єднуються в пари, auto-reply виконується на чотирьох збалансованих worker-ах із розбиттям subtree reply на shard-и agent-runner, dispatch і commands/state-routing, а конфігурації agentic gateway/plugin розподіляються по наявних source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої окремі конфігурації Vitest замість спільного catch-all для plugin. Завдання shard extension запускають до двох груп конфігурацій plugin одночасно з одним Vitest worker на групу і збільшеним heap Node, щоб важкі за імпортами пакети plugin не створювали додаткових CI jobs. Широка agents lane використовує спільний scheduler паралельності файлів Vitest, оскільки в ній домінують імпорти/планування, а не один повільний тестовий файл. `runtime-config` запускається разом із shard-ом infra core-runtime, щоб спільний runtime shard не залишався останнім. Шарди з include-pattern записують таймінги, використовуючи назву CI shard, тому `.artifacts/vitest-shard-timings.json` може відрізняти цілу конфігурацію від фільтрованого shard-а. `check-additional` тримає разом compile/canary-роботи package-boundary і відокремлює архітектуру топології runtime від покриття gateway watch; shard boundary guard виконує свої невеликі незалежні guard-ів паралельно всередині одного завдання. Gateway watch, channel tests і shard меж core support виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрано, зберігаючи свої старі назви перевірок як легкі verifier-завдання й уникаючи двох додаткових Blacksmith worker-ів та другої черги споживачів artifacts. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає debug APK для Play. Flavor third-party не має окремого source set або manifest; його лінія unit-тестів усе одно компілює цей flavor із прапорцями BuildConfig для SMS/call-log, при цьому уникаючи дубльованого пакування debug APK на кожен Android-релевантний push. +`extension-fast` є лише для PR, тому що push-запуски вже виконують повні shard-и bundled plugin. Це зберігає швидкий зворотний зв’язок для review щодо змінених plugin, не резервуючи додатковий Blacksmith worker на `main` для покриття, яке вже є в `checks-node-extensions`. -GitHub може позначати витіснені новішими jobs як `cancelled`, коли новий push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо тільки найновіший запуск для того самого ref також не завершується збоєм. Агреговані shard-перевірки використовують `!cancelled() && always()`, тож вони все одно повідомляють про звичайні збої shard-ів, але не стають у чергу після того, як увесь workflow уже був витіснений. -Ключ конкурентності CI має версію (`CI-v7-*`), щоб zombie-процес у старій групі черги на стороні GitHub не міг безстроково блокувати нові запуски в main. +GitHub може позначати витіснені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо лише найновіший запуск для того самого ref також не падає. Агреговані shard checks використовують `!cancelled() && always()`, тож вони все одно повідомляють про звичайні збої shard-ів, але не стають у чергу після того, як увесь workflow уже було витіснено. +Ключ concurrency для CI має версіонування (`CI-v7-*`), тому zombie-процес на боці GitHub у старій групі черги не може безстроково блокувати новіші запуски main. -## Runners +## Runner-и -| Runner | Завдання | -| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки контрактів каналів, шарди `check`, окрім lint, шарди й агрегати `check-additional`, агреговані верифікатори Node-тестів, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла ставати в чергу раніше | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди Linux Node-тестів, шарди тестів bundled plugin, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який і далі достатньо чутливий до CPU, тож 8 vCPU коштували дорожче, ніж давали вигоди; Docker-збірки install-smoke, де час очікування в черзі для 32-vCPU коштував дорожче, ніж давав вигоди | -| `blacksmith-16vcpu-windows-2025` | `checks-windows` | -| `blacksmith-6vcpu-macos-latest` | `macos-node` у `openclaw/openclaw`; для fork використовується `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; для fork використовується `macos-latest` | +| Runner | Завдання | +| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки контрактів каналів, shard-и `check`, окрім lint, shard-и та агрегати `check-additional`, агреговані верифікатори Node-тестів, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла ставати в чергу раніше | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shard-и Linux Node-тестів, shard-и тестів bundled plugin, `android` | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який і далі достатньо чутливий до CPU, тож 8 vCPU коштували дорожче, ніж заощаджували; Docker-збірки install-smoke, де час очікування в черзі для 32 vCPU коштував дорожче, ніж давав вигоду | +| `blacksmith-16vcpu-windows-2025` | `checks-windows` | +| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; fork-и повертаються до `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; fork-и повертаються до `macos-latest` | ## Локальні еквіваленти ```bash pnpm changed:lanes # перевірити локальний класифікатор changed-lane для origin/main...HEAD -pnpm check:changed # розумна локальна перевірка: changed typecheck/lint/tests за boundary lane -pnpm check # швидка локальна перевірка: production tsgo + шардований lint + паралельні швидкі guard +pnpm check:changed # розумний локальний gate: changed typecheck/lint/tests за lane меж +pnpm check # швидкий локальний gate: production tsgo + sharded lint + parallel fast guards pnpm check:test-types -pnpm check:timed # та сама перевірка з таймінгами для кожного етапу +pnpm check:timed # той самий gate із таймінгами по кожному етапу pnpm build:strict-smoke pnpm check:architecture pnpm test:gateway:watch-regression pnpm test # тести vitest pnpm test:channels pnpm test:contracts:channels -pnpm check:docs # форматування документації + lint + зламані посилання -pnpm build # збірка dist, коли важливі доріжки CI artifact/build-smoke -pnpm ci:timings # зведення для останнього запуску CI push у origin/main -pnpm ci:timings:recent # порівняння останніх успішних запусків CI у main -node scripts/ci-run-timings.mjs # зведення wall time, queue time і найповільніших завдань +pnpm check:docs # docs format + lint + broken links +pnpm build # зібрати dist, коли важливі CI-лінії artifact/build-smoke +pnpm ci:timings # підсумувати останній push CI run для origin/main +pnpm ci:timings:recent # порівняти нещодавні успішні main CI runs +node scripts/ci-run-timings.mjs # підсумувати wall time, queue time і найповільніші завдання node scripts/ci-run-timings.mjs --latest-main # ігнорувати шум issue/comment і вибрати push CI для origin/main -node scripts/ci-run-timings.mjs --recent 10 # порівняти останні успішні запуски CI у main +node scripts/ci-run-timings.mjs --recent 10 # порівняти нещодавні успішні main CI runs pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json ``` diff --git a/docs/uk/plugins/codex-harness.md b/docs/uk/plugins/codex-harness.md index 88e4e96fa..1792d9da1 100644 --- a/docs/uk/plugins/codex-harness.md +++ b/docs/uk/plugins/codex-harness.md @@ -1,198 +1,194 @@ --- read_when: - - Ви хочете використовувати вбудований harness app-server Codex - - Вам потрібні приклади конфігурації harness Codex - - Ви хочете, щоб розгортання лише з Codex завершувалися помилкою замість переходу до Pi -summary: Запускайте вбудовані ходи агентів OpenClaw через вбудований harness app-server Codex -title: Harness Codex + - Ви хочете використовувати вбудований каркас app-server Codex + - Вам потрібні приклади конфігурації каркаса Codex + - Ви хочете, щоб розгортання лише з Codex завершувалися з помилкою замість переходу на Pi +summary: Запустіть вбудовані ходи агента OpenClaw через вбудований каркас app-server Codex +title: каркас Codex x-i18n: - generated_at: "2026-04-26T07:49:39Z" + generated_at: "2026-04-26T20:28:20Z" model: gpt-5.4 provider: openai - source_hash: bf54ee2eab64e611e50605e8fef24cc840b3246d0bddc18ae03730a05848e271 + source_hash: 57c0d66c3ce0cdb26ffd2e6637c1494908c563f4c9750b20a9b33b6bc7810e1b source_path: plugins/codex-harness.md workflow: 15 --- -Вбудований Plugin `codex` дає OpenClaw змогу запускати вбудовані ходи агентів через -app-server Codex замість вбудованого harness Pi. +Вбудований Plugin `codex` дає OpenClaw змогу запускати вбудовані ходи агента через +app-server Codex замість вбудованого каркаса Pi. Використовуйте це, коли хочете, щоб Codex керував низькорівневою сесією агента: виявленням -моделей, нативним відновленням гілок, нативною Compaction і виконанням app-server. -OpenClaw і далі керує каналами чату, файлами сесій, вибором моделей, інструментами, +моделей, нативним відновленням потоків, нативним Compaction і виконанням через app-server. +OpenClaw, як і раніше, керує каналами чату, файлами сесій, вибором моделі, інструментами, погодженнями, доставленням медіа та видимим дзеркалом транскрипту. -Якщо ви лише орієнтуєтеся в темі, почніть із -[Середовища виконання агентів](/uk/concepts/agent-runtimes). Коротка версія: -`openai/gpt-5.5` — це посилання на модель, `codex` — це середовище виконання, а Telegram, -Discord, Slack або інший канал залишається поверхнею комунікації. +Якщо ви намагаєтеся зорієнтуватися, почніть з +[середовищ виконання агентів](/uk/concepts/agent-runtimes). Коротко: +`openai/gpt-5.5` — це посилання моделі, `codex` — це середовище виконання, а Telegram, +Discord, Slack або інший канал лишається поверхнею комунікації. ## Що змінює цей Plugin Вбудований Plugin `codex` додає кілька окремих можливостей: -| Capability | Як це використовувати | Що це робить | -| --------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------- | -| Нативне вбудоване середовище виконання | `agentRuntime.id: "codex"` | Запускає вбудовані ходи агентів OpenClaw через app-server Codex. | -| Нативні команди керування чатом | `/codex bind`, `/codex resume`, `/codex steer`, ... | Прив’язує та керує гілками app-server Codex із розмови в месенджері. | -| Провайдер/каталог app-server Codex | внутрішні механізми `codex`, доступні через harness | Дає середовищу виконання змогу виявляти та перевіряти моделі app-server. | -| Шлях розуміння медіа Codex | шляхи сумісності моделей зображень `codex/*` | Запускає обмежені ходи app-server Codex для підтримуваних моделей розуміння зображень. | -| Нативна передача hooks | Hooks Plugin-а навколо нативних подій Codex | Дає OpenClaw змогу спостерігати/блокувати підтримувані нативні події інструментів/фіналізації Codex. | +| Можливість | Як її використовувати | Що вона робить | +| ------------------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------- | +| Нативне вбудоване середовище виконання | `agentRuntime.id: "codex"` | Запускає вбудовані ходи агента OpenClaw через app-server Codex. | +| Нативні команди керування чатом | `/codex bind`, `/codex resume`, `/codex steer`, ... | Прив’язує та керує потоками app-server Codex із розмови в повідомленнях. | +| Провайдер/каталог app-server Codex | внутрішні механізми `codex`, доступні через каркас | Дає змогу середовищу виконання виявляти й перевіряти моделі app-server. | +| Шлях розуміння медіа Codex | шляхи сумісності моделей зображень `codex/*` | Запускає обмежені ходи app-server Codex для підтримуваних моделей розуміння зображень. | +| Нативна ретрансляція хуків | Хуки Plugin навколо нативних подій Codex | Дає змогу OpenClaw спостерігати/блокувати підтримувані нативні події інструментів/фіналізації Codex. | -Увімкнення Plugin-а робить ці можливості доступними. Воно **не**: +Увімкнення Plugin робить ці можливості доступними. Воно **не**: -- починає використовувати Codex для кожної моделі OpenAI -- перетворює посилання на моделі `openai-codex/*` на нативне середовище виконання -- робить ACP/acpx типовим шляхом Codex +- не починає використовувати Codex для кожної моделі OpenAI +- не перетворює посилання моделей `openai-codex/*` на нативне середовище виконання +- не робить ACP/acpx типовим шляхом Codex - не перемикає на льоту наявні сесії, у яких уже зафіксовано середовище виконання Pi -- не замінює доставлення каналів OpenClaw, файли сесій, сховище auth-profile або +- не замінює доставлення через канали OpenClaw, файли сесій, сховище профілів автентифікації чи маршрутизацію повідомлень -Той самий Plugin також відповідає за нативну поверхню команд керування чатом `/codex`. Якщо -Plugin увімкнено й користувач просить прив’язати, відновити, спрямувати, зупинити або переглянути -гілки Codex із чату, агентам слід віддавати перевагу `/codex ...` замість ACP. ACP залишається -явним резервним варіантом, коли користувач просить ACP/acpx або тестує адаптер ACP -Codex. +Той самий Plugin також керує нативною поверхнею команд керування чатом `/codex`. Якщо +Plugin увімкнено і користувач просить прив’язати, відновити, спрямувати, зупинити або перевірити +потоки Codex із чату, агенти мають віддавати перевагу `/codex ...` замість ACP. ACP лишається +явним запасним варіантом, коли користувач просить ACP/acpx або тестує адаптер ACP Codex. -Нативні ходи Codex зберігають hooks Plugin-ів OpenClaw як публічний шар сумісності. -Це внутрішньопроцесні hooks OpenClaw, а не командні hooks Codex `hooks.json`: +Нативні ходи Codex зберігають хуки Plugin OpenClaw як публічний шар сумісності. +Це внутрішньопроцесні хуки OpenClaw, а не командні хуки Codex `hooks.json`: - `before_prompt_build` - `before_compaction`, `after_compaction` - `llm_input`, `llm_output` - `before_tool_call`, `after_tool_call` - `before_message_write` для дзеркальних записів транскрипту -- `before_agent_finalize` через реле `Stop` Codex +- `before_agent_finalize` через ретрансляцію Codex `Stop` - `agent_end` -Plugin-и також можуть реєструвати нейтральне до середовища виконання middleware результатів інструментів, щоб переписувати результати динамічних інструментів OpenClaw після того, як OpenClaw виконає інструмент, і до того, як результат буде повернуто до Codex. Це окремо від публічного -hook-а Plugin-а `tool_result_persist`, який трансформує записи результатів інструментів у транскрипті, що належить OpenClaw. +Plugins також можуть реєструвати нейтральне до середовища виконання проміжне ПЗ результатів інструментів, щоб переписувати результати динамічних інструментів OpenClaw після того, як OpenClaw виконає інструмент, і до того, як результат буде повернено в Codex. Це окремо від публічного +хука Plugin `tool_result_persist`, який перетворює записи результатів інструментів у транскрипті, якими володіє OpenClaw. -Про саму семантику hooks Plugin-ів див. [Hooks Plugin-ів](/uk/plugins/hooks) -і [Поведінка guard Plugin-а](/uk/tools/plugin). +Докладніше про семантику самих хуків Plugin див. [Хуки Plugin](/uk/plugins/hooks) +і [Поведінка захисту Plugin](/uk/tools/plugin). -Harness вимкнено за замовчуванням. У нових конфігураціях слід зберігати посилання на моделі OpenAI -канонічними у вигляді `openai/gpt-*` і явно примусово задавати +Каркас вимкнений типово. Нові конфігурації мають зберігати канонічні посилання моделей OpenAI +у вигляді `openai/gpt-*` і явно примусово вказувати `agentRuntime.id: "codex"` або `OPENCLAW_AGENT_RUNTIME=codex`, коли -потрібне нативне виконання через app-server. Застарілі посилання `codex/*` і далі автоматично вибирають -harness для сумісності, але застарілі префікси провайдерів, підкріплені середовищем виконання, -не показуються як звичайні варіанти моделі/провайдера. +потрібне нативне виконання через app-server. Застарілі посилання моделей `codex/*` і далі автоматично вибирають +каркас для сумісності, але застарілі префікси провайдерів, підкріплені середовищем виконання, не показуються як звичайні варіанти моделі/провайдера. -Якщо Plugin `codex` увімкнено, але основна модель усе ще -`openai-codex/*`, `openclaw doctor` попереджає замість зміни маршруту. Це -навмисно: `openai-codex/*` і далі залишається шляхом OAuth/підписки PI Codex, а -нативне виконання через app-server залишається явним вибором середовища виконання. +Якщо Plugin `codex` увімкнено, але основною моделлю все ще є +`openai-codex/*`, `openclaw doctor` показує попередження замість зміни маршруту. Це +навмисно: `openai-codex/*` лишається шляхом OAuth/підписки Codex через Pi, а +нативне виконання через app-server лишається явним вибором середовища виконання. ## Карта маршрутів -Скористайтеся цією таблицею перед зміною конфігурації: +Користуйтеся цією таблицею перед зміною конфігурації: -| Бажана поведінка | Посилання на модель | Конфігурація середовища виконання | Вимога до Plugin-а | Очікувана мітка стану | -| ------------------------------------------ | -------------------------- | -------------------------------------- | -------------------------- | ------------------------------ | -| API OpenAI через звичайний раннер OpenClaw | `openai/gpt-*` | пропущено або `runtime: "pi"` | Провайдер OpenAI | `Runtime: OpenClaw Pi Default` | -| OAuth/підписка Codex через PI | `openai-codex/gpt-*` | пропущено або `runtime: "pi"` | Провайдер OAuth OpenAI Codex | `Runtime: OpenClaw Pi Default` | -| Нативні вбудовані ходи app-server Codex | `openai/gpt-*` | `agentRuntime.id: "codex"` | Plugin `codex` | `Runtime: OpenAI Codex` | -| Змішані провайдери з консервативним авто-режимом | посилання провайдерів | `agentRuntime.id: "auto"` | Необов’язкові середовища виконання Plugin-ів | Залежить від вибраного середовища виконання | -| Явна сесія адаптера ACP Codex | залежить від підказки/моделі ACP | `sessions_spawn` з `runtime: "acp"` | справний бекенд `acpx` | Стан завдання/сесії ACP | +| Бажана поведінка | Посилання моделі | Конфігурація середовища виконання | Вимога до Plugin | Очікувана мітка стану | +| ------------------------------------------ | -------------------------- | -------------------------------------- | ------------------------- | ------------------------------ | +| API OpenAI через звичайний виконавець OpenClaw | `openai/gpt-*` | пропущено або `runtime: "pi"` | Провайдер OpenAI | `Runtime: OpenClaw Pi Default` | +| OAuth/підписка Codex через Pi | `openai-codex/gpt-*` | пропущено або `runtime: "pi"` | Провайдер OpenAI Codex OAuth | `Runtime: OpenClaw Pi Default` | +| Нативні вбудовані ходи app-server Codex | `openai/gpt-*` | `agentRuntime.id: "codex"` | Plugin `codex` | `Runtime: OpenAI Codex` | +| Змішані провайдери з консервативним автоматичним режимом | посилання, специфічні для провайдера | `agentRuntime.id: "auto"` | Необов’язкові середовища виконання Plugin | Залежить від вибраного середовища виконання | +| Явна сесія адаптера ACP Codex | залежить від запиту/моделі ACP | `sessions_spawn` з `runtime: "acp"` | справний бекенд `acpx` | Стан задачі/сесії ACP | -Важливе розділення тут — провайдер проти середовища виконання: +Важливе розділення — провайдер проти середовища виконання: -- `openai-codex/*` відповідає на питання «який маршрут провайдера/автентифікації має використовувати PI?» -- `agentRuntime.id: "codex"` відповідає на питання «який цикл має виконувати цей +- `openai-codex/*` відповідає на запитання: «який маршрут провайдера/автентифікації має використовувати Pi?» +- `agentRuntime.id: "codex"` відповідає на запитання: «який цикл має виконувати цей вбудований хід?» -- `/codex ...` відповідає на питання «до якої нативної розмови Codex має бути прив’язано цей чат - або чим він має керувати?» -- ACP відповідає на питання «який зовнішній процес harness має запускати acpx?» +- `/codex ...` відповідає на запитання: «до якої нативної розмови Codex має бути прив’язано цей чат + або якою розмовою треба керувати?» +- ACP відповідає на запитання: «який зовнішній процес каркаса має запускати acpx?» ## Виберіть правильний префікс моделі -Маршрути сімейства OpenAI залежать від префікса. Використовуйте `openai-codex/*`, якщо вам потрібен -OAuth Codex через PI; використовуйте `openai/*`, якщо вам потрібен прямий доступ до API OpenAI або -коли ви примусово використовуєте нативний harness app-server Codex: +Маршрути сімейства OpenAI залежать від префікса. Використовуйте `openai-codex/*`, коли хочете +OAuth Codex через Pi; використовуйте `openai/*`, коли хочете прямий доступ до API OpenAI або +коли примусово використовуєте нативний каркас app-server Codex: -| Посилання на модель | Шлях середовища виконання | Використовуйте, коли | -| -------------------------------------------- | --------------------------------------------- | ---------------------------------------------------------------------------- | -| `openai/gpt-5.4` | Провайдер OpenAI через інфраструктуру OpenClaw/PI | Вам потрібен поточний прямий доступ до OpenAI Platform API з `OPENAI_API_KEY`. | -| `openai-codex/gpt-5.5` | OAuth OpenAI Codex через OpenClaw/PI | Вам потрібна автентифікація за підпискою ChatGPT/Codex із типовим раннером PI. | -| `openai/gpt-5.5` + `agentRuntime.id: "codex"` | Harness app-server Codex | Вам потрібне нативне виконання через app-server Codex для вбудованого ходу агента. | +| Посилання моделі | Шлях середовища виконання | Використовуйте, коли | +| -------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------- | +| `openai/gpt-5.4` | Провайдер OpenAI через механізми OpenClaw/Pi | Вам потрібен поточний прямий доступ до API OpenAI Platform з `OPENAI_API_KEY`. | +| `openai-codex/gpt-5.5` | OpenAI Codex OAuth через OpenClaw/Pi | Вам потрібна автентифікація підписки ChatGPT/Codex зі типовим виконавцем Pi. | +| `openai/gpt-5.5` + `agentRuntime.id: "codex"` | Каркас app-server Codex | Вам потрібне нативне виконання через app-server Codex для вбудованого ходу агента. | GPT-5.5 наразі в OpenClaw доступна лише через підписку/OAuth. Використовуйте -`openai-codex/gpt-5.5` для OAuth через PI або `openai/gpt-5.5` разом із harness app-server -Codex. Прямий доступ за API-ключем для `openai/gpt-5.5` підтримуватиметься, -щойно OpenAI ввімкне GPT-5.5 у публічному API. +`openai-codex/gpt-5.5` для OAuth через Pi або `openai/gpt-5.5` з каркасом +app-server Codex. Прямий доступ за API-ключем для `openai/gpt-5.5` підтримуватиметься, +щойно OpenAI увімкне GPT-5.5 у публічному API. Застарілі посилання `codex/gpt-*` і далі приймаються як псевдоніми для сумісності. Doctor -під час міграції сумісності переписує застарілі основні посилання середовища виконання на канонічні посилання моделей і окремо фіксує політику середовища виконання, тоді як застарілі посилання лише для резервного варіанта залишаються без змін, бо середовище виконання налаштовується для всього контейнера агента. -Нові конфігурації PI Codex OAuth мають використовувати `openai-codex/gpt-*`; нові конфігурації нативного -harness app-server мають використовувати `openai/gpt-*` разом із +під час міграції сумісності переписує застарілі основні посилання середовища виконання на канонічні посилання моделей і окремо зберігає політику середовища виконання, тоді як застарілі посилання лише для запасного варіанта залишаються без змін, бо середовище виконання налаштовується для всього контейнера агента. +Нові конфігурації PI Codex OAuth мають використовувати `openai-codex/gpt-*`; нові конфігурації +каркаса нативного app-server мають використовувати `openai/gpt-*` разом із `agentRuntime.id: "codex"`. -`agents.defaults.imageModel` дотримується того самого поділу префіксів. Використовуйте -`openai-codex/gpt-*`, коли розуміння зображень має виконуватися через шлях провайдера OpenAI -Codex OAuth. Використовуйте `codex/gpt-*`, коли розуміння зображень має виконуватися -через обмежений хід app-server Codex. Модель app-server Codex повинна -заявляти підтримку введення зображень; текстові моделі Codex завершуються помилкою ще до початку медіаходу. +`agents.defaults.imageModel` дотримується того самого розділення префіксів. Використовуйте +`openai-codex/gpt-*`, коли розуміння зображень має працювати через шлях провайдера OpenAI +Codex OAuth. Використовуйте `codex/gpt-*`, коли розуміння зображень має працювати +через обмежений хід app-server Codex. Модель app-server Codex має +заявляти підтримку вхідних зображень; текстові моделі Codex завершуються з помилкою до того, як почнеться медіа-хід. -Використовуйте `/status`, щоб підтвердити фактичний harness для поточної сесії. Якщо -вибір дивує, увімкніть налагоджувальне журналювання для підсистеми `agents/harness` +Використовуйте `/status`, щоб підтвердити фактичний каркас для поточної сесії. Якщо вибір дивує, +увімкніть журналювання налагодження для підсистеми `agents/harness` і перегляньте структурований запис шлюзу `agent harness selected`. Він -містить ID вибраного harness, причину вибору, політику середовища виконання/резервного варіанта та, -у режимі `auto`, результат підтримки для кожного кандидата Plugin-а. +містить ідентифікатор вибраного каркаса, причину вибору, політику середовища виконання/запасного варіанта та, +у режимі `auto`, результат підтримки для кожного кандидата Plugin. ### Що означають попередження doctor -`openclaw doctor` попереджає, коли всі наведені умови істинні: +`openclaw doctor` показує попередження, коли одночасно виконуються всі ці умови: - вбудований Plugin `codex` увімкнено або дозволено - основна модель агента — `openai-codex/*` -- фактичне середовище виконання цього агента — не `codex` +- ефективне середовище виконання цього агента — не `codex` Це попередження існує, тому що користувачі часто очікують, що «Plugin Codex увімкнено» означає -«нативне середовище виконання app-server Codex». OpenClaw не робить такого припущення. Попередження -означає: +«нативне середовище виконання app-server Codex». OpenClaw не робить такого припущення. Попередження означає: -- **Жодних змін не потрібно**, якщо ви мали на увазі OAuth ChatGPT/Codex через PI. +- **Нічого змінювати не потрібно**, якщо вам потрібен був OAuth ChatGPT/Codex через Pi. - Змініть модель на `openai/` і встановіть - `agentRuntime.id: "codex"`, якщо ви мали на увазі нативне виконання + `agentRuntime.id: "codex"`, якщо вам потрібне нативне виконання через app-server. -- Наявні сесії все одно потребують `/new` або `/reset` після зміни середовища виконання, - оскільки фіксація середовища виконання сесії є сталою. +- Наявним сесіям усе одно потрібен `/new` або `/reset` після зміни середовища виконання, + тому що прив’язки середовища виконання сесії є фіксованими. -Вибір harness не є механізмом керування живою сесією. Коли виконується вбудований хід, -OpenClaw записує ID вибраного harness у цю сесію і далі використовує його для -наступних ходів у межах того самого ID сесії. Змінюйте конфігурацію `agentRuntime` або -`OPENCLAW_AGENT_RUNTIME`, коли хочете, щоб майбутні сесії використовували інший harness; +Вибір каркаса не є механізмом керування поточною сесією в реальному часі. Коли виконується вбудований хід, +OpenClaw записує ідентифікатор вибраного каркаса в цю сесію і продовжує використовувати його для +наступних ходів у межах того самого ідентифікатора сесії. Змінюйте конфігурацію `agentRuntime` або +`OPENCLAW_AGENT_RUNTIME`, коли хочете, щоб майбутні сесії використовували інший каркас; використовуйте `/new` або `/reset`, щоб почати нову сесію перед перемиканням наявної розмови між Pi і Codex. Це дає змогу уникнути відтворення одного транскрипту через дві несумісні нативні системи сесій. -Застарілі сесії, створені до появи фіксації harness, вважаються прив’язаними до Pi, щойно -вони мають історію транскрипту. Використовуйте `/new` або `/reset`, щоб перевести таку -розмову на Codex після зміни конфігурації. +Застарілі сесії, створені до появи прив’язок каркаса, вважаються прив’язаними до Pi, щойно в них +з’являється історія транскрипту. Використовуйте `/new` або `/reset`, щоб перевести цю розмову на +Codex після зміни конфігурації. -`/status` показує фактичне середовище виконання моделі. Типовий harness Pi відображається як -`Runtime: OpenClaw Pi Default`, а harness app-server Codex — як +`/status` показує фактичне середовище виконання моделі. Типовий каркас Pi відображається як +`Runtime: OpenClaw Pi Default`, а каркас app-server Codex — як `Runtime: OpenAI Codex`. ## Вимоги -- OpenClaw із доступним вбудованим Plugin-ом `codex`. -- App-server Codex версії `0.125.0` або новішої. Вбудований Plugin за замовчуванням керує - сумісним бінарним файлом app-server Codex, тому локальні команди `codex` у `PATH` - не впливають на звичайний запуск harness. -- Автентифікація Codex, доступна процесу app-server. +- OpenClaw із доступним вбудованим Plugin `codex`. +- app-server Codex `0.125.0` або новішої версії. Вбудований Plugin типово керує + сумісним двійковим файлом app-server Codex, тому локальні команди `codex` у `PATH` + не впливають на звичайний запуск каркаса. +- Автентифікація Codex, доступна для процесу app-server. -Plugin блокує старі або неверсіоновані handshake app-server. Це утримує -OpenClaw на поверхні протоколу, з якою його було протестовано. +Plugin блокує старіші або неверсіоновані рукостискання app-server. Це зберігає +роботу OpenClaw у межах поверхні протоколу, з якою його було протестовано. -Для live- і Docker smoke-тестів автентифікація зазвичай надходить із `OPENAI_API_KEY`, а також, -за потреби, з файлів CLI Codex, таких як `~/.codex/auth.json` і -`~/.codex/config.toml`. Використовуйте ті самі матеріали автентифікації, що й ваш локальний app-server Codex. +Для live- і Docker-smoke-тестів автентифікація зазвичай надходить із `OPENAI_API_KEY`, а також із +необов’язкових файлів CLI Codex, таких як `~/.codex/auth.json` і +`~/.codex/config.toml`. Використовуйте ті самі матеріали автентифікації, що і ваш локальний app-server Codex. ## Мінімальна конфігурація -Використовуйте `openai/gpt-5.5`, увімкніть вбудований Plugin і примусово задайте -harness `codex`: +Використовуйте `openai/gpt-5.5`, увімкніть вбудований Plugin і примусово задайте каркас `codex`: ```json5 { @@ -214,7 +210,7 @@ harness `codex`: } ``` -Якщо ваша конфігурація використовує `plugins.allow`, додайте туди також `codex`: +Якщо у вашій конфігурації використовується `plugins.allow`, також додайте туди `codex`: ```json5 { @@ -229,26 +225,25 @@ harness `codex`: } ``` -Застарілі конфігурації, які встановлюють `agents.defaults.model` або модель агента в -`codex/`, і далі автоматично вмикають вбудований Plugin `codex`. У нових конфігураціях слід +Застарілі конфігурації, які задають `agents.defaults.model` або модель агента як +`codex/`, і далі автоматично вмикають вбудований Plugin `codex`. Нові конфігурації мають віддавати перевагу `openai/` разом із явним записом `agentRuntime`, наведеним вище. ## Додайте Codex поруч з іншими моделями -Не встановлюйте `agentRuntime.id: "codex"` глобально, якщо той самий агент має вільно перемикатися -між Codex і моделями інших провайдерів. Примусово задане середовище виконання застосовується до кожного -вбудованого ходу для цього агента або сесії. Якщо ви виберете модель Anthropic, поки це середовище виконання примусово задане, OpenClaw усе одно спробує harness Codex і завершиться помилкою без резервного переходу -замість того, щоб непомітно маршрутизувати цей хід через Pi. +Не задавайте `agentRuntime.id: "codex"` глобально, якщо той самий агент має вільно перемикатися +між моделями провайдера Codex і не-Codex. Примусове середовище виконання застосовується до кожного +вбудованого ходу для цього агента або сесії. Якщо ви виберете модель Anthropic, поки це середовище виконання примусово задано, OpenClaw усе одно спробує каркас Codex і завершиться з помилкою, замість того щоб тихо спрямувати цей хід через Pi. -Натомість використовуйте одну з таких конфігурацій: +Натомість використовуйте одну з таких форм: - Розмістіть Codex на окремому агенті з `agentRuntime.id: "codex"`. -- Залиште типовий агент на `agentRuntime.id: "auto"` і резервний перехід на Pi для звичайного змішаного +- Залиште типовий агент на `agentRuntime.id: "auto"` і запасний варіант Pi для звичайного змішаного використання провайдерів. - Використовуйте застарілі посилання `codex/*` лише для сумісності. Нові конфігурації мають віддавати перевагу `openai/*` разом із явною політикою середовища виконання Codex. -Наприклад, така конфігурація залишає типовий агент на звичайному автоматичному виборі й +Наприклад, така конфігурація залишає типовий агент на звичайному автоматичному виборі та додає окремого агента Codex: ```json5 @@ -286,37 +281,37 @@ harness `codex`: } ``` -З такою конфігурацією: +У такій формі: -- Типовий агент `main` використовує звичайний шлях провайдера та резервний перехід сумісності через Pi. -- Агент `codex` використовує harness app-server Codex. -- Якщо для агента `codex` Codex відсутній або не підтримується, хід - завершується помилкою замість тихого переходу на Pi. +- Типовий агент `main` використовує звичайний шлях провайдера та сумісний запасний варіант Pi. +- Агент `codex` використовує каркас app-server Codex. +- Якщо Codex відсутній або не підтримується для агента `codex`, хід + завершується з помилкою замість тихого використання Pi. ## Маршрутизація команд агента Агенти мають маршрутизувати запити користувача за наміром, а не лише за словом "Codex": -| Користувач просить... | Агент має використовувати... | -| ----------------------------------------------------- | ----------------------------------------------- | -| "Прив’яжи цей чат до Codex" | `/codex bind` | -| "Віднови тут гілку Codex ``" | `/codex resume ` | -| "Покажи гілки Codex" | `/codex threads` | -| "Використовуй Codex як середовище виконання для цього агента" | зміна конфігурації `agentRuntime.id` | -| "Використовуй мою підписку ChatGPT/Codex зі звичайним OpenClaw" | посилання на моделі `openai-codex/*` | -| "Запусти Codex через ACP/acpx" | ACP `sessions_spawn({ runtime: "acp", ... })` | -| "Запусти Claude Code/Gemini/OpenCode/Cursor у гілці" | ACP/acpx, не `/codex` і не нативні субагенти | +| Користувач просить... | Агент має використовувати... | +| ------------------------------------------------------ | ----------------------------------------------- | +| "Прив’яжи цей чат до Codex" | `/codex bind` | +| "Віднови тут потік Codex ``" | `/codex resume ` | +| "Покажи потоки Codex" | `/codex threads` | +| "Використовуй Codex як середовище виконання для цього агента" | зміна конфігурації `agentRuntime.id` | +| "Використовуй мою підписку ChatGPT/Codex зі звичайним OpenClaw" | посилання моделі `openai-codex/*` | +| "Запусти Codex через ACP/acpx" | ACP `sessions_spawn({ runtime: "acp", ... })` | +| "Запусти Claude Code/Gemini/OpenCode/Cursor у потоці" | ACP/acpx, а не `/codex` і не нативні субагенти | -OpenClaw показує агентам підказки щодо запуску ACP лише тоді, коли ACP увімкнено, -можна диспетчеризувати й підкріплено завантаженим бекендом середовища виконання. Якщо ACP недоступний, -системна підказка та skills Plugin-ів не повинні навчати агента маршрутизації +OpenClaw показує агентам інструкції щодо запуску ACP лише тоді, коли ACP увімкнено, +його можна диспетчеризувати, і він підтримується завантаженим бекендом середовища виконання. Якщо ACP недоступний, +системний запит і Skills Plugin не повинні навчати агента маршрутизації ACP. ## Розгортання лише з Codex -Примусово використовуйте harness Codex, коли потрібно довести, що кожен вбудований хід агента -використовує Codex. Явні середовища виконання Plugin-ів за замовчуванням не мають резервного переходу на Pi, тому -`fallback: "none"` є необов’язковим, але часто корисним як документація: +Примусово використовуйте каркас Codex, коли потрібно довести, що кожен вбудований хід агента +використовує Codex. Явні середовища виконання Plugin типово не мають запасного варіанта Pi, тому +`fallback: "none"` необов’язковий, але часто корисний як документація: ```json5 { @@ -332,20 +327,20 @@ ACP. } ``` -Перевизначення через змінну середовища: +Перевизначення через середовище: ```bash OPENCLAW_AGENT_RUNTIME=codex openclaw gateway run ``` -Коли Codex примусово задано, OpenClaw завершується помилкою на ранньому етапі, якщо Plugin Codex вимкнено, +Якщо Codex примусово задано, OpenClaw завершується з помилкою на ранньому етапі, якщо Plugin Codex вимкнено, app-server надто старий або app-server не може запуститися. Установлюйте -`OPENCLAW_AGENT_HARNESS_FALLBACK=pi` лише тоді, коли ви навмисно хочете, щоб Pi обробляв -відсутній вибір harness. +`OPENCLAW_AGENT_HARNESS_FALLBACK=pi` лише якщо ви навмисно хочете, щоб Pi обробляв +відсутній вибір каркаса. ## Codex для окремого агента -Ви можете зробити один агент лише для Codex, тоді як типовий агент збереже звичайний +Ви можете зробити одного агента лише-Codex, тоді як типовий агент збереже звичайний автовибір: ```json5 @@ -378,14 +373,14 @@ app-server надто старий або app-server не може запуст ``` Використовуйте звичайні команди сесії для перемикання агентів і моделей. `/new` створює нову -сесію OpenClaw, а harness Codex за потреби створює або відновлює власну sidecar-гілку app-server. -`/reset` очищає прив’язку сесії OpenClaw для цієї гілки -і дає наступному ходу змогу знову визначити harness із поточної конфігурації. +сесію OpenClaw, а каркас Codex за потреби створює або відновлює свій бічний потік app-server. +`/reset` очищає прив’язку сесії OpenClaw для цього потоку +і дає змогу наступному ходу знову визначити каркас із поточної конфігурації. ## Виявлення моделей -За замовчуванням Plugin Codex запитує app-server про доступні моделі. Якщо -виявлення не вдається або перевищує час очікування, він використовує вбудований резервний каталог для: +Типово Plugin Codex запитує в app-server доступні моделі. Якщо +виявлення завершується помилкою або перевищує час очікування, він використовує вбудований резервний каталог для: - GPT-5.5 - GPT-5.4 mini @@ -411,7 +406,7 @@ app-server надто старий або app-server не може запуст } ``` -Вимкніть виявлення, якщо хочете, щоб під час запуску не відбувалося опитування Codex і використовувався +Вимкніть виявлення, якщо хочете, щоб під час запуску не виконувалася перевірка Codex і використовувався резервний каталог: ```json5 @@ -431,27 +426,27 @@ app-server надто старий або app-server не може запуст } ``` -## Підключення до app-server і політика +## Підключення app-server і політика -За замовчуванням Plugin локально запускає керований OpenClaw бінарний файл Codex з: +Типово Plugin локально запускає керований OpenClaw двійковий файл Codex за допомогою: ```bash codex app-server --listen stdio:// ``` -Керований бінарний файл оголошено як вбудовану залежність середовища виконання Plugin-а й розгортається -разом з рештою залежностей Plugin-а `codex`. Це прив’язує версію app-server -до вбудованого Plugin-а, а не до окремого CLI Codex, +Керований двійковий файл оголошено як залежність середовища виконання вбудованого Plugin і підготовлено +разом з іншими залежностями Plugin `codex`. Це зберігає прив’язку версії app-server +до вбудованого Plugin, а не до будь-якого окремого CLI Codex, який випадково встановлено локально. Установлюйте `appServer.command` лише тоді, коли -навмисно хочете запускати інший виконуваний файл. +ви навмисно хочете запустити інший виконуваний файл. -За замовчуванням OpenClaw запускає локальні сесії harness Codex у режимі YOLO: +Типово OpenClaw запускає локальні сесії каркаса Codex у режимі YOLO: `approvalPolicy: "never"`, `approvalsReviewer: "user"` і -`sandbox: "danger-full-access"`. Це довірена локальна операторська позиція, яка використовується -для автономних Heartbeat: Codex може використовувати shell та мережеві інструменти без -зупинки на нативних запитах погодження, на які нікому відповісти. +`sandbox: "danger-full-access"`. Це позиція довіреного локального оператора, що використовується +для автономних Heartbeat: Codex може використовувати інструменти оболонки та мережі без +зупинки на нативних запитах погодження, на які нікому відповідати. -Щоб увімкнути погодження Codex, перевірені Guardian, установіть `appServer.mode: +Щоб увімкнути погодження, перевірені Guardian Codex, установіть `appServer.mode: "guardian"`: ```json5 @@ -472,16 +467,16 @@ codex app-server --listen stdio:// } ``` -Режим Guardian використовує нативний шлях автоматичного перегляду погоджень Codex. Коли Codex просить -вийти із sandbox, записувати поза межами робочого простору або додати дозволи на кшталт мережевого доступу, -Codex спрямовує цей запит на погодження до нативного рецензента замість запиту людині. Рецензент застосовує модель ризиків Codex і схвалює або відхиляє конкретний запит. Використовуйте Guardian, якщо вам потрібні сильніші запобіжники, ніж у режимі YOLO, +Режим Guardian використовує нативний шлях автоперевірки погоджень Codex. Коли Codex просить +вийти із sandbox, писати поза робочою областю або додати дозволи, як-от мережевий доступ, +Codex спрямовує цей запит на погодження до нативного рецензента замість людського запиту. Рецензент застосовує систему ризиків Codex і схвалює або відхиляє конкретний запит. Використовуйте Guardian, коли вам потрібно більше захисних обмежень, ніж у режимі YOLO, але при цьому потрібно, щоб агенти без нагляду могли просуватися далі. Пресет `guardian` розгортається в `approvalPolicy: "on-request"`, `approvalsReviewer: "auto_review"` і `sandbox: "workspace-write"`. -Окремі поля політики все одно перевизначають `mode`, тож розширені розгортання можуть поєднувати -цей пресет із явними налаштуваннями. Старе значення рецензента `guardian_subagent` -і далі приймається як псевдонім для сумісності, але в нових конфігураціях слід використовувати +Окремі поля політики, як і раніше, перевизначають `mode`, тому в розширених розгортаннях можна поєднувати +пресет із явними налаштуваннями. Старе значення рецензента `guardian_subagent` +і далі приймається як псевдонім для сумісності, але нові конфігурації мають використовувати `auto_review`. Для app-server, який уже працює, використовуйте транспорт WebSocket: @@ -508,22 +503,22 @@ Codex спрямовує цей запит на погодження до нат Підтримувані поля `appServer`: -| Field | Типове значення | Значення | -| ------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------- | -| `transport` | `"stdio"` | `"stdio"` запускає Codex; `"websocket"` підключається до `url`. | -| `command` | керований бінарний файл Codex | Виконуваний файл для транспорту stdio. Не задавайте, щоб використовувати керований бінарний файл; задавайте лише для явного перевизначення. | -| `args` | `["app-server", "--listen", "stdio://"]` | Аргументи для транспорту stdio. | -| `url` | не задано | URL WebSocket app-server. | -| `authToken` | не задано | Bearer token для транспорту WebSocket. | -| `headers` | `{}` | Додаткові заголовки WebSocket. | -| `requestTimeoutMs` | `60000` | Час очікування для викликів контрольної площини app-server. | -| `mode` | `"yolo"` | Пресет для виконання в режимі YOLO або з перевіркою Guardian. | -| `approvalPolicy` | `"never"` | Нативна політика погодження Codex, що надсилається під час запуску/відновлення гілки/ходу. | -| `sandbox` | `"danger-full-access"` | Нативний режим sandbox Codex, що надсилається під час запуску/відновлення гілки. | -| `approvalsReviewer` | `"user"` | Використовуйте `"auto_review"`, щоб Codex переглядав нативні запити на погодження. `guardian_subagent` залишається застарілим псевдонімом. | -| `serviceTier` | не задано | Необов’язковий service tier app-server Codex: `"fast"`, `"flex"` або `null`. Некоректні застарілі значення ігноруються. | +| Поле | Типове значення | Значення | +| ------------------- | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------- | +| `transport` | `"stdio"` | `"stdio"` запускає Codex; `"websocket"` підключається до `url`. | +| `command` | керований двійковий файл Codex | Виконуваний файл для транспорту stdio. Залиште порожнім, щоб використовувати керований двійковий файл; задавайте лише для явного перевизначення. | +| `args` | `["app-server", "--listen", "stdio://"]` | Аргументи для транспорту stdio. | +| `url` | не задано | URL app-server WebSocket. | +| `authToken` | не задано | Bearer-токен для транспорту WebSocket. | +| `headers` | `{}` | Додаткові заголовки WebSocket. | +| `requestTimeoutMs` | `60000` | Час очікування для викликів площини керування app-server. | +| `mode` | `"yolo"` | Пресет для виконання YOLO або з погодженням, перевіреним Guardian. | +| `approvalPolicy` | `"never"` | Нативна політика погодження Codex, яка надсилається під час запуску/відновлення потоку/ходу. | +| `sandbox` | `"danger-full-access"` | Нативний режим sandbox Codex, який надсилається під час запуску/відновлення потоку. | +| `approvalsReviewer` | `"user"` | Використовуйте `"auto_review"`, щоб Codex перевіряв нативні запити погодження. `guardian_subagent` лишається застарілим псевдонімом. | +| `serviceTier` | не задано | Необов’язковий рівень сервісу app-server Codex: `"fast"`, `"flex"` або `null`. Неприпустимі застарілі значення ігноруються. | -Перевизначення через змінні середовища й далі доступні для локального тестування: +Перевизначення через середовище лишаються доступними для локального тестування: - `OPENCLAW_CODEX_APP_SERVER_BIN` - `OPENCLAW_CODEX_APP_SERVER_ARGS` @@ -531,18 +526,82 @@ Codex спрямовує цей запит на погодження до нат - `OPENCLAW_CODEX_APP_SERVER_APPROVAL_POLICY` - `OPENCLAW_CODEX_APP_SERVER_SANDBOX` -`OPENCLAW_CODEX_APP_SERVER_BIN` обходить керований бінарний файл, коли +`OPENCLAW_CODEX_APP_SERVER_BIN` оминає керований двійковий файл, коли `appServer.command` не задано. -`OPENCLAW_CODEX_APP_SERVER_GUARDIAN=1` видалено. Натомість використовуйте +`OPENCLAW_CODEX_APP_SERVER_GUARDIAN=1` вилучено. Натомість використовуйте `plugins.entries.codex.config.appServer.mode: "guardian"` або `OPENCLAW_CODEX_APP_SERVER_MODE=guardian` для разового локального тестування. Для -відтворюваних розгортань перевага надається конфігурації, оскільки вона зберігає поведінку Plugin-а в тому самому -перевіреному файлі, що й решта налаштувань harness Codex. +відтворюваних розгортань краще використовувати конфігурацію, оскільки вона зберігає поведінку Plugin у тому самому перевіреному файлі, що й решта налаштувань каркаса Codex. + +## Computer Use + +Computer Use — це нативний MCP Plugin Codex. OpenClaw не постачає застосунок керування робочим столом +і не виконує дії на робочому столі самостійно; він вмикає Plugins app-server Codex, +встановлює налаштований Plugin маркетплейсу Codex за запитом, перевіряє, +що MCP-сервер `computer-use` доступний, а потім дозволяє Codex обробляти +нативні виклики інструментів MCP під час ходів у режимі Codex. + +Установіть `plugins.entries.codex.config.computerUse`, якщо хочете, щоб ходи в режимі Codex +вимагали Computer Use: + +```json5 +{ + plugins: { + entries: { + codex: { + enabled: true, + config: { + computerUse: { + autoInstall: true, + }, + }, + }, + }, + }, + agents: { + defaults: { + model: "openai/gpt-5.5", + embeddedHarness: { + runtime: "codex", + }, + }, + }, +} +``` + +Якщо поля маркетплейсу не задано, OpenClaw просить app-server Codex використовувати виявлені ним +маркетплейси. У новому домашньому каталозі Codex app-server ініціалізує офіційний куруємий +маркетплейс, а OpenClaw дотримується тієї самої схеми завантаження, що й Codex: він опитує +`plugin/list` під час встановлення, перш ніж вважати Computer Use недоступним. Типовий час очікування виявлення становить 60 секунд і може бути налаштований через +`marketplaceDiscoveryTimeoutMs`. Якщо кілька відомих маркетплейсів Codex містять +Computer Use, OpenClaw використовує порядок пріоритету маркетплейсів Codex, перш ніж +завершитися з помилкою при невідомих неоднозначних збігах. + +Використовуйте `marketplaceSource` для нетипового джерела маркетплейсу Codex, яке +app-server може додати, або `marketplacePath` для локального файла маркетплейсу, який +вже існує на машині. Якщо маркетплейс уже зареєстровано в app-server Codex, +використовуйте натомість `marketplaceName`. Типові значення: +`pluginName: "computer-use"` і `mcpServerName: "computer-use"`. +З міркувань безпеки автоінсталяція на початку ходу використовує лише ті маркетплейси, які app-server +уже виявив. Використовуйте `/codex computer-use install` для явного встановлення з +налаштованого `marketplaceSource` або `marketplacePath`. + +Ту саму конфігурацію можна перевірити або встановити з поверхні команд: + +- `/codex computer-use status` +- `/codex computer-use install` +- `/codex computer-use install --source ` +- `/codex computer-use install --marketplace-path ` + +Computer Use специфічний для macOS і може потребувати локальних дозволів ОС, перш ніж +MCP-сервер Codex зможе керувати застосунками. Якщо `computerUse.enabled` має значення true і MCP- +сервер недоступний, ходи в режимі Codex завершуються з помилкою до запуску потоку, а не +тихо виконуються без нативних інструментів Computer Use. ## Поширені рецепти -Локальний Codex із типовим транспортом stdio: +Локальний Codex з типовим транспортом stdio: ```json5 { @@ -556,7 +615,7 @@ Codex спрямовує цей запит на погодження до нат } ``` -Перевірка harness лише з Codex: +Перевірка каркаса лише Codex: ```json5 { @@ -623,187 +682,187 @@ Codex спрямовує цей запит на погодження до нат } ``` -Перемикання моделей і далі контролюється OpenClaw. Коли сесію OpenClaw прив’язано -до наявної гілки Codex, наступний хід знову надсилає до -app-server поточну вибрану модель OpenAI, провайдера, політику погодження, sandbox і service tier. +Перемикання моделей і далі контролюється OpenClaw. Коли сесію OpenClaw приєднано +до наявного потоку Codex, наступний хід знову надсилає до +app-server поточно вибрані модель OpenAI, провайдера, політику погодження, sandbox і рівень сервісу. Перемикання з `openai/gpt-5.5` на `openai/gpt-5.2` зберігає -прив’язку до гілки, але просить Codex продовжити з новою вибраною моделлю. +прив’язку до потоку, але просить Codex продовжити з новообраною моделлю. ## Команда Codex -Вбудований Plugin реєструє `/codex` як дозволену slash-команду. Вона є -універсальною та працює в будь-якому каналі, що підтримує текстові команди OpenClaw. +Вбудований Plugin реєструє `/codex` як авторизовану slash-команду. Вона є +універсальною і працює в будь-якому каналі, який підтримує текстові команди OpenClaw. Поширені форми: -- `/codex status` показує поточне підключення до app-server, моделі, обліковий запис, ліміти швидкості, сервери MCP і Skills. -- `/codex models` виводить поточні моделі app-server Codex. -- `/codex threads [filter]` виводить список нещодавніх гілок Codex. -- `/codex resume ` прив’язує поточну сесію OpenClaw до наявної гілки Codex. -- `/codex compact` просить app-server Codex виконати Compaction прив’язаної гілки. -- `/codex review` запускає нативну перевірку Codex для прив’язаної гілки. +- `/codex status` показує активне підключення до app-server, моделі, обліковий запис, ліміти швидкості, MCP-сервери та Skills. +- `/codex models` перелічує активні моделі app-server Codex. +- `/codex threads [filter]` перелічує недавні потоки Codex. +- `/codex resume ` приєднує поточну сесію OpenClaw до наявного потоку Codex. +- `/codex compact` просить app-server Codex виконати Compaction для приєднаного потоку. +- `/codex review` запускає нативну перевірку Codex для приєднаного потоку. +- `/codex computer-use status` перевіряє налаштований Plugin Computer Use і MCP-сервер. +- `/codex computer-use install` встановлює налаштований Plugin Computer Use і перезавантажує MCP-сервери. - `/codex account` показує стан облікового запису та лімітів швидкості. -- `/codex mcp` показує список станів серверів MCP app-server Codex. -- `/codex skills` показує список Skills app-server Codex. +- `/codex mcp` перелічує стан MCP-серверів app-server Codex. +- `/codex skills` перелічує Skills app-server Codex. -`/codex resume` записує той самий sidecar-файл прив’язки, який harness використовує для -звичайних ходів. На наступному повідомленні OpenClaw відновлює цю гілку Codex, передає -поточну вибрану модель OpenClaw до app-server і зберігає -увімкнену розширену історію. +`/codex resume` записує той самий бічний файл прив’язки, який каркас використовує для +звичайних ходів. У наступному повідомленні OpenClaw відновлює цей потік Codex, передає +до app-server поточну вибрану модель OpenClaw і зберігає увімкнену +розширену історію. -Поверхня команд потребує app-server Codex версії `0.125.0` або новішої. Окремі -методи керування позначаються як `unsupported by this Codex app-server`, якщо -майбутній або власний app-server не надає цей метод JSON-RPC. +Поверхня команд вимагає app-server Codex `0.125.0` або новішої версії. Про окремі +методи керування повідомляється як `unsupported by this Codex app-server`, якщо +майбутній або кастомний app-server не надає цей метод JSON-RPC. -## Межі hooks +## Межі хуків -Harness Codex має три шари hooks: +Каркас Codex має три шари хуків: -| Layer | Owner | Призначення | -| ------------------------------------- | ------------------------ | ----------------------------------------------------------------- | -| Hooks Plugin-ів OpenClaw | OpenClaw | Сумісність продукту/Plugin-ів між harness Pi і Codex. | -| Middleware розширення app-server Codex | Вбудовані Plugin-и OpenClaw | Поведінка адаптера для кожного ходу навколо динамічних інструментів OpenClaw. | -| Нативні hooks Codex | Codex | Низькорівневий життєвий цикл Codex і нативна політика інструментів із конфігурації Codex. | +| Шар | Власник | Призначення | +| ------------------------------------- | ------------------------ | ------------------------------------------------------------------ | +| Хуки Plugin OpenClaw | OpenClaw | Сумісність продукту/Plugin між каркасами Pi і Codex. | +| Проміжне ПЗ розширення app-server Codex | вбудовані Plugins OpenClaw | Поведінка адаптера для кожного ходу навколо динамічних інструментів OpenClaw. | +| Нативні хуки Codex | Codex | Низькорівневий життєвий цикл Codex і політика нативних інструментів із конфігурації Codex. | -OpenClaw не використовує файли Codex `hooks.json` рівня проєкту або глобальні файли для маршрутизації -поведінки Plugin-ів OpenClaw. Для підтримуваного нативного мосту інструментів і дозволів -OpenClaw впроваджує конфігурацію Codex для кожної гілки для `PreToolUse`, `PostToolUse`, -`PermissionRequest` і `Stop`. Інші hooks Codex, як-от `SessionStart` і -`UserPromptSubmit`, залишаються елементами керування рівня Codex; вони не відкриваються як -hooks Plugin-ів OpenClaw у контракті v1. +OpenClaw не використовує файли `hooks.json` проєкту чи глобальні файли Codex для маршрутизації +поведінки Plugins OpenClaw. Для підтримуваного мосту нативних інструментів і дозволів +OpenClaw вставляє конфігурацію Codex для кожного потоку для `PreToolUse`, `PostToolUse`, +`PermissionRequest` і `Stop`. Інші хуки Codex, як-от `SessionStart` і +`UserPromptSubmit`, лишаються елементами керування рівня Codex; вони не відкриваються як +хуки Plugin OpenClaw у контракті v1. Для динамічних інструментів OpenClaw OpenClaw виконує інструмент після того, як Codex запитує -виклик, тому OpenClaw запускає поведінку Plugin-а та middleware, якою він володіє в -адаптері harness. Для нативних інструментів Codex канонічний запис інструмента належить Codex. -OpenClaw може дзеркалити окремі події, але не може переписувати нативну гілку Codex, якщо -Codex не відкриває цю операцію через app-server або нативні callbacks hooks. +виклик, тому OpenClaw запускає поведінку Plugin і проміжного ПЗ, якою він володіє, у +адаптері каркаса. Для нативних інструментів Codex Codex володіє канонічним записом інструмента. +OpenClaw може дзеркалити вибрані події, але не може переписати нативний потік Codex, +якщо тільки Codex не відкриває цю операцію через app-server або колбеки +нативних хуків. -Проєкції Compaction і життєвого циклу LLM походять із сповіщень app-server Codex -і стану адаптера OpenClaw, а не з нативних команд hooks Codex. +Проєкції Compaction і життєвого циклу LLM надходять із +сповіщень app-server Codex і стану адаптера OpenClaw, а не з команд нативних хуків Codex. Події OpenClaw `before_compaction`, `after_compaction`, `llm_input` і -`llm_output` — це спостереження рівня адаптера, а не побайтні копії -внутрішнього запиту Codex або навантажень Compaction. +`llm_output` є спостереженнями на рівні адаптера, а не побайтовими копіями +внутрішнього запиту або навантаження Compaction у Codex. Нативні сповіщення app-server Codex `hook/started` і `hook/completed` проєктуються як події агента `codex_app_server.hook` для траєкторії та налагодження. -Вони не викликають hooks Plugin-ів OpenClaw. +Вони не викликають хуки Plugin OpenClaw. ## Контракт підтримки V1 -Режим Codex — це не Pi з іншим викликом моделі під ним. Codex бере на себе більшу частину -нативного циклу моделі, а OpenClaw адаптує свої поверхні Plugin-ів і сесій +Режим Codex — це не Pi з іншим викликом моделі під ним. Codex керує більшою частиною +нативного циклу моделі, а OpenClaw адаптує свої поверхні Plugins і сесій навколо цієї межі. Підтримується в середовищі виконання Codex v1: -| Surface | Підтримка | Чому | -| --------------------------------------------- | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Цикл моделі OpenAI через Codex | Підтримується | App-server Codex керує ходом OpenAI, нативним відновленням гілки та нативним продовженням інструментів. | -| Маршрутизація та доставлення каналів OpenClaw | Підтримується | Telegram, Discord, Slack, WhatsApp, iMessage та інші канали залишаються поза межами середовища виконання моделі. | -| Динамічні інструменти OpenClaw | Підтримується | Codex просить OpenClaw виконати ці інструменти, тому OpenClaw залишається на шляху виконання. | -| Plugin-и підказок і контексту | Підтримується | OpenClaw будує накладки підказок і проєктує контекст у хід Codex перед запуском або відновленням гілки. | -| Життєвий цикл рушія контексту | Підтримується | Збирання, ingest або супровід після ходу та координація Compaction рушія контексту виконуються для ходів Codex. | -| Hooks динамічних інструментів | Підтримується | `before_tool_call`, `after_tool_call` і middleware результатів інструментів виконуються навколо динамічних інструментів OpenClaw. | -| Hooks життєвого циклу | Підтримуються як спостереження адаптера | `llm_input`, `llm_output`, `agent_end`, `before_compaction` і `after_compaction` спрацьовують із коректними навантаженнями режиму Codex. | -| Шлюз перегляду фінальної відповіді | Підтримується через реле нативних hooks | `Stop` Codex передається до `before_agent_finalize`; `revise` просить Codex виконати ще один прохід моделі перед фіналізацією. | -| Блокування або спостереження нативного shell, patch і MCP | Підтримується через реле нативних hooks | `PreToolUse` і `PostToolUse` Codex передаються для зафіксованих поверхонь нативних інструментів, включно з навантаженнями MCP у app-server Codex `0.125.0` або новішому. Блокування підтримується; переписування аргументів — ні. | -| Нативна політика дозволів | Підтримується через реле нативних hooks | `PermissionRequest` Codex може маршрутизуватися через політику OpenClaw там, де це відкриває середовище виконання. Якщо OpenClaw не повертає рішення, Codex продовжує звичайним шляхом погодження guardian або користувача. | -| Захоплення траєкторії app-server | Підтримується | OpenClaw записує запит, який він надіслав до app-server, і сповіщення, які отримує від app-server. | +| Поверхня | Підтримка | Чому | +| --------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Цикл моделі OpenAI через Codex | Підтримується | app-server Codex керує ходом OpenAI, нативним відновленням потоку та нативним продовженням інструментів. | +| Маршрутизація й доставлення каналів OpenClaw | Підтримується | Telegram, Discord, Slack, WhatsApp, iMessage та інші канали лишаються поза середовищем виконання моделі. | +| Динамічні інструменти OpenClaw | Підтримується | Codex просить OpenClaw виконати ці інструменти, тому OpenClaw лишається в шляху виконання. | +| Plugins запиту та контексту | Підтримується | OpenClaw будує накладки запиту і проєктує контекст у хід Codex перед запуском або відновленням потоку. | +| Життєвий цикл рушія контексту | Підтримується | Збирання, ingest або обслуговування після ходу, а також координація Compaction рушія контексту виконуються для ходів Codex. | +| Хуки динамічних інструментів | Підтримується | `before_tool_call`, `after_tool_call` і проміжне ПЗ результатів інструментів працюють навколо динамічних інструментів OpenClaw. | +| Хуки життєвого циклу | Підтримуються як спостереження адаптера | `llm_input`, `llm_output`, `agent_end`, `before_compaction` і `after_compaction` спрацьовують із чесними навантаженнями режиму Codex. | +| Шлюз ревізії фінальної відповіді | Підтримується через ретрансляцію нативних хуків | Codex `Stop` ретранслюється до `before_agent_finalize`; `revise` просить Codex виконати ще один прохід моделі перед фіналізацією. | +| Блокування або спостереження для нативних shell, patch і MCP | Підтримується через ретрансляцію нативних хуків | Codex `PreToolUse` і `PostToolUse` ретранслюються для підтверджених нативних поверхонь інструментів, зокрема для навантажень MCP у app-server Codex `0.125.0` або новіше. Блокування підтримується; переписування аргументів — ні. | +| Політика нативних дозволів | Підтримується через ретрансляцію нативних хуків | Codex `PermissionRequest` може маршрутизуватися через політику OpenClaw там, де середовище виконання це підтримує. Якщо OpenClaw не повертає рішення, Codex продовжує через свій звичайний шлях погодження guardian або користувача. | +| Захоплення траєкторії app-server | Підтримується | OpenClaw записує запит, який він надіслав до app-server, і сповіщення, які він отримує від app-server. | Не підтримується в середовищі виконання Codex v1: -| Surface | Межа v1 | Майбутній шлях | -| --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | -| Мутація аргументів нативних інструментів | Нативні hooks попередньої обробки інструментів Codex можуть блокувати, але OpenClaw не переписує аргументи нативних інструментів Codex. | Потрібна підтримка hooks/схеми Codex для заміни вхідних даних інструмента. | -| Редагована історія нативного транскрипту Codex | Codex володіє канонічною історією нативної гілки. OpenClaw володіє дзеркалом і може проєктувати майбутній контекст, але не має змінювати непідтримувані внутрішні механізми. | Додати явні API app-server Codex, якщо потрібна хірургія нативної гілки. | -| `tool_result_persist` для записів нативних інструментів Codex | Цей hook трансформує записи транскрипту, що належать OpenClaw, а не записи нативних інструментів Codex. | Можна дзеркалити трансформовані записи, але для канонічного переписування потрібна підтримка Codex. | -| Розширені нативні метадані Compaction | OpenClaw спостерігає початок і завершення Compaction, але не отримує стабільного списку збереженого/відкинутого, різниці токенів або навантаження зведення. | Потрібні багатші події Compaction у Codex. | -| Втручання в Compaction | Поточні hooks Compaction OpenClaw у режимі Codex працюють лише на рівні сповіщень. | Додати hooks Codex до/після Compaction, якщо Plugin-ам потрібно забороняти або переписувати нативну Compaction. | -| Побайтне захоплення запиту API моделі | OpenClaw може захоплювати запити й сповіщення app-server, але ядро Codex внутрішньо будує фінальний запит API OpenAI. | Потрібна подія трасування запиту моделі Codex або API налагодження. | +| Поверхня | Межа V1 | Майбутній шлях | +| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- | +| Мутація аргументів нативних інструментів | Нативні pre-tool хуки Codex можуть блокувати, але OpenClaw не переписує аргументи нативних інструментів Codex. | Потребує підтримки хуків/схем Codex для заміни вхідних даних інструмента. | +| Редагована історія нативного транскрипту Codex | Codex володіє канонічною історією нативного потоку. OpenClaw володіє дзеркалом і може проєктувати майбутній контекст, але не повинен змінювати непідтримувані внутрішні елементи. | Додати явні API app-server Codex, якщо потрібне втручання в нативний потік. | +| `tool_result_persist` для записів нативних інструментів Codex | Цей хук перетворює записи транскрипту, якими володіє OpenClaw, а не записи нативних інструментів Codex. | Може дзеркалити перетворені записи, але канонічне переписування потребує підтримки Codex. | +| Розширені метадані нативного Compaction | OpenClaw спостерігає початок і завершення Compaction, але не отримує стабільного списку збереженого/відкинутого, дельти токенів або підсумкового навантаження. | Потрібні багатші події Compaction у Codex. | +| Втручання в Compaction | Поточні хуки Compaction OpenClaw у режимі Codex працюють на рівні сповіщень. | Додати pre/post хуки Compaction у Codex, якщо Plugins потрібно забороняти або переписувати нативний Compaction. | +| Побайтове захоплення запиту до API моделі | OpenClaw може захоплювати запити й сповіщення app-server, але ядро Codex формує фінальний запит до API OpenAI внутрішньо. | Потрібна подія трасування запиту моделі Codex або API налагодження. | ## Інструменти, медіа та Compaction -Harness Codex змінює лише низькорівневий виконавець вбудованого агента. +Каркас Codex змінює лише низькорівневий виконавець вбудованого агента. -OpenClaw і далі будує список інструментів і отримує результати динамічних інструментів від -harness. Текст, зображення, відео, музика, TTS, погодження та вивід інструментів повідомлень -і далі проходять звичайним шляхом доставлення OpenClaw. +OpenClaw, як і раніше, формує список інструментів і отримує результати динамічних інструментів від +каркаса. Текст, зображення, відео, музика, TTS, погодження та вивід інструментів обміну повідомленнями +і далі проходять через звичайний шлях доставлення OpenClaw. -Реле нативних hooks навмисно є узагальненим, але контракт підтримки v1 -обмежений нативними шляхами інструментів і дозволів Codex, які тестує OpenClaw. У +Ретрансляція нативних хуків навмисно є узагальненою, але контракт підтримки v1 +обмежено шляхами нативних інструментів і дозволів Codex, які тестує OpenClaw. У середовищі виконання Codex це включає навантаження `PreToolUse`, `PostToolUse` і `PermissionRequest` для shell, patch і MCP. Не припускайте, що кожна майбутня -подія hook Codex є поверхнею Plugin-а OpenClaw, доки контракт середовища виконання прямо -цього не визначить. +подія хуків Codex є поверхнею Plugin OpenClaw, доки контракт середовища виконання +не назве її явно. -Для `PermissionRequest` OpenClaw повертає явні рішення allow або deny -лише тоді, коли політика приймає рішення. Результат без рішення — це не allow. Codex -трактує його як відсутність рішення hook-а і переходить до власного шляху погодження guardian або користувача. +Для `PermissionRequest` OpenClaw повертає явні рішення дозволити або заборонити +лише тоді, коли політика ухвалює рішення. Результат без рішення — це не дозвіл. Codex трактує його як відсутність +рішення хука і переходить до власного шляху погодження guardian або користувача. -Виклики погодження інструментів MCP Codex маршрутизуються через потік -погодження Plugin-ів OpenClaw, коли Codex позначає `_meta.codex_approval_kind` як -`"mcp_tool_call"`. Запити Codex `request_user_input` надсилаються назад до -початкового чату, а наступне поставлене в чергу повідомлення-відповідь відповідає на цей нативний -запит сервера замість того, щоб спрямовуватися як додатковий контекст. Інші запити виклику MCP -і далі завершуються помилкою безпечним способом. +Запити на погодження для інструментів MCP Codex маршрутизуються через потік +погодження Plugin OpenClaw, коли Codex позначає `_meta.codex_approval_kind` як +`"mcp_tool_call"`. Запити Codex `request_user_input` надсилаються назад у +початковий чат, а наступне поставлене в чергу повідомлення-відповідь відповідає на цей нативний +запит сервера замість того, щоб спрямовуватися як додатковий контекст. Інші запити MCP все ще завершуються з помилкою. -Коли вибрана модель використовує harness Codex, нативна Compaction гілки -делегується app-server Codex. OpenClaw зберігає дзеркало транскрипту для історії -каналу, пошуку, `/new`, `/reset` і майбутнього перемикання моделі або harness. Це -дзеркало містить підказку користувача, фінальний текст асистента та полегшені записи -міркувань або плану Codex, коли app-server їх генерує. Наразі OpenClaw записує лише -сигнали початку та завершення нативної Compaction. Він іще не показує -людинозрозуміле зведення Compaction або аудитований список того, які записи Codex +Коли вибрана модель використовує каркас Codex, нативний Compaction потоку +делегується app-server Codex. OpenClaw зберігає дзеркало транскрипту для історії каналу, пошуку, `/new`, `/reset` і майбутнього перемикання моделі або каркаса. Дзеркало +включає запит користувача, фінальний текст помічника та полегшені записи +міркувань або плану Codex, якщо app-server їх надсилає. Наразі OpenClaw лише записує сигнали початку й завершення нативного Compaction. Він ще не надає +людинозрозумілого підсумку Compaction або придатного для аудиту списку того, які записи Codex зберіг після Compaction. -Оскільки Codex володіє канонічною нативною гілкою, `tool_result_persist` наразі -не переписує записи результатів нативних інструментів Codex. Він застосовується лише тоді, -коли OpenClaw записує результат інструмента до транскрипту сесії, що належить OpenClaw. +Оскільки Codex володіє канонічним нативним потоком, `tool_result_persist` наразі не +переписує записи результатів нативних інструментів Codex. Він застосовується лише тоді, коли +OpenClaw записує результат інструмента в транскрипт сесії, яким володіє OpenClaw. Генерація медіа не потребує Pi. Генерація зображень, відео, музики, PDF, TTS і -розуміння медіа й далі використовують відповідні налаштування провайдера/моделі, як-от +розуміння медіа і далі використовують відповідні налаштування провайдера/моделі, такі як `agents.defaults.imageGenerationModel`, `videoGenerationModel`, `pdfModel` і `messages.tts`. -## Усунення несправностей +## Усунення проблем -**Codex не з’являється як звичайний провайдер у `/model`:** це очікувано для +**Codex не з’являється як звичайний провайдер `/model`:** це очікувано для нових конфігурацій. Виберіть модель `openai/gpt-*` з `agentRuntime.id: "codex"` (або застаріле посилання `codex/*`), увімкніть `plugins.entries.codex.enabled` і перевірте, чи `plugins.allow` не виключає `codex`. **OpenClaw використовує Pi замість Codex:** `agentRuntime.id: "auto"` усе ще може використовувати Pi як -бекенд сумісності, якщо жоден harness Codex не бере на себе цей запуск. Установіть +бекенд сумісності, коли жоден каркас Codex не бере на себе запуск. Установіть `agentRuntime.id: "codex"`, щоб примусово вибрати Codex під час тестування. Примусово -задане середовище виконання Codex тепер завершується помилкою замість резервного переходу на Pi, якщо ви -явно не встановите `agentRuntime.fallback: "pi"`. Щойно буде вибрано app-server Codex, -його збої відображатимуться безпосередньо без додаткової конфігурації резервного варіанта. +задане середовище виконання Codex тепер завершується з помилкою замість переходу на Pi, якщо ви +явно не встановите `agentRuntime.fallback: "pi"`. Щойно app-server Codex +вибрано, його збої відображаються безпосередньо без додаткової конфігурації запасного варіанта. -**App-server відхиляється:** оновіть Codex так, щоб handshake app-server -повідомляв версію `0.125.0` або новішу. Пререлізи тієї самої версії або версії із суфіксом збірки, -такі як `0.125.0-alpha.2` або `0.125.0+custom`, відхиляються, оскільки -стабільний поріг протоколу `0.125.0` — це те, що тестує OpenClaw. +**app-server відхиляється:** оновіть Codex, щоб рукостискання app-server +повідомляло версію `0.125.0` або новішу. Передрелізи тієї самої версії або версії з суфіксом збірки, +такі як `0.125.0-alpha.2` або `0.125.0+custom`, відхиляються, тому що саме +стабільний поріг протоколу `0.125.0` тестує OpenClaw. **Виявлення моделей повільне:** зменште `plugins.entries.codex.config.discovery.timeoutMs` або вимкніть виявлення. -**Транспорт WebSocket одразу завершується помилкою:** перевірте `appServer.url`, `authToken` +**Транспорт WebSocket відразу завершується помилкою:** перевірте `appServer.url`, `authToken` і те, що віддалений app-server використовує ту саму версію протоколу app-server Codex. -**Модель не Codex використовує Pi:** це очікувано, якщо ви не примусово встановили +**Модель не-Codex використовує Pi:** це очікувано, якщо ви не примусово задали `agentRuntime.id: "codex"` для цього агента або не вибрали застаріле -посилання `codex/*`. Звичайні `openai/gpt-*` та інші посилання провайдерів залишаються на своєму звичайному +посилання `codex/*`. Звичайні `openai/gpt-*` та інші посилання провайдерів лишаються на своєму стандартному шляху провайдера в режимі `auto`. Якщо ви примусово задаєте `agentRuntime.id: "codex"`, кожен вбудований хід для цього агента має бути моделлю OpenAI, яку підтримує Codex. -## Пов’язані матеріали +## Пов’язане -- [Plugin-и harness агента](/uk/plugins/sdk-agent-harness) +- [Plugins каркаса агента](/uk/plugins/sdk-agent-harness) - [Середовища виконання агентів](/uk/concepts/agent-runtimes) - [Провайдери моделей](/uk/concepts/model-providers) - [Провайдер OpenAI](/uk/providers/openai) - [Status](/uk/cli/status) -- [Hooks Plugin-ів](/uk/plugins/hooks) -- [Довідник конфігурації](/uk/gateway/configuration-reference) +- [Хуки Plugin](/uk/plugins/hooks) +- [Довідник з конфігурації](/uk/gateway/configuration-reference) - [Тестування](/uk/help/testing-live#live-codex-app-server-harness-smoke)