regex-le-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@regex-le-mcpAre any regex patterns in this code vulnerable to ReDoS?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 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).
Related MCP server: RegexForge
Install
Where | What you get | Install |
VS Code | The lint and the tester, in your editor | |
Cursor, VSCodium, Windsurf | The same extension | |
A terminal or a CI step | The same run over a whole tree, with exit codes |
|
Any MCP agent, via Node |
|
|
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.
Editor | How |
VS Code 1.101+ | Nothing to install — the extension registers |
Claude Code |
|
Cursor, Windsurf, anything else | point it at |
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.
Most hosts read a JSON config. Add one entry:
{
"mcpServers": {
"regex-le": {
"command": "npx",
"args": ["-y", "regex-le-mcp"]
}
}
}-y skips the install prompt on first run. Pin a version if you would rather not track releases — regex-le-mcp@2.6.0.
Prefer not to go through npx on every launch? Install it once and point at the binary instead:
npm install -g regex-le-mcp{
"mcpServers": {
"regex-le": { "command": "regex-le-mcp" }
}
}It speaks MCP over stdio and needs no environment variables, no API key and no configuration of its own. To check it before wiring it into anything:
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y regex-le-mcpThat prints the tool list and exits — if you see extract_patterns, the server works.
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:
Language | Form | Example |
JavaScript, TypeScript, Ruby | Literal |
|
JavaScript, TypeScript | Constructor |
|
JavaScript, TypeScript | Bare constructor call |
|
Python |
|
|
Rust |
|
|
Go |
|
|
Java |
|
|
Ruby |
|
|
PHP |
|
|
C# |
|
|
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 likereturn, 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 andString.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).
Across a folder or a workspace
Extract and Validate read the document you have open. Each has a form that reads many files from disk and gives one report.
The whole workspace: run
Regex-LE: Extract Patterns from WorkspaceorRegex-LE: Validate Patterns in Workspacefrom the command palette.One folder: right-click it in the Explorer and choose
Extract Patterns from FolderorValidate Patterns in Folder. The same two commands in the palette ask for a folder.
Extract
A project writes the same pattern in many places, so the report is the distinct patterns and where each one is, the most widely used first:
# Regex-LE workspace report
`my-project` · 3 file(s) read · 3 distinct pattern(s) in 3 file(s)
| Pattern | Files |
|---|---|
| `/\d+/g` | 2 |
| `/\d+/` | 1 |
| `/^x$/` | 1 |
## `/\d+/g` (2)
- `src/a.ts` · **1:11**
- `src/b.ts` · **1:11**
## `/\d+/` (1)
- `src/c.py` · **2:5**
## `/^x$/` (1)
- `src/a.ts` · **2:11**Two patterns are the same when their text and flags are, so /\d+/g and /\d+/ are listed apart. A pattern is counted once per file, at the first place it is written there.
Validate
The report opens with a table of the files that hold something to look at, then lists the patterns that can hang:
# Regex-LE workspace report
`my-project` · 3 file(s) read · 5 pattern(s), 1 can hang, 1 not checked
| File | Patterns | Can hang | Not checked |
|---|---|---|---|
| `src/a.ts` | 2 | 1 | 0 |
| `src/b.py` | 2 | 0 | 1 |
> 1 other file(s) hold only patterns with no finding.
## `src/a.ts` (1)
- **2:14** · `/(a+)+$/` · can hang (high): exponential backtracking: 2000000 steps on 41 characters, against 229328 on 20 · complexity 0/100Can hang means an input was found that drives the pattern into backtracking, the same search ReDoS screening describes. Not checked means the search could not answer for the pattern either way, because it uses a backreference or a lookaround. That is not a verdict on the pattern, and the report gives the reason.
A pattern written for another language's engine is read, not refused: a Python (?P<year>\d{4}), an atomic group or a possessive quantifier is searched like any other.
Only the patterns that can hang are listed. The rest are counted per file, and regex-le.workspace.scanIncludePassing lists every one with what was found. regex-le.workspace.scanProblemsEnabled also puts the ones that can hang in the Problems panel, where each is a line you can click.
What a scan reads. Source files in the nine languages the extractor knows: JavaScript, TypeScript, Python, Rust, Go, Java, Ruby, PHP and C#. Any other file would be searched for every spelling of a pattern at once, and a path in a README reads as one. scanPatterns widens that. Files come from disk, so an unsaved edit is not seen. A file over the safety size, or one that is not UTF-8 text, is left unread. It stops at 5,000 files or 10,000 listed patterns. The report ends with a line for each thing it left out, so a short report is never mistaken for a clean project.
What it skips, and how to change that. Three switches are on by default, and each can be turned off on its own in Settings:
Switch | Skips |
| Dependency folders, build output, tool caches and lockfiles. The full list is below |
| Whatever the project's |
| Images, fonts, archives and other files that are not text |
Two lists adjust the result without turning a switch off. To skip more, add a pattern to scanExcludes. To read something a switch would skip, add it to scanAlwaysInclude:
{
// Also skip the test fixtures.
"regex-le.workspace.scanExcludes": ["**/fixtures/**"],
// Read the vendored code, though the built-in list skips it.
"regex-le.workspace.scanAlwaysInclude": ["**/vendor/**"]
}Regex-LE: Open Settings opens all of these in the Settings editor.
Folders, wherever they appear:
.git, .hg, .svn, node_modules, bower_components, jspm_packages, .pnpm-store, .yarn, vendor, site-packages, Pods, Carthage, dist, build, out, target, _build, _site, dist-newstyle, zig-out, storybook-static, cdk.out, DerivedData, CMakeFiles, .next, .nuxt, .output, .svelte-kit, .angular, .astro, .docusaurus, .vuepress, .expo, .turbo, .parcel-cache, .cache, .sass-cache, .jekyll-cache, .dart_tool, .pub-cache, .gradle, .kotlin, .cxx, .externalNativeBuild, captures, ephemeral, .symlinks, .swiftpm, .build, .bundle, .stack-work, .zig-cache, .godot, elm-stuff, .vercel, .netlify, .serverless, .aws-sam, .terraform, .venv, venv, __pycache__, .tox, .nox, .mypy_cache, .pytest_cache, .ruff_cache, .ipynb_checkpoints, .eggs, coverage, htmlcov, .nyc_output, .vscode-test, .idea, .vs, xcuserdata, *.egg-info
Files, wherever they appear:
*.min.js, *.min.css, *.map, *.snap, *.lock, package-lock.json, pnpm-lock.yaml, npm-shrinkwrap.json, go.sum, *.pbxproj, *.iml, local.properties, output-metadata.json, .flutter-plugins, .flutter-plugins-dependencies, .packages, Generated.xcconfig, flutter_export_environment.sh, GeneratedPluginRegistrant.*, fastlane/report.xml, fastlane/test_output/**, doc/api/**
Not on the list, because they are ordinary folders in many projects: bin, obj, tmp, logs, public, generated. A project that generates those ignores them in git, and the scan reads .gitignore.
The settings that shape a scan are under Settings. The positions settings apply to it as they do to the single-file commands.
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 stdioExit 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
Command | Description |
| Test a found or entered pattern against the file |
| List every regex pattern found in the document |
| The distinct patterns in every source file in the workspace, and the files that hold each |
| The same for one folder. Also on a folder in the Explorer |
| Syntax + ReDoS report for every found pattern |
| Every pattern in every source file in the workspace, and which can hang |
| The same for one folder. Also on a folder in the Explorer |
| Open Regex-LE settings |
| Built-in documentation |
No command is bound to a key by default. Give any of them one under Keyboard Shortcuts in the editor.
Settings
Setting | Default | Description |
|
| Open results beside the current editor |
|
| Show the line and column of each pattern and match |
|
| Also copy results to the clipboard |
|
| Include the line and column in that copy |
|
|
|
|
| Guardrails for very large files and outputs |
|
| Refuse processing above this file size |
|
| Refuse result documents above this line count |
|
| Show the status bar item |
|
| Local-only event log (see Privacy) |
|
| ReDoS screening in Test/Validate |
|
| Cap on matches collected per test (10–10000) |
| Source files in the nine languages | The files a folder or workspace scan reads |
|
| Skip dependency folders, build output, caches and lockfiles |
|
| Skip what the project's |
|
| Skip images, fonts, archives and other files that are not text |
|
| More files to skip, as glob patterns |
|
| Files to read even when one of the three above would skip them |
|
| The most files one scan reads |
|
| The most patterns one scan lists before it stops reading |
|
| In a Validate scan, list every pattern, not only the ones that can hang |
|
| In a Validate scan, also show the patterns that can hang in the Problems panel |
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
telemetryEnabledsetting 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-bundlefails the build if the server ever imports something that could reach either.Error notifications redact home directories and credential-shaped fragments.
One rating prompt, at most twice. On the 3rd successful use the extension asks once whether you would rate it, and once more on the 20th if you chose Later or dismissed it. Don't Ask Again ends it. Setting
notificationsLeveltoimportantorsilentyourself turns it off. The counts are kept in VS Code's extension storage and nothing is sent anywhere; Rate opens the listing you installed from — the VS Code Marketplace or Open VSX — in your browser.
Documentation
What | Where |
What the tool is allowed to say — scope, output contract, refusals, non-goals | |
How the extension is built and held together — architecture, invariants, toolchain, release | |
How the CLI is built and held together | |
What changed | |
The tool's page, and the other fifteen |
Performance
Input | Size | Found | Time | Rate | Scan speed |
JS with literals | 1.12 MB | 25,000 | 44.19 ms | 565,679/sec | 25.4 MB/s |
JS with constructors | 1.27 MB | 25,000 | 41.86 ms | 597,268/sec | 30.3 MB/s |
Source without regexes | 1.24 MB | 0 | 18.75 ms | — | 66 MB/s |
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
Metric | Coverage |
Statements | 93.34% |
Branches | 82.27% |
Functions | 98.59% |
Lines | 95.39% |
378 test cases across 26 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, 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
This server cannot be deployed
Maintenance
Related MCP Connectors
Detects catastrophic-backtracking (ReDoS) regex risk via AST parsing, with JS-safe rewrites.
Explain a regex in plain English and detect catastrophic backtracking risk.
Security scanner for AI agents: prompt injection, leaked secrets, PII, and SSRF-risk URL detection.
1Scan configs, files, or text for leaked secrets and obvious misconfigurations. Nothing stored.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides a suite of regex and text processing tools for AI agents, including pattern testing, extraction, and replacement with capture group support. It also enables various text transformations like case conversion, line sorting, and deduplication through the Model Context Protocol.41 npmMIT
- FlicenseNot gradedqualityCmaintenanceRegexForge gives AI agents a reliable way to get a regex without asking an LLM to hallucinate one. Pass in labeled examples (strings that should match, strings that shouldn't) plus an optional description; get back the regex, a proof matrix showing it handles every example, and a backtracking-risk audit flagging catastrophic-backtracking patterns. Pure symbolic synthesis over a template bank with-
- AlicenseAqualityDmaintenanceProvides tools to test regex patterns for correctness, performance (ReDoS), and memory usage, and suggests safe rewrites. Enables LLMs to iterate on regex generation with verifiable feedback.9MIT
- FlicenseNot gradedqualityCmaintenanceLets users generate regex patterns from plain-English descriptions, then verifies them with Python's real re engine against generated positive and negative test strings, iterating on failures until they pass. It exposes this as a tool callable from MCP clients such as Claude Desktop or Claude Code.-