Skip to content

Comments

Add Perplexity cookie-auth fallback + Cloudflare retry path#7

Open
damianpdr wants to merge 3 commits intonicobailon:mainfrom
damianpdr:fix/perplexity-cloudflare-cookie-fallback
Open

Add Perplexity cookie-auth fallback + Cloudflare retry path#7
damianpdr wants to merge 3 commits intonicobailon:mainfrom
damianpdr:fix/perplexity-cloudflare-cookie-fallback

Conversation

@damianpdr
Copy link

Summary

This PR makes web_search more resilient when Perplexity API keys are missing/invalid and when Perplexity web requests are blocked by Cloudflare in Node fetch.

What changed

  • Added Perplexity Chrome-cookie auth support on macOS:
    • chrome-cookies.ts now supports Perplexity origins and relevant cookie names.
    • isPerplexityAvailable() now considers local Chrome cookie availability.
  • Added fallback chain in perplexity.ts:
    • Try Perplexity API key path first.
    • On auth/rate/network failure, fallback to Perplexity web cookie-auth.
  • Added Cloudflare 403 handling for Perplexity web endpoint:
    • Detect challenge pages (Just a moment..., cf challenge markers).
    • Retry via Python curl_cffi Chrome impersonation.
    • Auto-bootstrap a local venv at ~/.pi/cache/pi-web-access/curl-cffi-venv on first use.
  • Improved provider behavior in search routing and curator flow:
    • Preserve provider selection correctly when switching providers in curator.
    • Keep auto-provider behavior while allowing explicit provider pinning.
  • Updated docs/changelog:
    • README now documents Perplexity cookie-auth and Cloudflare fallback behavior.
    • Unreleased changelog entries added.

Why

In some environments, Perplexity web endpoint calls from Node fetch get blocked by Cloudflare (403 Just a moment...) even with valid logged-in Chrome cookies. Using curl_cffi with browser impersonation resolves this and restores working Perplexity search.

Validation

Manual validation in local environment:

  • Node fetch + cookies to https://www.perplexity.ai/rest/sse/perplexity_ask returned Cloudflare 403.
  • Python curl_cffi + same cookies to same endpoint returned HTTP 200 SSE stream.
  • Perplexity cookie session endpoint (/api/auth/session) confirmed valid logged-in session.

Note: full project tsc in isolation still reports unrelated missing peer/dependency types in this environment; this PR focuses on runtime behavior and fallback correctness.

Notes

  • curl_cffi fallback requires python3 with venv support on macOS.
  • First fallback invocation may be slower due to venv/bootstrap install.

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0fab415b4f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

try {
const { answer, results } = await search(queryList[qi], {
provider: defaultProvider as SearchProvider | undefined,
provider: initialSearchProvider,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Keep provider mode consistent across curator searches

When requestedProvider is "auto", the initial query loop now calls search() with provider: undefined, so it can fall back from Perplexity to Gemini, but onAddSearch in the curator path still calls search() with a pinned provider (pc.defaultProvider/currentProvider). In environments where Perplexity is detected but unusable at runtime (e.g., Chrome installed but no active Perplexity session), initial queries can succeed via Gemini while added queries fail with Perplexity auth errors, which makes the same curator session behave inconsistently.

Useful? React with 👍 / 👎.

@damianpdr
Copy link
Author

Thanks, this is valid and fixed in d284554.\n\nI introduced a small helper and now use it consistently in both curator paths:\n- initial query batch\n- callbacks\n\nBehavior now stays consistent when the requested provider is (it passes so runtime fallback can still occur), while explicit provider selections in the curator continue to pin to the chosen provider.

@damianpdr
Copy link
Author

Follow-up with exact details:

✅ Fixed in commit d284554.

I added a helper:

  • resolveSearchProvider(requestedProvider, resolvedProvider)

and use it consistently in both curator paths for:

  • initial query batch
  • onAddSearch callbacks

Result:

  • when requested provider is auto, both paths pass provider: undefined (so runtime fallback still works)
  • when user explicitly switches provider in curator, both paths pin to that selected provider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant