You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CLI's open() call has no timeout, no catch, and no fallback message #2410
v2 — current (@modelcontextprotocol/inspector@latest)
Which client?
CLI
Inspector version
2.7.0 (git tag) — static code-review finding, not run locally
Node version
N/A — static code review, no live run performed
Operating system (and browser, for the web client)
N/A — static code review
Transport
Not applicable / never connected
MCP server under inspection
N/A — this is a static code-review finding against the 2.7.0 tag source (clients/cli/src/open-url.ts), not a live reproduction against a running MCP server.
Steps to reproduce
Found via static review of the 2.7.0 tag source, not a live run.
clients/cli/src/open-url.ts is a bare await open(url) with no error handling and no timeout:
In a headless CI box, a container, or a Linux desktop with no registered URL handler, open() can reject or hang depending on platform.
There is no "copy this URL instead" fallback the way clipboard access does elsewhere in the codebase.
I have not run this against an actual headless/no-DISPLAY environment to observe the hang; flagging based on the code path itself.
Expected behavior
The OAuth flow's browser-open call has a timeout and error handling, and prints the URL for the user to copy manually on failure (or by default alongside the browser open).
Actual behavior
openUrl (clients/cli/src/open-url.ts) is a bare await open(...) with no timeout, no catch, and no fallback message.
Suggested fix: wrap the call in a try/catch with a timeout, and on failure (or by default alongside the browser open) print the URL so the user can copy it manually.
Logs, errors, or screenshots
No response
Already prototyped a fix?
No response
Before you submit
I searched existing issues and this is not a duplicate.
This is not a security vulnerability report (those go through the private advisory process).
Activity
cliffhall commentedon Sep 18, 2026
Triage: Priority Low (total 5)
buglabelLabels applied at triage:
v2.Board: #28, Status
Incoming(awaiting maintainer review — no milestone yet).fix(cli): bound the OAuth browser open and say when it fails (modelco…
fix(cli): catch an opener that cannot be spawned instead of crashing