Split out of #15 so it isn't lost when that issue closes.
The question
Should Perplexity.daemonPort default to a pinned value instead of 0 (ephemeral)?
Context
The daemon binds an OS-assigned ephemeral port on every start (options.port ?? 0). As @owenhuang1991 observed in #15, the pinned-port path already does the right thing on a conflict — it throws Port X is in use; daemon cannot start rather than spawning a duplicate — whereas the ephemeral path retries on a fresh random port, so N daemons can coexist on N ports all pointing at one shared browser-data.
Since #15/#14 landed, several things changed:
Perplexity.daemonPort is honored (validated 1024–65535, threaded into the spawn). It was dead code before — the extension's own "Pin a port now?" nudge wrote 49217 and nothing read it. So pinning is a real mitigation today, for anyone who wants it.- The pile-up itself is fixed independently: stale-reclaim fences live holders, wedged/version-mismatched daemons are stopped and replaced, orphaned browsers are evicted, and every kill is a tree-kill. So a pinned port is no longer needed to prevent the fight.
- Port changes now re-fire VS Code's MCP server definitions, so an ephemeral port is far less disruptive than it was.
The trade
For a pinned default: duplicates become impossible-by-construction rather than fixed-by-cleanup; http-loopback IDE configs stop drifting (that's what the nudge exists for); one fewer moving part in the multi-client story.
Against: any fixed port can collide with unrelated software on a user's machine, and the pinned path's response is to refuse to start — turning a silent, self-healing ephemeral retry into a hard failure for someone whose port 49217 is taken. It would need a "pinned, but fall back to ephemeral on EADDRINUSE" policy to be safe as a default, which partly defeats the point.
Suggested resolution
Either:
- Keep
0 as the default and document pinning as the mitigation for http-loopback stability (cheap; status quo + docs), or
- Default to a pinned port with an ephemeral fallback on
EADDRINUSE + a warning, so duplicates are prevented in the common case without ever bricking startup.
Leaning (1) unless multi-daemon reports recur on 0.8.60+, since the mechanisms that actually caused the pile-up are now fixed at the source. Flagging for a product call rather than deciding it silently.
Split out of #15 so it isn't lost when that issue closes.
The question
Should
Perplexity.daemonPortdefault to a pinned value instead of0(ephemeral)?Context
The daemon binds an OS-assigned ephemeral port on every start (
options.port ?? 0). As @owenhuang1991 observed in #15, the pinned-port path already does the right thing on a conflict — it throwsPort X is in use; daemon cannot startrather than spawning a duplicate — whereas the ephemeral path retries on a fresh random port, so N daemons can coexist on N ports all pointing at one sharedbrowser-data.Since #15/#14 landed, several things changed:
Perplexity.daemonPortis honored (validated 1024–65535, threaded into the spawn). It was dead code before — the extension's own "Pin a port now?" nudge wrote49217and nothing read it. So pinning is a real mitigation today, for anyone who wants it.The trade
For a pinned default: duplicates become impossible-by-construction rather than fixed-by-cleanup;
http-loopbackIDE configs stop drifting (that's what the nudge exists for); one fewer moving part in the multi-client story.Against: any fixed port can collide with unrelated software on a user's machine, and the pinned path's response is to refuse to start — turning a silent, self-healing ephemeral retry into a hard failure for someone whose port 49217 is taken. It would need a "pinned, but fall back to ephemeral on EADDRINUSE" policy to be safe as a default, which partly defeats the point.
Suggested resolution
Either:
0as the default and document pinning as the mitigation for http-loopback stability (cheap; status quo + docs), orEADDRINUSE+ a warning, so duplicates are prevented in the common case without ever bricking startup.Leaning (1) unless multi-daemon reports recur on 0.8.60+, since the mechanisms that actually caused the pile-up are now fixed at the source. Flagging for a product call rather than deciding it silently.