The agent loop in this tool had a small defensive heuristic. After the AI's first response, it scanned the text for words like scrambled, garbled, fragment, and keyboard issue. If it found any, it auto-cleared the session on the theory that a silent SDK-resume had failed and the AI was now confused about the user's actual question.
The code was three lines long, sat in the assistant-text handler, and had a comment explaining the intent. From the inside it looked sensible: when the AI says "your input looks scrambled," yeah, something broke — clear the session and let the user re-type.
The probe was a content review of the assistant-text handler, looking for content-regex violations of the codebase rule about using language-model interpretation instead of pattern matching. The regex was the first thing I noticed. The probe didn't take more than a minute to find — but it took looking at it through "what real responses match this?" rather than "what malicious responses match this?"
This tool is a Workers' Compensation case manager. The documents it processes are medical reports, deposition transcripts, X-ray findings, expert opinions. Half the words in the trigger regex appear in every other document.
- "Bone fragment" in a medical report describing an injury.
- "DNA fragment analysis" in a forensic record.
- "The defendant claimed a keyboard issue caused the email" from a deposition transcript.
- "Use scrambled eggs as a comparison" — okay, that one's unlikely, but the word "scrambled" appears in case narratives describing scrambled call lists, scrambled records, scrambled phone messages.
Every one of these triggers the auto-clear. The attorney sends a question about a medical report. The AI's response mentions "the bone fragment shown in the X-ray." The session clears. The attorney sees "Session had stale data. Clearing — please re-type your query." Their working context evaporates. They re-type. The next response mentions "fragment" again. Same thing.
The shape this catches
This is a specific instance of a broader anti-pattern: using a content-regex to approximate a structural signal that's already detectable.
The intent of the heuristic was to detect a specific runtime condition — the SDK was asked to resume session A, but it created session B instead (a silent resume failure). That condition has an explicit structural signal: at the init-message handler, the code already checks whether the returned session_id matches the requested one. When they differ, the code logs a "resume-fail" entry. The signal is there. The information is there. The handler that watches for it is right there.
The garbled-session regex was a heuristic for what the structural detector already knew. If you want to clear the session on resume failure, do it at the structural site. Don't scan downstream output for words that approximate the failure.
This anti-pattern shows up whenever someone reaches for regex to detect a runtime condition that has a structural representation. Other examples:
- Parsing process output to detect "did the command succeed?" instead of checking exit code.
- Regexing HTTP response bodies for "error" instead of checking status code.
- Scanning log lines for "failed" instead of subscribing to a structured event stream.
The cost in each case is the same: the regex captures false positives whenever the matched word appears in legitimate content. The structural signal is more reliable, faster, and doesn't false-positive.
The fix
Delete the regex. The two lines that did the auto-clear become a single pass-through to the existing print logic.
The legitimate use case the heuristic was meant to catch — session was truly corrupted and the AI is confused — now requires the attorney to run aaicase --logout manually. That was always preferable to a silent auto-clear the attorney didn't ask for. The attorney sees the AI being confused (which they can recognize in the rendered output), runs the logout command, retries. Same end result, no false-positive on every other case file.
If a future probe shows that resume failures are common enough to warrant automatic recovery, the right implementation is at the structural detection site:
if (message.type === "system" && message.subtype === "init") {
const requestedId = opts.resume || null;
const returnedId = message.session_id;
if (requestedId && requestedId !== returnedId) {
// Currently logs only. If we want to clear and warn, this is the
// place — not by scanning later assistant text.
}
}That handler already runs. It already has the information. Acting on it is one branch, not a content-regex on every assistant message.
What this round didn't find
The rest of the agent dispatch logic checked out cleanly. The humanizeToolUse helper uses regex extensively, but every pattern matches structural CLI invocations the tool produces itself — merus-fetch /uploads/index, aai-bind, etc. — not user-supplied content. That's a fine use of regex. The session-file load path already has the negative-age guard from an earlier release. The session-ownership check (don't reuse a session another process is holding) is sound.
One bug, well-contained, easy to fix once named. The interesting part was the false-positive analysis: realizing that the trigger words were not adversarial inputs but ordinary case content. That's the kind of finding that only surfaces when you ask "what does my actual data look like?" rather than "what could an attacker put here?"
The version on the install URL is 4.5.102.