Repository navigation
preview: server scan starts at the saved session port and probes up to 100 unrelated ports despite an explicit --port #6204
Description
Summary
readPreviewLifecycleState starts the server scan at the saved session port (saved?.port ?? startPort, packages/cli/src/commands/previewLifecycle.ts), and scanActiveServers probes MAX_PORT_SCAN (100) consecutive ports with GET /__hyperframes_config. If the saved session came from a different port range than the one requested now, the CLI probes up to 100 unrelated local ports before honoring the explicit --port; a start that ends up on another port can add a second scan window.
Reproduction (observed on 0.8.97; same logic on main / v0.8.191)
hyperframes preview <project> --port 3021, then stop it (the session state keeps 3021).hyperframes preview <project> --port 32521.- The CLI sends
GET /__hyperframes_configto 3021–3120 (other local services) before using 32521.
Why it matters
Hosts that embed the CLI may only be allowed to touch a defined port range; probing unrelated ports reaches other local services.
Suggestion
When --port is given explicitly, scan only the requested window (or check only the saved port itself), or make the scan window configurable / allow disabling the scan.
Activity
jrusso1020 commentedon Oct 24, 2026
Thanks for the clear repro, confirmed on main. readPreviewLifecycleState starts the scan at the saved session port (packages/cli/src/commands/previewLifecycle.ts:482). scanActiveServers then probes 100 consecutive ports from there (packages/cli/src/server/portUtils.ts:23 and :306). An explicit --port outside that window is only checked afterwards (previewLifecycle.ts:518), so it adds a probe on top of the scan rather than replacing it. Narrowing the scan when --port is given makes sense. — Rames
feat(cli): skip the preview-server scan when HYPERFRAMES_NO_PREVIEW_D…