perplexity-user-mcp 0.8.42 — Headed Bootstrap reads cookies as anonymous despite successful login (regression from 0.8.41 fix) #5

Activity

1. luvher

   added

   bugSomething isn't workingSomething isn't working

   on May 11, 2026
2. ARHAEEM commented on May 11, 2026

   

   ARHAEEM

   on May 11, 2026

   Member

   More actions

   Thanks for the thorough writeup, and you're right that PR #4 missed a path. Reading 0.8.42's code with your symptoms in hand, there are two distinct bugs stacked on top of each other — both worth a 0.8.43 release. Before we ship, I want to confirm which one is biting in your scenario A vs. scenario B because some of the data below distinguishes them.

   Bugs identified (high confidence)

   Bug 1 — PERPLEXITY_HEADLESS_ONLY=1 leaks from the launcher into the daemon's spawn env

   This is the cause of your Skipping headed session (PERPLEXITY_HEADLESS_ONLY=1) line.

   • packages/extension/src/auto-config/transports/stdio-daemon-proxy.ts writes PERPLEXITY_HEADLESS_ONLY: "1" into the launcher's IDE-config env block.
   • In daemon-proxy mode the launcher itself doesn't run a PerplexityClient — it just relays JSON-RPC over HTTP — so the flag is dead weight on the launcher.
   • But when the daemon isn't already running, attachToDaemon → ensureDaemon → spawnDetachedDaemon inherits ...process.env directly. HEADLESS_ONLY=1 leaks straight into the daemon. The daemon's PerplexityClient.init() then skips the headed bootstrap entirely — which is exactly what needs to refresh cf_clearance for the headless phase.
   • The buildDaemonEnv overlay from PR fix(vault): unseal hardening for external MCP clients (issue #3) #4 is appended after ...process.env in spawnBundledDaemon too, so even when the extension is the spawner it doesn't strip launcher-scoped flags. It happens to work in the extension-spawner case only because the extension host's process.env doesn't have HEADLESS_ONLY=1 to begin with — your scenario B is the launcher-spawner case, which does.

   Bug 2 — Phase 2 (headless) discards Phase 1's fresh cf_clearance

   This would explain your scenario A (Headed bootstrap complete → No authenticated session).

   • The doc-comment on PerplexityClient.init() says Phase 2 "launches headless with the same persistent profile (now carrying fresh cf_clearance)" — client.ts:892.
   • The actual code at client.ts:918-929 does chromium.launch(...) + getOrCreateContext(...) — non-persistent. So the cf_clearance flushed to browserData/ by Phase 1 is never loaded by Phase 2.
   • Vault cookies are then injected via addCookies — but the cf_clearance in the vault is from login time. If your login was even ~30s ago, that clearance can already be invalid (CF rotates aggressively on UA/IP/fingerprint shifts), and the page navigation in Phase 2 hits the CF challenge and falls back to anonymous before checkAuth runs.
   • The H1 integration test in login-tier-end-to-end.integration.test.js passes because the mock server has no Cloudflare. In production this is a real handoff gap.

   Diagnostic gap

   Separately, getSavedCookies() returns [] silently when either (a) vault.enc doesn't exist for the daemon's resolved profile or (b) the cookies key is missing from a decryptable vault. Combined with the doctor's unseal-verify passing, this gives users no signal which of four failure modes they're hitting. We'll add explicit logging.

   What I need to confirm before writing the fix

   I want to be sure scenario A is the cf_clearance handoff and not a separate profile-mismatch issue that would survive Bug 2's fix. Could you attach the following to this issue?

   1. Full ~/.perplexity-mcp/daemon.log (it's the most informative artifact — please redact tokens if you want, the [trace] http lines aren't sensitive but tokens/cookies are).
   2. Get-Content $env:USERPROFILE\.perplexity-mcp\active — one-line file containing the active profile name.
   3. Get-ChildItem $env:USERPROFILE\.perplexity-mcp\profiles -Recurse -Name — confirms whether there's still a stale personal/vault.enc next to the new default/vault.enc.
   4. echo "%PERPLEXITY_PROFILE%" "%PERPLEXITY_HEADLESS_ONLY%" in a fresh cmd (System+User env vars) so I can see whether either is set system-wide.
   5. npx perplexity-user-mcp@0.8.42 doctor --json --probe — the full JSON output, not just the failing categories. The full output includes activeProfile and per-category checks that the truncated version in the issue body doesn't.

   A fresh Perplexity: Capture Diagnostics Bundle zip covers 1-4 in one shot and is the easiest way to send everything.

   What's coming in 0.8.43 once we confirm

   Fix 1 (HEADLESS_ONLY leak) — belt-and-suspenders:

   • Strip PERPLEXITY_HEADLESS_ONLY from stdio-daemon-proxy.ts auto-config env (it's redundant in proxy mode anyway).
   • Auto-regen existing IDE configs on next activation so your already-written Antigravity/Claude Code config gets rewritten without the dead flag.
   • Defensively strip both PERPLEXITY_HEADLESS_ONLY and PERPLEXITY_NO_DAEMON from spawnDetachedDaemon AND spawnBundledDaemon envs, so the daemon can never inherit these launcher-scoped flags from any future leak path.

   Fix 2 (Phase 2 cookie handoff) — persistent context + headed cookie injection:

   • Inject vault cookies in the headed phase too, so it authenticates from the start, fetches real account info, and the dashboard shows tier=Pro on first init rather than waiting for the headless recovery path.
   • Switch Phase 2 to chromium.launchPersistentContext(browserData, ...) so the fresh cf_clearance from Phase 1 carries over to the headless context.

   Diagnostic gap — add explicit log lines in getSavedCookies() for both "vault.enc missing" and "cookies key missing" so the next bug report can distinguish silent-empty from decrypt-failure.

   Will ping back as soon as you drop the diagnostics. Thanks again for the precise repro — both bugs were findable from your logs alone but the daemon.log will tell us whether there's a third thing hiding underneath.
3. ARHAEEM commented on May 11, 2026

   

   ARHAEEM

   on May 11, 2026

   Member

   More actions

   Both bugs are fixed and in PR #7 — no need to wait for the diagnostics at this point, the root causes were clear enough from the original report.

   What was shipped in 0.8.43:

   • Bug 1 (HEADLESS_ONLY leak) — stripped from daemon spawn env at all three spawn sites (daemon/launcher.ts, extension/src/daemon/runtime.ts, stdio-daemon-proxy.ts). The auto-config for your existing IDE configs will be rewritten on next activation to drop the dead flag.
   • Bug 2 (Phase 2 discards cf_clearance) — Phase 2 now uses launchPersistentContext(browserData, ...), same directory as Phase 1, so the fresh clearance is on disk when Phase 2 starts. Vault cookies are injected selectively so a freshly-written cf_clearance is never overwritten by a stale vault copy.
   • Diagnostic gap — getSavedCookies() now logs a specific message for each silent-empty path (no vault.enc, cookies key absent, JSON parse failure, unseal error) so future bug reports will be much easier to triage.

   Additionally, as a bonus for this release: the dashboard now shows a live daemon auth status indicator in the hero panel (green when the daemon is authenticated, yellow warning when the daemon sees an anonymous session despite stored credentials). Clicking "Refresh state" in the dashboard will automatically touch the .reinit sentinel to force a daemon reinit — so if the mismatch happens again after a cold start you can recover without restarting the whole extension.

   PR: #7 — will close this issue on merge. The VSIX will be attached to the release once smoke passes on Win11 + macOS + Ubuntu.
4. ARHAEEM

   closed this as completedin #7on May 11, 2026
5. ARHAEEM

   added a commit that references this issue on May 11, 2026

   Merge pull request #7 from Automations-Project/fix/0.8.43-auth-cli-ha…

   ...

   This issue will close once commit 0860ed9 is merged into the 'main' branch.

   0860ed9
6. ARHAEEM

   added a commit that references this issue on Jun 4, 2026

   fix(#8): resolve browser-data singleton-lock deadlock (daemon single-…

   ...

   adc5986