# Quote Guard: FSM на PreToolUse ловит незакрытую кавычку до зависания Bash

> 2026-10-29 · AI Release · @ai_release1

> #AI-агенты #Bash #FSM #безопасность #AI #ClaudeCode #DevTools #разработка

### ⚡ Главное за 5 секунд - Quote Guard перехватывает команду LLM- агента хуком PreToolUse — до передачи байтов в ОС. - Валидация переехала с регулярок на детерминированный конечный автомат с тремя грамматиками. - Неизвестные инструменты проверяются «двойным замком»: сразу по posix и powershell. ### 🔍 Что случилось Инженер под ником SkyAngels20 разобрал на Хабре кейс: LLM-агент собирает команду для терминала, теряет закрывающую кавычку — и рантайм встаёт. Bash, а по словам автора и PowerShell, решает, что ввод многострочный, печатает `>>` и ждёт закрывающую кавычку из stdin. Агент читает процесс синхронно через пайп, EOF не приходит, таймаут сессии выгорает, процесс падает. Решение автор назвал Quote Guard. Это конечный автомат на хуке PreToolUse: строка проверяется до того, как уйдёт в ОС. Лексер ведёт её через состояния `NORMAL`, `IN_DOUBLE_QUOTES`, `IN_SINGLE_QUOTES`, `ESCAPE` и держит три изолированные грамматики — posix, powershell, cmd. Регулярки выброшены. Почему не считать кавычки через `count % 2 == 0`? Автор показывает матрицу изоморфности. Строка `dir "C:\"` в PowerShell безопасна: обратный слэш там обычный разделитель пути. В Bash тот же `\` экранирует закрывающую кавычку — и шелл ждёт вечно. Второй пример: `echo "a`"b"` — в PowerShell бэктик экранирует, в Bash запускает command substitution. Угадывать шелл по хостовой ОС бесполезно: в контейнерах Windows крутится Bash, в WSL — PowerShell. Для неизвестных инструментов автор сделал Strict Intersect, «двойной замок». Команда гоняется сразу по posix и powershell. safe + safe — пропуск, unsafe + unsafe — блок. Расхождение — самый интересный случай: Exit 2 и машиночитаемая подсказка модели вроде `[quote-guard BLOCKED]:... Строка безопасна в PowerShell, но вешает POSIX. Лечение: задайте QUOTE_GUARD_MAP=MyTool=powershell`. Отдельно автор рассказывает, как закрыл дыру с heredoc, которая молча пропускала незакрытые кавычки, и зачем 122 состязательных теста на Python и Node.js. ### 🧠 Наш разбор Агенты всё чаще дёргают терминал сами, а не сидят в чате. Пока агент один и под присмотром, зависание — досада. Когда их десяток в CI, это уже простой. Наша оценка: новость не про кавычки, а про то, что доверие к выводу модели переезжает из промпта в инфраструктуру, в хук перед исполнением. Просьба «пожалуйста, проверяй кавычки» гарантий не даёт. Автомат даёт. Для тех, кто строит агентов, это готовый паттерн: валидировать не текст, а грамматику целевой среды. И отказывать структурированно, чтобы модель исправилась со второй попытки. Мы считаем, что главное здесь — формат ошибки. Не «invalid input», а инструкция с переменной окружения, которую агент реально прочитает. Выигрывают те, кто катит агентов в прод. Проигрывают наивные валидаторы на регулярках: их либо обходят ложным срабатыванием, либо они не ловят настоящий дедлок. Логика автора проста — инженер отключает защиту после первого false positive. Это и есть цена плохой проверки. ### ⚠️ Чего мы не знаем В поводе нет ссылки на репозиторий — только описание архитектуры. Нет цифр по накладным расходам лексера, нет данных, как часто агенты реально теряют кавычки в проде. Утверждение, что PowerShell тоже уходит в многострочный режим, я бы проверил руками: поведение зависит от версии и режима запуска. И это один голос, кейс из песочницы, а не независимая проверка. ### 💬 О чём спорить - Чинить это хуком перед запуском или внутри самого шелла — обёрткой с таймаутом и принудительным EOF? - Блокировать команду, которая безопасна в PowerShell, но вешает POSIX, или отдавать решение человеку? - 122 состязательных теста — достаточная гарантия для предохранителя, который стоит на пути у всех команд агента? **Прогноз:** в течение квартала похожие грамматические валидаторы появятся в готовых агентных фреймворках — при условии, что кейс подхватят и откроют код. **Дисклеймер:** официально не подтверждено, один источник — разбор инженера на Хабре, независимых проверок нет. **Источник:** Хабр

[Источник](https://habr.com/ru/articles/1101048/)