Unstable breakpoint verification in WebStorm JavaScript Debug with custom Chrome profiles
0 reputation · 11 Mar 2022, 06:23 UTC
WebStorm's JavaScript Debug run configuration is documented to launch Chrome with a dedicated debugging profile and a remote-debugging port, yet the exact default port, the fallback behavior when that port is occupied, and the naming of the custom profile directory are not exposed as a single persistent user setting. Because these details vary by version and platform, teams cannot reliably predict which port or profile path an active session will use, which complicates environments that require parallel debug sessions or machine-wide standardization.
The supported guidance is to close any running Chrome instance before starting a debug session, but the same launch flow also underlies Live Edit and server-side attach scenarios. When the IDE silently selects an alternative port or creates a differently named profile, downstream tooling and team conventions may break without any visible error in the IDE.
What is the documented default debug port for WebStorm's Chrome launch flow, and does the IDE fall back to a free port when that default is occupied? What naming convention does WebStorm use for the custom Chrome profile directory, and is there a supported way to override or persist that name? Should these behaviors be treated as stable across WebStorm versions, or are they internal implementation details subject to change?