Unstable breakpoint verification in WebStorm JavaScript Debug with custom Chrome profiles

Short answer

JetBrains does not document one persistent setting that fixes both the remote-debugging port and the Chrome user-data directory used by the built-in JavaScript Debug launch. Both values are chosen at launch time, so they are best treated as internal implementation details rather than a stable contract. The port most commonly associated with this flow is 9222, Chrome's conventional remote-debugging port, but treat that as likely rather than confirmed. Current builds generally fall back to another free loopback port when the preferred one is occupied, which is why parallel sessions can land on different ports with no visible message. The profile directory is generated under the operating system's temporary area with a name that is not a documented constant. The supported way to pin either value is a custom browser entry that passes explicit command-line arguments.

What is documented versus what is internal

Detail	Status
Close running Chrome before starting a debug session	Documented guidance
Browsers and Preview UI accepts custom browser entries with arguments	Documented, supported override
Fixed default debug port of 9222	Likely, not a documented constant
Silent fallback to a free loopback port when the default is taken	Likely in current builds; older builds were more likely to fail or attach to an existing Chrome
Generated profile directory name under the temp area	Internal; do not hardcode it in tooling
Older extension-based flow connecting back to the IDE server port	Historical; version-dependent

The same launch flow underlies Live Edit and server-side attach scenarios, so the constraint propagates to them: two Chrome processes cannot share one user-data directory, and a second launch with the same path hands off to the already-running instance.

Pin both values with a custom browser entry

In Settings | Tools | Browsers and Preview, define a custom browser entry and supply the arguments yourself. This is the reliable way to make the port and profile predictable for a team or for parallel sessions.

chrome --remote-debugging-port=9222 --user-data-dir=<your-profile-path>

Give each parallel session its own profile path. Sharing one path across sessions does not create two debug targets; it reuses the first instance.

Verification steps

1. Reproduce the session, then read the actual Chrome process command line (Task Manager or Process Explorer on Windows, ps on macOS/Linux) and note the --remote-debugging-port and --user-data-dir values in use.
2. During the active session, open Chrome's built-in version page, which reports the profile directory currently in use.
3. Check Help | Show Log for the launch command line recorded when the debug session starts; this is the most direct confirmation of what the IDE chose.
4. Query the DevTools HTTP endpoint on the loopback interface for the port in use to confirm the session is reachable and to see attached targets.
5. Repeat with the pinned custom browser entry on each WebStorm build your team uses to confirm the override is honored consistently.

Stability and the one detail that changes the advice

Port selection, profile naming, and whether the older IDE Support extension is required have all changed across WebStorm releases. Verify against the exact build in use rather than assuming machine-wide consistency. Corporate endpoint agents, antivirus, or firewall policy can also block or rewrite loopback debugging ports, producing symptoms that look like IDE instability but are environmental.

One diagnostic detail changes the recommendation: the launch command line from Help | Show Log, or the Chrome process command line. If it shows the IDE choosing the port, the fix is a pinned custom browser entry; if it shows a pinned port that still fails intermittently, the cause is more likely environment or port contention, and configuration changes will not help. Because these behaviors are version-sensitive, treat this draft as a conservative starting point and confirm against your installed build before standardizing on it.