Regex-LE: Zero Hassle Regex Extraction & Validation

Find, test, and validate the regex patterns in the current file
Literal patterns, RegExp constructors, ReDoS screening

Useful? A star or rating is how other developers find it — ★ GitHub · ★ Open VSX · ★ Marketplace

What it does

Open any file and run one of three commands. Extract lists every regex pattern found in the document. Test (Ctrl+Alt+R / Cmd+Alt+R) runs a found — or manually entered — pattern against the file content and reports matches with real line/column positions and capture groups (named groups included). Validate checks every found pattern for syntax errors and screens it for catastrophic backtracking, reporting the input that causes it. Works in VS Code and VS Code–based editors like Cursor and VSCodium (installable from Open VSX).

Install

Use it from an AI agent

The same engine runs as an MCP server, so an agent can call it directly instead of you running a command.

extract_patterns(content, format?, filename?, maxResults?)

Returns every pattern with its flags, 1-based position and a ReDoS verdict, so "are any of the regexes in this file dangerous?" is one call rather than two. A verdict that reports a blow-up carries the witness that caused it, so an agent can check the finding instead of trusting it.

The server takes content and returns data — it reads no files and makes no network requests of its own. Published as regex-le-mcp on npm and as io.github.nolindnaidoo/regex-le in the MCP registry.

{
  "mcpServers": {
    "regex-le": {
      "command": "npx",
      "args": ["-y", "regex-le-mcp"]
    }
  }
}

npm install -g regex-le-mcp

{
  "mcpServers": {
    "regex-le": { "command": "regex-le-mcp" }
  }
}

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y regex-le-mcp

What gets extracted

Extraction scans the whole document, so constructors split across lines are found too. The document's language chooses which spellings to look for:

A language nothing recognises is not a refusal — every spelling above is looked for. Naming it buys precision: a Python file is not scanned for bare /…/, so #!/usr/bin/env python stops reading as a pattern.

What is deliberately not extracted:

• Division, dates, and filesystem paths (a / b, 10/29/2025, /usr/local/bin): a / preceded by an identifier, number, ), ], ., or another / is not treated as a regex — after keywords like return, it is. That question is only asked where a bare /…/ is legal.
• Candidates that are not a well-formed regular expression in any of these languages, or with invalid/duplicate flags. Another language's spelling is not a syntax error: re.compile(r'(?P<word>\w+)+@') is reported as written, and still flagged.
• Constructor calls whose pattern argument is a variable, or a template literal with a ${…} substitution. String literals, static template literals and String.raw`…` are read.
• Flags, on anything but a JavaScript literal or constructor: every other language sets them with constants, builder methods or an inline (?i) rather than a string argument.
• Anything written in a comment or a string. A JSDoc block explaining a hazard, a commented-out line, a Python docstring with an example — none of them is code, and reporting one fails a build over a sentence. The rule is about where a candidate starts, so re.compile(r"(a+)+b") keeps its quoted argument while a docstring holding that whole line is prose. Only when the language is known: a document nothing recognises is scanned as written, because a comment rule guessed from the wrong grammar would drop real patterns instead of phantom ones.

Duplicate pattern+flags pairs are listed once. This is lexing by heuristic, not a parser for nine languages: a slash inside a string can still be picked up when its context looks expression-like.

ReDoS screening

Validate (and Test, before running a risky pattern) reports a pattern only when an input was found that demonstrably drives it into catastrophic backtracking — and reports that input alongside it, as the witness.

Your pattern is never run. It is compiled to an automaton, and that automaton is walked the way a backtracking engine walks one — depth-first, every edge in order, a dead end unwound rather than remembered — while the steps are counted. An attack string is built, pumped at two lengths, and measured against a step budget. So a finding is falsifiable: run the witness and watch.

Nothing is reported on the strength of how a pattern is shaped. Shape is a poor predictor in both directions: ^[a-z0-9]+(?:-[a-z0-9]+)*$ looks dangerous and is not, because every iteration must eat a - the inner class cannot produce, while (.*a){20} looks bounded and is not. A separator forcing the split is a fact about strings, so no test on syntax settles it.

Silence is not a clearance. A pattern this cannot read — a backreference, lookaround, syntax it does not parse — comes back as not decided: <reason>, never as safe.

The reports also include a rough performance score based on execution time relative to input size — treat it as a hint, not a benchmark (memory is not measured).

The CLI

The same lint runs from a terminal or a shell pipeline: a Rust CLI in crate/, sharing one corpus with the extension — crate/fixtures/ — so the two can never read a document differently.

regex-le .                      # every vulnerable pattern in the tree
regex-le --severity high src/   # only the exponential shapes
regex-le --all src/             # every pattern, vulnerable or not
regex-le mcp                    # the same lint over MCP on stdio

Exit codes: 0 nothing vulnerable, 1 at least one finding, 2 the question was malformed — so regex-le . || exit 1 is a CI gate.

It ports the lint half, not the tester. Running a pattern against your text with JavaScript semantics needs a JavaScript engine, and getting it nearly right would mean the two frontends reporting different matches for the same pattern. Testing is an editor activity; keep it here. The lint needs no engine at all — the ReDoS verdict walks an automaton built from the pattern text, under a step budget — which is what makes it a cheap deterministic CI step.

It reports what it can demonstrate and refuses what it cannot read, exactly as the screening in this extension does.

Commands

Settings

Languages

Twelve languages besides English:

German · Spanish · French · Indonesian · Italian · Japanese · Korean · Portuguese (Brazil) · Russian · Ukrainian · Vietnamese · Chinese (Simplified)

Both halves are covered — the manifest (command titles, setting names and descriptions) and everything shown while the extension runs (notifications, the status bar, quick-picks and prompts). The extension follows VS Code's display language, so it matches whatever the editor is already set to; no setting of its own.

Privacy & security

• No network access. The extension never sends data anywhere. The telemetryEnabled setting only writes events to a local Output Channel you can inspect (Regex-LE Telemetry).
• Testing a pattern the ReDoS screen rates high-severity asks for confirmation first.
• The MCP server holds the same line. It takes content as an argument and returns data: no filesystem access, no network calls, no telemetry. Your agent already has file-read tools, so duplicating them inside the server would add a path-traversal surface for no capability. check:mcp-bundle fails the build if the server ever imports something that could reach either.
• Error notifications redact home directories and credential-shaped fragments.

Documentation

Performance

Median of 7 runs after warmup, on Apple M5 Pro, 24 GB RAM, Node 24.3.0. Inputs are generated by scripts/benchmark.ts rather than checked in, so the sizes above are exactly what was measured. Reproduce with bun run benchmark.

These are machine-specific and are not asserted in CI — a benchmark that gates a build only tells you how busy the runner was.

Testing

261 test cases across 17 files, plus an integration suite that runs in a real VS Code extension host and an end-to-end test that installs the built .vsix into a clean profile.

Generated from a real run — coverage/coverage-summary.json and coverage/test-results.json — by scripts/coverage-readme.js; CI fails if this section drifts. Reproduce with bun run test:coverage, and the case count is the one vitest prints.

More from the LE family

Sixteen single-purpose tools for the work in front of every model. Each ships a Rust CLI and an MCP server. One page: letools.dev

Get it out

• String-LE — Extract every string in a codebase, with its position, so a person can read them
• Numbers-LE — Extract every hardcoded number in a codebase, so a person can check them
• Units-LE — Extract every quantity with its unit, normalized, and refuse the ambiguous ones by name
• Dates-LE — Extract every date and timestamp, and the exact instant each one resolves to
• IDs-LE — Extract every UUID, ULID, NanoID, ObjectId and Snowflake, and decode the time inside
• IPs-LE — Extract every IP address, CIDR block and MAC, normalized and classified by scope
• URLs-LE — Extract every URL in a codebase, with its protocol and exact position
• Paths-LE — Extract every file path in a codebase, and say whether it still points at anything
• Colors-LE — Extract every color in a codebase, and say which ones are not in your palette

Check it

• Regex-LE — Find every regex in a codebase, and report which can be driven into catastrophic backtracking
• Versions-LE — Find where one dependency is constrained differently across a repository's manifests
• i18n-LE — Identify the i18n library a project uses, then audit its catalogs by that library's rules
• Scrape-LE — Check whether a page is scrapeable before the scraper is written, and say when it cannot tell

Guard it

• Secrets-LE — Find hardcoded credentials in a codebase, and never print one into the report
• EnvSync-LE — Compare the dotenv files in a tree, and say which keys are missing from which
• Unicode-LE — Find the Unicode that hides meaning — bidi controls, invisibles, homoglyphs, mixed scripts

Each stands on its own: no shared crate, no published core. Where two of them agree, it is because the same answer was right twice.

Contact — nolindnaidoo.com · GitHub · LinkedIn

Also by nolindnaidoo

Rust — pixelcoords and pixelactions are one loop: pixelcoords answers where, pixelactions acts there. Their own tools, their own voice — not part of the LE family.

• pixelcoords — Freeze your screen, mark regions, get pixel-exact coordinates and crops pixelcoords.dev · crates.io · docs.rs
• pixelactions — Consume human-verified coordinates, perform the interaction, confirm it landed pixelactions.dev · crates.io · docs.rs

License

MIT © nolindnaidoo