Daemon stuck reporting anonymous session after successful login (reason=not-logged-in)

[ARHAEEM]

Split out of #10, which was originally an onboarding question ("after login… now what?"). Several people have since reported a different problem in that thread, so it gets its own issue.

Symptom

After a login that reports success, the dashboard's daemon badge stays on:

Daemon sees an anonymous session — run login to connect.

…and running login again doesn't clear it. Reported by @ITFinesse and @lcarbow in #10.

Why this is not simply a duplicate of #11

#11 (Windows ships a Linux keytar.node) is one route to this symptom, but it is Windows-only, and the reason codes don't line up:

• Windows: bundled keytar.node is a Linux ELF binary -> "Bad Image" 0xc000012f, vault never persists (login stuck Anonymous) #11's own daemon.log line ([vault] getSavedCookies failed … Vault locked) sets _lastVaultLocked = true, which yields reason: "vault-locked" and renders a different string: "Daemon can't unlock this profile's vault — click Refresh state to re-send your passphrase."
• Both reporters quoted the not-logged-in string instead.
• Neither reporter stated an OS, and Dumb question.. but after login.. now what? #10's original reporter is on MX Linux — which ships without gnome-keyring/libsecret by default, giving a Linux route to the same symptom with a completely different fix.

So closing these as dupes of #11 risks dead-ending Linux users on a Windows packaging bug. Hence this umbrella.

The one thing we need from you

Please post your OS plus the verbatim reason field from:

~/.perplexity-mcp/profiles/<profile>/daemon-status.json

That single field forks the diagnosis cleanly:

reason	vault.enc	Most likely cause
vault-locked	present	Windows → #11 (Linux ELF keytar.node). Linux → no libsecret, or the passphrase isn't in the daemon's env (0.8.49 class) — try Refresh state, install gnome-keyring, or set PERPLEXITY_VAULT_PASSPHRASE
not-logged-in	absent	The vault seal never happened — login died before writing it
not-logged-in	present	The vault unsealed fine but the live auth probe failed (expired cookie, CF block). "Run login" will not fix this — misleading message, see below

The forking lines in daemon.log: [vault] getSavedCookies failed (vault-locked) · no vault.enc … run login first · No authenticated session (anonymous mode) · Auth check failed:.

Known contributing bugs

1. Stale status file — FIXED (unreleased). shutdown() wrote authenticated:false to daemon-status.json on its way out, and a crashed daemon just left its last write behind. The extension read that file with no liveness check, despite pid sitting right there in the payload. So a daemon that had merely stopped rendered "anonymous session" forever, and no amount of logging in could clear it. This is the best fit for "cant get it to change out of this status." getAccountSnapshot() now ignores a status whose writing process is gone.

2. not-logged-in is used as a catch-all — open. reason is computed as authenticated ? "ok" : wasLastVaultLocked() ? "vault-locked" : "not-logged-in". But authenticated is a live network probe, not "cookies exist" — any probe failure (expired session, CF block, nav timeout) lands on not-logged-in with a perfectly healthy vault, telling the user to run a login that cannot help. Needs a third reason (e.g. auth-check-failed) set when the vault did unseal but the probe still failed. Shared-contract change (DaemonAuthStatus.reason), so older daemons degrade to the existing else-branch.

3. Vault seal failure crashes the login runner — open. manual-login-runner.js, login-runner.js, and impit-login-runner.js all call vault.set(...) uncaught, so a seal failure kills the runner before it writes the models cache or emits {ok:true} — the user sees a generic crash instead of "your OS keychain is unavailable; set a vault passphrase." cli.js already does this preflight properly via checkVaultUnseal(); the extension-driven runners should reuse it.

4. Linux without libsecret — open (docs at minimum). MX Linux/XFCE and friends ship no keyring. The intended mitigation is the passphrase, but build-daemon-env.ts only peeks at an existing secret and resolves it at daemon spawn, so a daemon warm-started before the user's first login never gets one and stays anonymous until "Refresh state" fires a /daemon/reinit.

Fix 1 is in the tree; 2–4 are tracked here.

[ARHAEEM]

All four contributing bugs are now fixed in main (679c9ba), plus the related session-truth defects found while verifying them. Status of the original list:

Bug	Status
1. Stale daemon-status after daemon exit/crash	fixed (b060f80) — and since reproduced on a real machine: a dead pid 26924 from 07-14 was still rendering "anonymous session" for a logged-in profile, confirming the diagnosis
2. not-logged-in used as a catch-all	fixed — new auth-check-failed reason: when the vault unsealed and cookies loaded but the live probe still failed, the badge now says the session may have expired / the check was blocked, instead of prescribing a login that can't help
3. vault.set uncaught → login runner crashes	fixed — all three runners emit a typed vault_seal_failed, and the extension shows an actionable hint (enable gnome-keyring/libsecret, or set PERPLEXITY_VAULT_PASSPHRASE) instead of "crash"
4. Linux no-libsecret diagnosability	improved — vault.js now logs why keytar failed to load (this path previously produced zero trace, which is how #11 hid for weeks); full auto-re-supply of the passphrase on warm-started daemons remains follow-up work

Also fixed in the same sweep, because they fed the same "the UI lies about my session" class:

• perplexity_models labeled anonymous accounts "Authenticated" — the cache-first path hardcoded authenticated: true for any populated cache, but anonymous accounts have a minimal models config too. The account cache now records real authenticated/userId from every login/refresh path, and stale pre-upgrade caches degrade to Anonymous rather than faking a session.
• Speed Boost (impit) logins downgraded real Pro users to "Authenticated" — 4 of its 5 hardcoded REST paths didn't exist upstream and it wrote the cache in a shape no reader understood. It now shares the exact endpoint list and tier derivation with every other login path.
• Soft logout left you "logged in" forever — models-cache.json/daemon-status.json survived logout, and the extension's hasStoredLogin() was literally "does vault.enc exist" (it always does — email survives logout by design). Both fixed; note a profile last logged in by a very old version may need one re-login for the extension to see it.
• perplexity_reason/perplexity_research error taxonomy — "requires an authenticated Pro account" fired only on the auth check while authenticated Free users passed silently and failed upstream. Both now use the same two-step gate as perplexity_compute (fails open when account flags haven't loaded).

Verified: 1260 tests pass (+18 new covering each fix, including the reason-mapping matrix and a logout→hasStoredLogin round-trip); security coverage floors hold.

@ITFinesse @lcarbow — with main, the "cant get it to change out of this status" chain is closed end-to-end: the daemon no longer dies on a failed background reinit, a dead daemon's stale status is ignored, VS Code re-resolves when the daemon comes back on a new port (#14), and if it's genuinely your session/vault, the badge now says which problem it is instead of a blanket "run login". These land in the next release; still happy to see your daemon-status.json reason + OS if it persists after that.