All page-touching tools fail (~6.5s, 'Target page, context or browser has been closed') since 2026-07-16 — Cloudflare now hard-blocks the headless persistent phase

[owenhuang1991]

Since 2026-07-16 ~14:15 UTC, every page-touching tool call (perplexity_ask, perplexity_search, perplexity_research) fails after a constant ~6.5s with:

Error: page.evaluate: Target page, context or browser has been closed

The daemon then exits and the extension watchdog respawns it, so external MCP clients (Claude Code via start.mjs) also see MCP error -32000: Connection closed and lose their session.

Root cause (verified by isolated repro)

Perplexity's Cloudflare now appears to hard-block headless Chrome sessions — the Turnstile/managed challenge never clears headlessly, even reusing a profile that a headed session just cleared.

Repro with patchright (both 1.59.4 — the bundled version — and 1.61.1) + system Chrome 150.0.7871.124 on macOS (darwin arm64), fresh profile, https://www.perplexity.ai:

headless: title stays "Just a moment..." (localized "請稍候...") for 25s+, challenge never clears
headed:   challenge clears in ~5s, app fully reachable (search box present)

So the daemon's two-phase design (Phase 1 headed bootstrap solves CF → Phase 2 headless persistent context reuses cf_clearance from the shared profile) no longer works: the headless phase gets re-challenged, never passes, and the ~6.5s page watchdog tears the page down — which surfaces as the page.evaluate: Target page, context or browser has been closed error on every call.

Everything else was ruled out one by one on this machine before pinning it on CF:

• single daemon, no lock contention (earlier daemon pile-up cleaned up separately)
• fresh browser-data profile (rebuilt from vault cookies — vault unseal fine, Authenticated as user logged)
• Chrome 150 + patchright basics verified fine standalone (headless page.evaluate works on other sites)
• extension 0.8.54 / npm perplexity-user-mcp 0.8.53 are the latest available — no newer build to try

Workaround that restores service (tested locally)

In chunk-ZLKA2VC3.mjs (init()), launching the Phase 2 persistent context headed instead of headless fixes it — combined with the existing OFFSCREEN_POSITION_ARG (--window-position=-32000,-32000) the window stays invisible to the user, same as the headed bootstrap refresh path:

-      console.error("[perplexity-mcp] Launching headless persistent browser...");
-      const launchOpts = buildLaunchOptions(true);
+      console.error("[perplexity-mcp] Launching headed-offscreen persistent browser...");
+      const launchOpts = buildLaunchOptions(false);

buildLaunchOptions(false) already appends the off-screen positioning arg, so no other changes are needed. Suggest shipping this (or a config/env toggle, e.g. PERPLEXITY_PERSISTENT_HEADED=1) so users don't have to patch dist/.

Environment

• Extension: nskha.perplexity-vscode 0.8.54 (daemon reports 0.8.53)
• OS: macOS (darwin arm64, Darwin 25.5.0)
• Chrome: 150.0.7871.124 (system), auto-updated 2026-07-15
• Node: v24.17.0
• patchright bundled: 1.59.4

Happy to provide daemon logs / audit.log excerpts if useful.

[ARHAEEM]

Thank you — this is an outstanding report, and the isolated repro plus the tested patch is exactly what makes this actionable. I'm shipping a fix based on it. Two corrections and two questions first, because the diagnosis isn't fully nailed down and one detail matters for other platforms.

Shipping now (gated, not the unconditional flip)

Your patch is mechanically correct — buildLaunchOptions(false) is headed and does already append OFFSCREEN_POSITION_ARG. But I can't ship it unconditionally: it would hard-break headless Linux, which is a first-class target here.

The failure is asymmetric today. headedBootstrap() swallows its own errors and falls back to cache, so a display-less Linux box works right now (Phase 1 fails soft → Phase 2 headless succeeds). init() has no such catch — it rethrows. A headed Phase 2 with no X/Wayland throws Missing X server or $DISPLAY, which doesn't match the launch-retry regex, so it rethrows immediately and the daemon dies on start. It would also silently override PERPLEXITY_HEADLESS_ONLY=1 for stdio-in-process, airgapped, and doctor-probe users who explicitly opted out of a UI.

So the shipped version is display-aware: headed-offscreen on macOS/Windows (your fix, by default), headless where no DISPLAY/WAYLAND_DISPLAY exists, plus a PERPLEXITY_PERSISTENT_HEADED=1|0 override in both directions.

Correction 1: there is no ~6.5s watchdog

There's no watchdog and no 6500 constant anywhere in the server — worth correcting so nobody greps for a phantom timer. But your constant ~6.5s has a very good explanation, and it points somewhere interesting:

LOCK_CONTENTION_RE in fs-utils.js literally matches the string "target page, context or browser has been closed", so launchWithRetry classifies your error as retriable lock contention and burns 4 attempts + 200/400/800ms backoff before rethrowing — ≈6.5s. That's your constant, almost exactly.

Correction 2: the repro may not test the path that's actually broken

Your repro used a fresh profile, which shows headless can't solve a challenge from scratch. The code already assumes that — client.ts says verbatim "Phase 1 (headed): Cloudflare Turnstile cannot be solved by headless browsers." The two-phase design never claimed headless could solve CF; it claims headless can reuse the cf_clearance that Phase 1 just earned. Your repro doesn't exercise the reuse path, so it doesn't yet demonstrate Phase 2 is broken.

Meanwhile there are two competing explanations for your exact error string:

• Chromium profile singleton-lock contention (Diagnostics follow-up (requested) + new bug: exitCode=21 persistent context lock conflict — 0.8.44 #8). Our own doctor probe documents "Target page, context or browser has been closed" as the signature of a second launchPersistentContext on the same browser-data. You mention an earlier daemon pile-up — and on POSIX that collision makes Chromium exit silently (exit 0), which would let the launch return and then kill page.evaluate, matching your error prefix precisely.
• Version skew. Your Chrome auto-updated to 150 on 2026-07-15 — one day before onset — against our pinned patchright ^1.59.4.

Two questions that would settle it

1. Re-run your repro against a profile a headed session just cleared (not a fresh one). That's the path Phase 2 actually uses, and it's the only thing that distinguishes "CF hard-blocks headless entirely" from "headless can't solve from scratch" (which we already knew).
2. Daemon log lines around the failure. If you see Browser launch hit a profile-lock collision (attempt N/4), this is Diagnostics follow-up (requested) + new bug: exitCode=21 persistent context lock conflict — 0.8.44 #8 lock contention rather than CF, and the headed flip would be treating a symptom. Your ~6.5s matches that retry budget suspiciously well.

If you have a moment, testing headless against Chrome 149 or patchright 1.61.1 would rule out the third candidate.

Either way the gated fix restores service for you today — I'd just like to know whether we're fixing the disease or the symptom, since it decides whether headless Linux servers still have a working path at all.

[ARHAEEM]

Status update — the shipped default has changed, and the evidence picture has too.

The headed-offscreen Phase 2 default is reverted; headed is now opt-in (PERPLEXITY_PERSISTENT_HEADED=1). Two reasons:

1. It caused a confirmed regression. The off-screen positioning (--window-position=-32000,-32000) was designed for the ~20-second Phase 1 bootstrap. Phase 2's window is long-lived: it has a taskbar presence, and ordinary events — clicking the taskbar icon, DPI/display changes, the window manager rescuing off-screen windows — bring it fully on-screen. A permanently visible Chrome window was observed on a real Windows device within a day.
2. The benefit remains unconfirmed, and Daemon lifecycle: stale-reclaim releases the lockfile but never kills the orphan process → multiple daemons pile up and fight over the shared browser profile #15 weakened it further. Your repro demonstrates headless can't solve a fresh challenge — which the two-phase design already assumes (Phase 1 exists for exactly that). It doesn't test the cf_clearance reuse path. Meanwhile Daemon lifecycle: stale-reclaim releases the lockfile but never kills the orphan process → multiple daemons pile up and fight over the shared browser profile #15 documents five simultaneous daemons on this same machine fighting over one browser-data profile — and a profile singleton-lock collision produces the identical "Target page, context or browser has been closed" error (our probe documents that string as the Diagnostics follow-up (requested) + new bug: exitCode=21 persistent context lock conflict — 0.8.44 #8 signature; on POSIX the collision exits silently, matching the page.evaluate failure shape).

What's on main now attacks the pile-up directly: stale-reclaim fences live holders before releasing the lock (#15), a wedged daemon (live pid, never-healthy port) is killed and replaced, a daemon from a previous build is stopped rather than attached to (code-graph version gate), and the reinit crash that killed daemons under a failing background refresh is fixed.

The clean experiment, once you're on a build with those fences: exactly one daemon alive, run the repro against a profile a headed session just cleared (the reuse path, not a fresh profile). If headless still gets re-challenged there, that's the confirmation the headed opt-in needs to become louder — and I'll happily revisit the default with that evidence in hand. If it doesn't, this issue resolves as a #15 duplicate in effect, and the CF theory retires.