docs(skills): урок 08-06 переписан — вывод теряет харнесс, не версия

- Зачем:
  - первая редакция объявляла отказ свойством codex-cli 0.146.0. Чистые
    0.146.0 и 0.146.1 на этой же машине пишут в перенаправленный файл
    штатно, значит запись вела следующего читателя чинить рецепты от
    несуществующей поломки.
- Что:
  - запись 2026-08-06 переписана: ось не «терминал против всего», а файл
    против канала, и живёт она в харнессе, а не в версии; одна причина на
    обе прежние находки, обход — канал вместо псевдотерминала.
  - методическая часть усилена: среда — тоже параметр серии, и первый
    подозреваемый при расхождении с документацией инструмента.
  - ловушка недоверенного каталога сохранена.
- Проверка:
  - изнутри харнесса на 0.146.1: `codex --version > f` — 0 байт,
    `| cat > g` — 18; `exec --json … > log` — пусто, `2>&1 | cat > log` —
    7 строк с thread_id и двумя command_execution; без песочницы то же.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dmitry DementievandClaude Opus 5 committed 2026-08-06 18:41:40 +03:00
1 parent 82bb9f5501
commit 1538fdaf4e
1 file changed
+46 -46
@@ -334,51 +334,51 @@
Отсюда требование вариантов, их цены и рекомендации — и к исполнителю, и Отсюда требование вариантов, их цены и рекомендации — и к исполнителю, и
к координатору, когда он несёт развилку владельцу. к координатору, когда он несёт развилку владельцу.
## 2026-08-06: Кодекс 0.146.0 молчит мимо терминала — три механизма слепнут ## 2026-08-06: вывод Кодекса теряет харнесс, а не версия
Сессия без прогона. Хвост от тикета #54 (clickstream v2): там вызовы Кодекса Запись переписана в тот же вечер: первая редакция валила отказ на версию
трижды падали вхолостую, причину я тогда назвал неверно. Здесь она снята codex-cli 0.146.0 и была неверна. Развели две проверки — холодная A/B
четырьмя контрольными прогонами — codex-cli **0.146.0**, Linux, запуск из (изолированная установка 0.146.0 рядом с глобальной 0.146.1, обе штатны) и
Bash оркестратора, то есть stdout всегда перенаправлен. контрольные прогоны изнутри харнесса, где отказ живёт и на 0.146.1.
- **Нет терминала — нет stdout.** 0.146.0 не пишет в перенаправленный stdout - **Версия ни при чём.** Чистые 0.146.0 и 0.146.1 на этой же машине пишут в
ничего: `codex --version` отдаёт пустой файл и код 0, `--json` — пустой перенаправленный файл штатно: `codex --version > f` — 18 байт, `--json` —
лог. От `-o` это не зависит: без него лог так же пуст, а отчёт `-o` семь строк JSONL с `thread.started` и `command_execution`. Списать отказ
пишется нормально. Сообщения об ошибках уходят туда же, поэтому **любой на версию — первый соблазн: он объясняет всё и не требует ничего. Цена
отказ запуска выглядит одинаково** — пустота и код 1. Так же молча падает проверки — десять минут на установку в отдельный префикс, и она стоит
и запуск из недоверенного каталога (пробовал из `/tmp`: под терминалом того, чтобы гипотеза не уехала в журнал утверждением.
видно `Not inside a trusted directory…`). - **Ось — файл против канала.** Изнутри харнесса (Bash Клода, T3 Code) на
- **Отсюда слепнут три механизма рецепта, и все три — молча.** thread_id 0.146.1: `codex --version > f` — ноль байт и код 0, `codex --version |
«из первой строки stdout-JSONL» взять неоткуда, а на нём висят саморевью cat > g` — 18 байт. То же на полном вызове: `exec --json … > log` — пусто,
этапа 3 и вся ветка триажа через `resume`. Сторож видит файл нулевого он же через `2>&1 | cat > log` — семь строк, thread_id в первой,
размера: первый тик `prev=0`, второй — `STALLED`, то есть ложная тревога на `command_execution` дважды. Отчёт `-o` пишется в обоих случаях: файлы,
десятой минуте любого долгого прогона. Проверка отписки которые Кодекс открывает сам, целы — пропадает унаследованный дескриптор,
(`grep -c '"command_execution"'`) даёт ноль на честной работе — и рецепт когда за ним файл. Stderr так же: `Error loading config.toml…` виден
велит перезапускать дорогое ревью. только через канал. Отключение песочницы Bash ничего не меняет.
- **Промпт читается только из канала.** `codex exec … - < prompt.md` отвечает - **Тот же разрез объясняет и вход.** `exec - < prompt.md` изнутри даёт
`No prompt provided via stdin.` и выходит с кодом 1; `cat prompt.md |` тем `No prompt provided via stdin` и код 1, `cat prompt.md |` работает; вне
же вызовом работает. Обычный файл на входе для 0.146.0 — это «промпта нет». харнесса работают оба. Одна причина на обе находки первой редакции — и обе
Ловушка в диагностике: сообщение то же самое, что при `< /dev/null` снимаются каналом.
(запись 2026-08-02, #39), — и уводит искать закрытый stdin вместо формы - **Правило для этой среды**: и промпт, и лог гнать каналом —
входа. Рецепты в `codex-exec.md` собраны через `cat`, поэтому копирующий `… 2>&1 | cat > "$D/…jsonl"`. Так живут все три механизма рецептов:
агент мимо этого проходит; я собирал команду руками и попал. thread_id из первой строки, сторож по росту лога, проверка отписки через
- **Диагноз без контрольного прогона промахивается по причине.** Первую `command_execution`. Псевдотерминал из первой редакции не нужен: `script`
находку я записал как «пусто, когда задан `-o`»: в падавших запусках давал тот же JSONL ценой `\r` и непереносимости. Сами рецепты
менялось сразу несколько вещей. Развела их серия из четырёх прогонов, `codex-exec.md` вне харнесса верны и не правились.
различающихся ровно одним параметром. Урок общий: пока причина не снята - **Механизм не вскрыт.** Известно поведение, не причина: файл на входе и
таким запуском, она гипотеза. выходе дочернего процесса пуст, канал цел, песочница ни при чём. Пишу это
- **Обход, оба проверены.** Псевдотерминал: `script -qec '<та же команда>' свойством среды и не выдаю за объяснение.
/dev/null > log.jsonl` даёт полный JSONL — `thread.started` с id, - **Цена неверной атрибуции — коммит в репозиторий скилла.** Правило «пока
`command_execution` — и отчёт `-o` на месте; строки заканчиваются на `\r`, причина не снята запуском с одним изменением, она гипотеза» у меня было —
перед `jq` нужен `tr -d '\r'`; только Linux, у macOS другой синтаксис, в и не спасло: внутри серии я честно менял по одному параметру, но вся серия
Git Bash `script` нет. Переносимо и без обвязки — журнал самого Кодекса: целиком стояла в одной среде, и согласованность её прогонов читалась
`~/.codex/sessions/ГГГГ/ММ/ДД/rollout-*-<thread-id>.jsonl`. Имя несёт подтверждением. Отсюда добавка к правилу: среда — тоже параметр, и первый
thread_id (сверил с `thread.started` — совпал), файл растёт по ходу и кандидат на подозрение, когда наблюдение расходится с документацией
содержит записи выполненных команд, то есть закрывает и признак жизни для инструмента. Сняла ошибку чужая проверка, не моя.
сторожа, и доказательство работы вместо отписки. - **Уцелевшая ловушка**: запуск из недоверенного каталога (пробовал из
- **Кандидат в механизм**: `codex-exec.md` держит правило «промпт через `/tmp`) даёт `Not inside a trusted directory and --skip-git-repo-check was
stdin» и приём проверки отписки в редакции, которая на 0.146.0 не not specified.` Снаружи это видно в stderr и коде 1; изнутри харнесса
работает. Правка не написана — решение за владельцем. сливается со всеми прочими отказами в пустоту и код 1.
- Цифры: четыре прогона по односложному промпту («выполни `pwd`»), - Цифры: два захода контрольных прогонов, промпт односложный («выполни
`model_reasoning_effort="low"`; отчёт `-o` — 46 байт, JSONL под `pwd`»), `model_reasoning_effort="low"`; отчёт `-o` — 46 байт в каждом,
псевдотерминалом — 7 строк, журнал прогона — 19 строк. лог через канал — семь строк.