## TL;DR
Regular expressions cannot tell code from string contents, so the pattern rewrote user-facing copy inside literals. Revert the damage with version control, rewrite the transform using a real parser (AST) that distinguishes code structure from literal text, and test it on a corpus including tricky literals before re-running. Regex is for text; code needs a parser.

## The query

```text
agent's regex codemod matched inside string literals and corrupted user-facing copy
```

## Use this when

- Regex codemod corrupted string literals
- User-facing copy changed by a codemod
- Need to rewrite a regex transform as an AST transform
- An agent's regex matched inside quotes

## Not for

- Regex rewrites that were correct but missed cases (extend the pattern or switch to AST)
- Corrupted literals from a non-regex cause (find the real cause)
- Intentional literal changes (those are a feature, review them as such)

## Steps

### 1. Find and revert the damage

```bash
git diff | grep -A2 -B2 "^[+-].*\"" | head -60
```

Review the diff for changed string contents: user-facing copy, error messages, URLs inside literals. Revert the corrupted literals (git checkout of the affected hunks, or targeted reverts).

Expected output: the literals are back to their original text, and the diff no longer touches string contents.

### 2. Rewrite the transform on an AST

Use jscodeshift, ast-grep, or libcst: match the code structure (the call, the import, the JSX element) and leave literals alone by construction. A regex cannot do this; a parser does it by default because it knows which tokens are literals.

Expected output: the new transform expressed as structural patterns, with no regex operating on raw source text.

### 3. Test on a corpus with adversarial literals

Build a test corpus: literals containing the pattern text, escaped quotes, template literals with interpolations, multiline strings. Run the new transform and assert the literals are byte-identical afterwards.

Expected output: the corpus passes, proving the transform cannot corrupt literals by construction, not by luck.

### 4. Re-run and diff carefully

Run the AST transform on the real tree and review the full diff. Expected output: only intended code changes, zero literal changes. Any literal in the diff is a bug in the transform: stop and fix it.

### 5. Ban regex codemods on code in the agent's procedure

The agent's rule: regex may search code, but only a parser may rewrite it. Regex rewrites need a written justification and a literal-corpus test.

Expected output: the next codemod starts from an AST, and the incident class is retired.

## Tool compatibility

jscodeshift and ast-grep (javascript/typescript), libcst (python). The regex-vs-AST principle is language-agnostic.

## Variant phrasings

### regex codemod corrupted string literals

Steps 1 and 2: revert the literals, rewrite on an AST.

### codemod changed user-facing copy

Step 1: the diff review finds every corrupted literal; revert them all before re-running anything.

### rewrite regex codemod as jscodeshift

Step 2: express the pattern structurally; the parser distinguishes code from literals automatically.

## Why it happens

Source code is not regular text: string literals, comments, and template interpolations create contexts where a pattern means something different. Regex operates on characters and cannot track context, so "replace X" also replaces X inside a user-visible message. Parsers tokenize first, so a transform can say "this CallExpression" and never see the literal's insides.

## Edge cases

- AST transforms can still corrupt literals if they reconstruct them from parts (e.g. rebuilding a template literal): assert literal byte-identity in tests.
- Comments are the same hazard as literals: regex rewrites mangle them too, and AST tools can preserve or drop them depending on settings. Check.
- Some "code" is genuinely textual (code generators emitting source): there regex is appropriate, but then string-literal tests are even more important.

## Provenance

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