js-reverse-mcp's default Chrome profile lives in another server's cache directory

The default profile path belongs to another MCP server

Read the anti-detection table and one cell stands out before any of the stealth detail. The profile directory row gives the default location as a path under a cache directory named chrome-devtools-mcp, and the cloak mode path as a sibling under that same directory with a different profile name. The project is js-reverse-mcp, not chrome-devtools-mcp. Two MCP servers that both manage a Chrome profile through this path would be writing into the same directory tree, and a profile is where cookies, localStorage and the login state the file says is deliberately kept across sessions live. The file does not mention the collision or suggest changing the location. Under cloak mode the two profiles are described as physically isolated from each other, which is the care taken inside one project; the name shared with another project is the part nobody addresses. Worth checking what already exists at that path before the first run.

Two sponsored blocks with referral codes sit above the features

The file opens with the project description and then, before any feature, two sections headed as sponsorships. The first is a residential proxy service, carried with a referral parameter on its link and a discount code printed in the text, framed as useful for regional access and localised content analysis. The second is a model API reseller, also with an affiliate link, offering access to several model providers behind one key, a claimed discount against official pricing, and a test credit for new accounts. Its stated purpose is to be the model API configuration for Claude Code and Codex, which is the same role the installation section later points at a tutorial for. Neither is a dependency and neither is required to run the server; they are advertising placed where the reader's attention is highest. For a tool in the anti-detection and reverse engineering category, the presence of referral codes in the first screen is a reasonable thing to weigh alongside the technical material, and the project does keep them clearly labelled rather than blending them into the documentation.

The stealth work is split into two layers that do not overlap

A table sets out the two layers and what each mode does with them. The protocol layer, which is the Chrome DevTools Protocol itself, behaves identically in both modes: it uses a dedicated Patchright fork, does not enable the runtime or console domains, evaluates inside an isolated world, removes the automation launch flags, and keeps fixing implementation signatures that are known to be shared. The source layer, which is a binary patch on the browser, is empty by default and only appears under the cloak flag. The wrapper layer, meaning this server's own code, is described as injecting no JavaScript at all and doing no property redefinition, on the grounds that such a redefinition is itself a signal. Three navigation level measures apply in both modes: silent navigation where the network and debugger domains stay off during page load and collection happens through Playwright listeners until a tool needs them, a Google referer on new pages, and turning off Playwright's default fake viewport so the browser reports its real screen size. The stated trigger for the extra layer is narrow: only when the above is not enough.

Default mode drives your own Chrome, cloak mode does not

The last row of that table answers a question the flags do not. In default mode the actual browser is the Google Chrome you installed, with its Web Store, your extensions and your sync. Under cloak it is a custom compiled Chromium with no Google services and no Web Store. So the flag is not a toggle on one binary, it is a different browser: your real profile, extensions and signed in state are available in the first case and simply absent in the second. The profile paths differ accordingly, and the file describes them as physically separated. Combined with the persistent login state that the default profile keeps across sessions, the practical question for a security adjacent tool is which of the two you actually want to drive, because the default is your own browsing identity and the isolated mode is a clean one. The file points at a separate document for the conditions under which the extra layer is meant to be enabled, and the guidance in the table itself is that it is a fallback rather than a starting point.

Most npm scripts rebuild the whole project before they run

Read the scripts block and count how many entry points start with a build. The build script is itself clean followed by the TypeScript compiler, and clean removes the build directory recursively with force. Then test, start, docs, docs:check, the routing evaluations, the test-only variant and the snapshot update all begin by invoking that build. In practice running the test suite deletes the compiled output and recompiles the TypeScript before a single test executes, and the documentation commands do the same before regenerating anything. One script exists purely to opt out: a test-only variant that skips the build step, alongside the one that does not. That is the tell, since an escape hatch is normally added because the default is annoying. The manifest points both its main field and its bin entry at the compiled index file, which is what a client configuration names when it launches through the package manager rather than a local build:

{
  "mcpServers": {
    "js-reverse": {
      "command": "npx",
      "args": ["js-reverse-mcp"]
    }
  }
}

For a project of this size the recompile costs a few seconds, but it means a task bound to the test script rebuilds on every run, and a partial build left by an interrupted run is not resumed.

A production audit gate exists and fails on high severity advisories

One script is a dependency audit with a deliberate scope. It runs the package manager's audit against production dependencies only, omitting development ones, and sets the failure level to high. That combination is the interesting part: dev dependency advisories are tolerated by design, since a build-time tool's transitive tree is not shipped, while a high severity advisory in what actually gets installed stops the command. There is no wrapper target that runs it as part of the test script, so it has to be invoked deliberately, which weakens it as a gate and makes it more of a tool. The rest of the quality surface is conventional and reasonably thorough: a separate typecheck that does not emit, a format script that writes through both eslint and prettier with caches, a check-format counterpart that does not write, and a debug start script that turns on debug output for the server's own namespace with colours disabled so the log stays readable in a pipe. Documentation is generated from the code rather than maintained by hand, and there is a check mode for it.

Tool routing is measured as its own gate

The project publishes twenty four tools and treats their selection as something to be tested. A script evaluates tool routing, and it has two modes: one that runs live and one that validates only. The live mode exists because the central design claim is that these are agent primitives rather than a mapping of a developer tools menu, and that claim is only meaningful if an agent picks the right primitive for a task. The naming follows the same idea. One tool lists network requests, or fetches one by its identifier, or exports it to a file. One evaluates a script, either in the page or inside a paused call frame, and accepts a local file as input. So each tool absorbs several DevTools operations rather than exposing one operation per tool, and the evaluation script is the mechanism for checking that the grouping still resolves correctly. Alongside it the tree carries an evaluations directory, a test directory, and a script that updates snapshots, which puts the tool surface under the same regression discipline as the rest of the code.

The project states it is not a general crawler framework

One paragraph sets the scope, and it is worth quoting the intent rather than the mechanism. The stated goal is not being able to drive a browser, but letting an agent complete one round of real reverse engineering work: open a page, get past the site's own checks, locate a script, save its source, set a breakpoint, trigger behaviour, inspect runtime state, export the network material, reproduce the state, and continue reasoning. The anti-detection is explicitly framed as serving that chain, with the aim of getting the agent onto the target page so analysis can continue, and the file says the opposite of what it is not for: turning the project into a general purpose crawling framework. On the fork, the claim is equally bounded: the goal is to reduce implementation signatures that have been confirmed as shared, not to promise that browser automation is absolutely undetectable. That disclaimer is the most useful line in the file for anyone deciding whether this suits them.

Editorial conclusion

This is a tool for people who already have authorisation to look at a page: the file itself frames the work as debugging and security research on scripts you are examining, and it says plainly that the anti-detection exists so an agent can reach a page and continue analysis rather than to turn the project into a general crawler framework. That framing is the reason the stealth layer is worth reading, because it is documented rather than implied: two non overlapping layers, a protocol layer always on and a source layer opt in, with the fork's stated goal being fewer shared implementation signatures and an explicit refusal to promise that automation is undetectable. Three things to check before you install it. The profile directory is named after another MCP server, so if you run both, be deliberate about which one owns that path. The default mode drives your own Chrome with your extensions and sync, and the cloak mode replaces it with a custom Chromium that has neither, which is a larger change than a flag. And two of the four npm entry points rebuild from clean before doing anything, so expect a full recompile every time unless you use the no-build variant.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. zhizhuodemao/js-reverse-mcp on GitHub