Skip to content

На macOS плагин не запускается: нет timeout, и Codex читается как «не залогинен» - #3

Merged
szarkans merged 1 commit into
szarkans:mainfrom
jojoprison:fix/macos-timeout
Aug 20, 2026
Merged

Conversation

@jojoprison

Copy link
Copy Markdown
Contributor

Поставил плагин себе, запустил — и он отказался работать. Оказалось, на macOS он не работает вообще. Пишу по-русски, коммит на английском, как и весь репо.

Что происходит

timeout — это GNU coreutils. На чистом macOS её нет; Homebrew ставит её как gtimeout, а на многих машинах нет ни того, ни другого. Отказ при этом тихий и полный:

timeout 10 codex login status 2>&1 | grep -qi 'logged in'

Шелл пишет command not found, grep читает пустой stdin, probe.sh печатает codex: NOT LOGGED IN. Дальше срабатывает гейт самого скилла — «No Codex, or not logged in → stop» — и плагин целиком отказывается запускаться.

Замер на моей машине (macOS, codex-cli 0.144.6, залогинен):

1. как есть (probe.sh:25)  → codex NOT LOGGED IN
2. что отвечает codex      → Logged in using ChatGPT
3. с shim-функцией         → codex OK

То есть Codex подключён, а плагин его не видит и стопорится.

Почему нельзя просто убрать timeout

Он используется в четырёх местах, и в двух из них он не косметика — это написано в комментарии над multi_run_openrouter твоей же рукой: Claude Code не падает быстро на плохом ключе, он молча ретраит и не возвращается. Без жёсткого лимита этот вызов висит вечно.

Поэтому фолбэк не «пропустить таймаут», а «сделать его самим».

Что в патче

multi_timeout в providers.sh (он и так подключается из probe.sh, ask.sh, setup.sh): берёт timeout, если он есть, иначе gtimeout, иначе своя реализация через фоновый запуск и сторожа. Все четыре вызова переведены на неё — probe.sh ×2 (codex, opencode), providers.sh ×2 (openrouter, gemini).

Дифф: +37 / −4, два файла, ни одного нового.

Проверено на машине, где нет ни timeout, ни gtimeout

Проверка Результат
быстрая команда отдаёт вывод echo hellohello
код возврата успешной команды true → rc=0
код возврата упавшей false → rc=1
зависшая реально убивается sleep 30 с лимитом 2с → убито за 2с, rc=143
работает в конвейере тот самый вызов из probe.sh → codex распознан

Последняя строка важнее прочих: shim, который «не падает», но и не убивает зависший процесс, был бы хуже исходного бага — он бы молча вернул openrouter к бесконечному ретраю.

Воспроизвести можно так (на маке без coreutils):

command -v timeout gtimeout || echo "нет ни того, ни другого"
timeout 10 codex login status 2>&1 | grep -qi 'logged in' && echo OK || echo "NOT LOGGED IN"
codex login status

Отношение к PR #2

Ветка отведена от main, а не от feat/safe-paths-preflight — они независимы, порядок влития любой, стека не будет. Этот PR я бы взял вперёд того: там гипотетический риск, здесь продукт не стартует на целой платформе.

`timeout` is GNU coreutils. A stock macOS does not have it, Homebrew installs
it as `gtimeout`, and many machines have neither. The failure is silent and
total:

  timeout 10 codex login status 2>&1 | grep -qi 'logged in'

The shell writes 'command not found', grep reads empty stdin, and the probe
reports 'codex: NOT LOGGED IN' on a machine where `codex login status` answers
'Logged in using ChatGPT'. The review skill then hits its own gate — 'No Codex,
or not logged in -> stop' — so the whole plugin declines to run. Measured on
macOS with codex-cli 0.144.6, logged in: NOT LOGGED IN before, OK after.

The same call is used for OpenRouter and Gemini, where the timeout is not
cosmetic: the comment above multi_run_openrouter says it outright — Claude Code
does not fail fast on a bad key, it retries silently and never returns. So the
fallback runs the timeout itself rather than dropping it.

multi_timeout picks timeout, then gtimeout, then a background-and-watchdog
implementation. Verified on a machine with neither: a fast command keeps its
output and exit code, a failing one keeps its non-zero code, `sleep 30` under a
2s limit dies in 2s with rc=143, and the pipeline above resolves correctly.
@szarkans
szarkans merged commit 4001743 into szarkans:main Aug 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants