Looking for public Chrome DevTools MCP startup failure logs to test safe failure-window extraction

[rileyross722]

Hi everyone, I’m looking for a few public Chrome DevTools MCP startup, CI, install, or terminal failure logs to test whether a “safe failure-window” workflow is useful for coding agents.

I saw issue #199, where adding chrome-devtools-mcp in an MCP client produced an ERR_MODULE_NOT_FOUND error around:

chrome-devtools-mcp/build/src/browser.js

That issue is already closed, so I’m not trying to reopen it or add noise there. I’m using it only as an example of the kind of failure pattern I’m interested in:

• MCP server startup failure
• ERR_MODULE_NOT_FOUND
• package/runtime path issue
• coding-agent or IDE MCP client context
• stack trace where the useful failure signal is buried inside a larger log

What I’m testing

I’m testing FailLens Crash Gate, which does one narrow thing:

failed command log -> redacted bounded failure evidence -> agent-safe next step

No install is needed for the first test.

If someone has a public failed Chrome DevTools MCP startup log, GitHub Actions failure, install failure, or terminal crash related to MCP setup, feel free to reply with a public link or paste a redacted excerpt.

What I can return

I can run it through FailLens and reply with a safe summary like:

failure type:
failure subject:
bounded evidence window:
safe_to_send:
likely next action:

I will not publish raw logs, secrets, private repo names, or stack trace bodies in any public proof without permission.

Good example

A good example is:

MCP server failed to start
log is noisy
useful error is buried
an agent or developer needs the small part that matters

If this kind of validation post is not appropriate for this discussion area, I’m happy to remove it. I’m mainly looking for real MCP/devtool failure examples to see whether this workflow is useful outside my own test cases.

[VectorPeak]

This seems like a reasonable validation target, especially because MCP startup failures often produce a lot of wrapper noise before the actual Node/runtime error shows up. The ERR_MODULE_NOT_FOUND case around:

chrome-devtools-mcp/build/src/browser.js

is a good example of the kind of signal that can get buried: the important part is usually the missing module path, the package version, the way the MCP client launched the server, and the immediate stack frames around the failing import.

What I would check first for logs in this category is whether the failure is coming from one of these buckets:

• Published package / build artifact mismatch, where the installed package does not contain the path being imported.
• Stale install or package-manager cache, especially if the error goes away after reinstalling or upgrading.
• Runtime mismatch, for example a Node version or ESM/CJS behavior difference.
• MCP client launch configuration issue, where the client runs a different command, working directory, or package version than expected.
• CI environment difference, where the same command works locally but fails under GitHub Actions or another clean environment.

For anyone sharing a useful excerpt, the smallest helpful shape would probably be something like this, with private paths and names removed:

MCP client:
chrome-devtools-mcp version:
Node version:
OS:
install/run command:
package manager:

<last 20-40 lines before the failure>
ERR_MODULE_NOT_FOUND ...
<first few stack frames after the failure>

The chrome-devtools-mcp version and the exact command matter quite a bit here. For example, npx chrome-devtools-mcp, a globally installed package, and an MCP client-managed install can all fail in slightly different ways even when the visible error looks like the same missing build/src/browser.js path.

For redaction, the things worth removing before posting are home directories, internal repo names, tokens, absolute workspace paths, CI URLs for private repos, and any MCP config that includes credentials. The useful diagnostic window should still preserve package names, relative paths inside node_modules, the error code, the command being run, and a few adjacent stack frames.

One caveat: if this discussion area is intended strictly for chrome-devtools-mcp bugs and support, this may be better kept as a narrow request for reproducible public startup failures rather than a broader tooling validation thread. The most repo-useful output would be a concise summary that says whether the failure appears to be a package issue, environment issue, or client configuration issue, plus the exact bounded evidence used to reach that conclusion.

If someone does have a public failure log, the most useful next step would be to link the original issue/action/log and paste only the bounded excerpt here. That keeps the thread auditable without turning it into a raw-log dump.

---

If my answer solved your problem, you can click answered the question. I'm really here to help, and along the way I'm also collecting Galaxy Brain badges haha 😆