Quote Guard: FSM on PreToolUse Catches an Unclosed Quote Before Bash Hangs

⚡ The key points in 5 seconds

• Quote Guard intercepts the LLM agent's command with a PreToolUse hook — before the bytes are handed to the OS.
• Validation moved from regexes to a deterministic finite state machine with three grammars.
• Unknown tools are checked with a "double lock": against both posix and powershell at once.

🔍 What happened

An engineer under the handle SkyAngels20 analyzed on Habr a case: an LLM agent assembles a command for the terminal, loses the closing quote — and the runtime stalls. Bash, and according to the author PowerShell too, decides the input is multi-line, prints >> and waits for a closing quote from stdin. The agent reads the process synchronously through a pipe, EOF never arrives, the session timeout burns out, the process crashes.

The author called his solution Quote Guard. It's a finite state machine on the PreToolUse hook: the string is checked before it goes to the OS. The lexer drives it through the states NORMAL, IN_DOUBLE_QUOTES, IN_SINGLE_QUOTES, ESCAPE and maintains three isolated grammars — posix, powershell, cmd. The regexes are gone.

Why not count quotes with count % 2 == 0? The author presents an isomorphism matrix. The string dir "C:\" is safe in PowerShell: there a backslash is just an ordinary path separator. In Bash the same \ escapes the closing quote — and the shell waits forever. Second example: echo "a"b"` — in PowerShell the backtick escapes, in Bash it triggers command substitution. Guessing the shell from the host OS is pointless: in Windows containers Bash is running, in WSL it's PowerShell.

For unknown tools the author built Strict Intersect, a "double lock". The command is run through posix and powershell at once. safe + safe — pass, unsafe + unsafe — block. A mismatch is the most interesting case: Exit 2 and a machine-readable hint to the model such as [quote-guard BLOCKED]:... The string is safe in PowerShell but hangs POSIX. Fix: set QUOTE_GUARD_MAP=MyTool=powershell. Separately the author explains how he closed the heredoc hole that silently let unclosed quotes through, and why 122 adversarial tests on Python and Node.js are needed.

🧠 Our take

Agents increasingly poke the terminal themselves instead of sitting in a chat. While there's just one agent and it's supervised, a hang is a nuisance. When there are ten of them in CI, it's downtime. Our take: this news isn't about quotes, it's about trust in the model's output moving out of the prompt and into the infrastructure, into a hook before execution. A request to "please check your quotes" gives no guarantees. A state machine does.

For those building agents, this is a ready-made pattern: validate not the text, but the grammar of the target environment. And refuse in a structured way so the model can fix it on the second attempt. We believe the main thing here is the error format. Not "invalid input", but an instruction with an environment variable that the agent will actually read.

Those who roll agents into production win. Naive regex validators lose: they're either bypassed by a false positive, or they fail to catch a real deadlock. The author's logic is simple — an engineer disables the protection after the first false positive. That's the price of a bad check.

⚠️ What we don't know

The item has no link to the repository — only an architecture description. There are no figures on the lexer's overhead, no data on how often agents actually lose quotes in production. I'd verify by hand the claim that PowerShell also drops into multi-line mode: the behavior depends on the version and the launch mode. And it's a single voice, a sandbox case, not an independent verification.

Forecast: within a quarter, similar grammar validators will appear in off-the-shelf agent frameworks — provided the case gets picked up and the code is open-sourced.

Disclaimer: not officially confirmed, a single source — the engineer's write-up on Habr, no independent checks.

Source: Habr