Debugging Chrome DevTools MCP's "Could not find DevToolsActivePort" error

Darsh Joshi @darshjoshiiOriginally posted 2026.10.18

Open original on X

Chrome DevTools MCP told me “Could not find DevToolsActivePort.” The file was there. Chrome was running. Remote debugging was enabled. The actual problem was macOS permissions—and the permission belonged to a different app than I expected. Here’s how we tracked it down while connecting Codex to my existing, signed-in Chrome session: 1. Check the connection setup Chrome’s chrome://inspect/#remote-debugging page showed the server running on 127.0.0.1:9222. Codex was configured with: args = ["chrome-devtools-mcp@latest", "--autoConnect"] The running connector also had --autoConnect. So this wasn’t just an unsaved config change. 2. Check whether the file is readable, not just whether it exists Listing Chrome’s DevToolsActivePort file worked. Reading it returned EPERM: operation not permitted—even outside Codex’s command sandbox. That distinction mattered. A successful file listing didn’t mean the connector could read its contents. 3. Inspect the error underneath the message In the installed connector dependency, the catch block reported “Could not find DevToolsActivePort” for errors in that connection path. The underlying permission error wasn’t visible in the tool’s response. The top-level message sent us toward the wrong diagnosis. 4. Find the app macOS considers responsible We initially allowed ChatGPT/Codex to access Google Chrome under Files & Folders. It still failed. The macOS privacy logs showed why: this background process was attributed to iTerm2. Granting access to the app I was chatting in didn’t cover that process. For my setup, the fix was: System Settings → Privacy & Security → Files & Folders → iTerm2 → Google Chrome This grants access to Chrome’s protected data. Check the responsible app in your own setup; it won’t necessarily be iTerm2. 5. Verify the result After that change: • The discovery file became readable. • The MCP connector successfully listed my existing Chrome tabs. • No further restart was needed. We didn’t need Full Disk Access or a separate Chrome profile. My takeaway: when an integration says “missing,” check the underlying error before reinstalling it. And on macOS, check which app the OS attributes the access to. Matching upstream report: https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/3089