Технічний контекст
Я натрапив на досить прикрий баг у Claude Code: під час сесії раптово перестає нормально відображатися історія. Іноді я бачив лише останню відповідь асистента. Іноді ще гірше: моє повідомлення зникало, а на екрані залишався тільки блок thinking, ніби інтерфейс вирішив, що контекст мені більше не потрібен.
Одразу уточню важливу річ. На момент публікації я не маю підтвердження цього конкретного кейсу в офіційній документації Anthropic або в changelog. Пошук показує, що у Claude Code останнім часом справді були проблеми з UI: мерехтіння (flicker), артефакти рендерингу, стрибки layout, дивна поведінка довгих сесій. Але саме сценарій зі зникаючою історією та env-прапором виплив поки що як користувацький workaround, а не як задокументована фіча.
Проте фікс у мене спрацював. У settings.json потрібно додати новий прапор середовища:
- {"env": {"CLAUDE_CODE_NO_FLICKER": 1}}
Після цього Claude Code перемикається на новий режим рендерингу. За відчуттями, саме його нещодавно додали в клієнт: з'являються клікабельні блоки, тулколи можна згортати й розгортати мишкою, а головне, інтерфейс знову починає жити як нормальний інструмент, а не як полтергейст у терміналі.
Я б описав це так: баг виглядає як проблема не моделі, а шару відображення. Сам Claude може продовжувати думати й генерувати відповідь коректно, але UI руйнує досвід роботи. І тут багато хто за звичкою звинувачує модель, хоча ламається саме прошарок між виведенням, історією та інструментальними блоками.
Якщо ви працюєте в довгих кодових сесіях, особливо з tool use, агентними проходами та частими правками файлів, такий збій дратує подвійно. У такі моменти я швидко перемикаюся на Codex або інші CLI-інструменти, тому що коли інтерфейс ховає контекст, продуктивність летить у прірву.
Що це змінює для бізнесу та автоматизації
На перший погляд, це дрібниця на рівні інтерфейсу. На практиці — ні. Якщо у команди розвалюється вікно історії в основному AI-інструменті, страждає не лише комфорт розробника, а й уся ШІ-автоматизація навколо коду: рев'ю, генерація патчів, агентні пайплайни, супровід внутрішніх утиліт.
Я це бачу регулярно в проєктах, де впровадження ШІ впирається не в якість моделі, а в надійність робочого контуру. Бізнесу байдуже, чому інженер втратив 20 хвилин. Через latency, поганий промпт чи багнутий рендер. Результат один: менше довіри до інструменту й відкат назад до ручної роботи.
Виграють тут ті команди, у яких є запасний маршрут. Один агент глючить, UI поводиться дивно — отже, в AI-архітектурі має бути план Б: інший інтерфейс, інший провайдер, fallback через CLI, локальні логи, збереження історії поза клієнтським вікном. Я саме так і збираю архітектуру ШІ-рішень у Nahornyi AI Lab, тому що красиві демки рідко переживають реальну експлуатацію.
Програють ті, хто будує процес на одному чарівному інструменті без страховки. Сьогодні у вас зникають повідомлення в Claude Code. Завтра в іншого вендора змінюється формат tool call. Післязавтра API віддає новий тип системної події. Якщо інтеграція штучного інтелекту тримається на надії, а не на інженерії, все це починає сипатися каскадом.
Мій висновок простий: фікс із CLAUDE_CODE_NO_FLICKER=1 варто спробувати одразу, якщо ви спіймали цей баг. Але стратегічно важливіший не сам прапор, а урок. Для розробки ШІ-рішень потрібен не лише сильний model layer, а й стійкий операційний шар: клієнти, логи, fallback-сценарії, моніторинг і зрозуміле перемикання між інструментами.
Я, Вадим Нагорний з Nahornyi AI Lab, такі штуки зазвичай не обговорюю в теорії, а відловлюю прямо в живих пайплайнах, де ШІ-автоматизація має працювати щодня, а не лише під час дзвінка. Якщо хочете розібрати ваш кейс, підібрати надійну схему впровадження або зібрати нормальну AI-архітектуру без крихких місць, пишіть. Із задоволенням подивлюся ваш проєкт разом з вами.