mirror of
https://github.com/multica-ai/multica.git
synced 2026-08-13 03:15:34 +02:00
53122a123d
Desktop derives its daemon profile from the renderer-supplied API URL. Until that arrived, "no profile yet" was represented by an empty profile name, which resolved to the default profile owned by the user's terminal CLI. Three silent consequences: syncToken wrote token and server_url into ~/.multica/config.json; profileArgs omitted --profile so the bundled CLI ran against that same profile; and healthPortForProfile returned 19514 — the default profile's port — so a user's own CLI daemon could be probed and reported as Desktop's. resolveActiveProfile's docstring and desktop-app.mdx both already promised this could not happen. Nothing enforced it, and there was no test. Not Windows specific: none of the three vectors branches on platform. Replace the sentinel with null so the unresolved state carries neither a path nor a port, forcing all ten call sites to handle it, and move the path/port/arg helpers into daemon-profile.ts with a resolved-profile assertion as a backstop. Also fixes login ordering: syncToken's fail-closed branch had no recovery because the login effect only depends on the user while the URL was pushed by a separate effect. The sequence now lives in platform/daemon-login-sync.ts and awaits setTargetApiUrl before syncToken and autoStart. Refs #6399