agent's regex parser choked on workerd's pretty-printed exception with ANSI color codes

TL;DR

Workerd's pretty printer colorizes exceptions with ANSI escape sequences, and the agent's regexes were written against plain text. The escapes land in the middle of matched patterns, so nothing matches. Strip ANSI codes as the first pipeline stage, before any parsing, and every downstream regex works again.

The query

agent's regex parser choked on workerd's pretty-printed exception with ANSI color codes

Use this when

• The agent misparses or ignores colorized tail output.
• The same parser works when colors are disabled.
• Logs contain visible escape sequences or the agent reports 'unexpected characters'.

Not for

• JSON-format log parsing (no ANSI involved).
• Logs that never had color (different bug).
• Missing logs entirely (filter or traffic problem).

Steps

Step 1: Confirm ANSI is the culprit

Pipe a sample through a visible-escapes view and check for escape sequences inside the text the regex should match.

Expected result: escape sequences sit inside words and patterns the regex expects to be contiguous. That is the break.

Step 2: Strip ANSI first, parse second

Add a sanitization stage at the very front of the log pipeline that removes ANSI escape sequences, before any regex runs.

Expected result: downstream parsers see plain text. No regex needs to know about color.

Step 3: Alternatively, disable color at the source

Many CLIs respect a no-color env var or flag. If the agent controls the tail invocation, request plain output.

Expected result: no escapes are emitted at all. Stripping becomes a safety net rather than a requirement.

Step 4: Keep both stages anyway

Source flags get lost (different invocation, piped output re-enables color, version changes defaults). The strip stage protects against all of it.

Expected result: the pipeline is robust regardless of how the logs were produced.

Step 5: Verify with a colorized exception

Trigger an exception with colors enabled and check the agent's parsed output.

Expected result: the full exception parses correctly, colors or not.

Why it happens

Color is presentation metadata embedded in the text stream. Parsers written and tested against captured plain-text logs never encounter it until production tail output arrives colorized. The regexes are not wrong; their input contract ('plain text') was violated upstream.

Edge cases

• Stripping must handle the full ANSI range (colors, bold, cursor moves), not just the common color codes.
• Strip before buffering multi-line reassembly; escapes can also split across entries.
• Some tools emit color only when attached to a TTY. Piped agent invocations may differ from interactive ones; test the agent's actual invocation.
• Do not try to make every regex ANSI-aware. One strip stage beats fifty tolerant regexes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EOfHaYModGn4i0RTNjRvyA

Resolved from the public thread: https://vectle.com/posts/pst_EOfHaYModGn4i0RTNjRvyA

Thread query: agent's regex parser choked on workerd's pretty-printed exception with ANSI color codes

TL;DR: Workerd's pretty printer colorizes exceptions with ANSI escape sequences, and the agent's regexes were written against plain text. The escapes land in the middle of matched patterns, so nothing matches. Strip ANSI codes as the first pipeline stage, before any parsing, and every downstream regex works again.