Skip to main content
Claude CodeCodexAI automation

Claude Code і Codex: Прихований перегрів в idle

Неприємне відкриття: Claude Code і Codex можуть запускати приховані фонові процеси та палити CPU навіть у режимі очікування. Для бізнесу це важливо не лише через батарею, а й через ризики в AI-автоматизації, де агент працює без нагляду годинами, потенційно пошкоджуючи обладнання.

Технічний контекст

Я зацікавився цим кейсом не через драму про "згорілий MacBook", а тому що це дуже приземлена проблема для AI-автоматизації. Якщо агентний інструмент у фоні тримає одне ядро на 100%, у вас ламається не тільки ноутбук – ламається довіра до всієї схеми автоматизації.

За повідомленнями користувачів, і Claude Code, і Codex можуть залишати фантомні процеси після начебто звичайної сесії. Зовні все тихо, термінал ніби в idle, а всередині продовжує жити осиротілий Node-процес або хук, який крутить CPU без користі.

Я б дивився в три місця одразу: фонові Node-процеси, автозапускні хуки та занадто довгі сесії з роздутим контекстом. Для Claude Code спільнота вже знайшла робочі рішення: вбивати завислі Node-процеси, вимикати суперсили (superpowers hook), вмикати потоковий режим (streaming mode), обмежувати паралелізм до max-jobs = 2 і очищати контекст через /clear.

Окремо мені сподобався один практичний момент: тайм-аут неактивності на 5 хвилин. Це не "виправлення архітектури", але як запобіжник працює нормально. Особливо якщо у вас кілька агентних каналів і кожен норовить залишити після себе хвіст.

Порада "запускайте у віртуалці" звучить грубо, але в ній є сенс. Коли я проєктую AI-інтеграцію для довгих сесій, я майже завжди намагаюся ізолювати агентний рантайм від основної машини: окрема VM, контейнер, ліміти CPU, моніторинг процесів і жорсткі правила завершення завдань.

Що це змінює для бізнесу

Перше: локальний запуск агентних IDE та CLI більше не можна вважати нешкідливим. Якщо команда будує розробку AI-рішень навколо ноутбуків розробників, приховане навантаження швидко перетворюється на перегрів, шум, розрядження батареї та дивні "плаваючі" баги.

Друге: виграють ті, хто одразу закладає ізоляцію та спостережуваність. Програють ті, хто залишає агентів жити в нескінченних терміналах без тайм-аутів, лімітів і watchdog-перевірок.

Третє: це удар по вартості володіння. Один фантомний процес дешевше помітити на графіку CPU, ніж потім розбиратися з залізом, простоями та втраченим часом команди.

Якщо у вас агенти вже крутяться у фоні й машина поводиться "якось дивно", я б не чекав офіційного виправлення. Можна швидко перезібрати схему так, щоб automation with AI не вбивала робочі станції: у Nahornyi AI Lab ми якраз розбираємо такі кейси руками та збираємо безпечну AI-архітектуру під реальне навантаження, а не під гарне демо.

Ми раніше аналізували баг самоаналізу Claude, де prompt injection провокує фантомні процеси та відмову в обслуговуванні. Та сама динаміка лежить в основі перегріву MacBook, про який зараз ідеться.

Поділитися статтею