0.3.1 — Perplexity streaming restored after CORS enforcement change

Why care?

If you clicked Ask Perplexity or ran a directory template and got a CORS error — or just got nothing — this is the fix. Streaming was broken for every Perplexity query. Non-streaming requests were unaffected.

Perplexity's API stopped including the Access-Control-Allow-Origin header that Electron's Chromium renderer requires before it will hand a response body to calling code. The request was arriving and returning 200 OK — Chromium was reading the headers, seeing no CORS allowance for app://obsidian.md, and then blocking the body. The underlying request was succeeding; the plugin just couldn't see any of it.

What changed?

Both streaming code paths now use https.request from Node.js's built-in node:https module instead of activeWindow.fetch. Node.js routes requests through the OS network stack — below Chromium entirely. CORS enforcement is a Chromium concept; it has no meaning at the OS socket layer.

• Modal query flow (perplexityService.ts) — the quick Ask Perplexity command and all model variants
• Directory template runner (directoryTemplateService.ts) — the streamPerplexityToFile function used by every template that calls Perplexity

The SSE parsing, idle-timeout, chunk accumulation, citations, images, and AbortController signal handling are all untouched. This is a pure transport-layer swap.

Before:  activeWindow.fetch → Chromium renderer → CORS enforcement → body blocked
After:   https.request → Node.js network stack → OS socket → no CORS

Upgrade notes

Reload the plugin after upgrading (Settings → Community Plugins → Perplexed → toggle off, then on). No vault-template changes, no new settings, no new cft-block keys. All 0.3.0 analyst-grade templates and infrastructure are fully intact.

Full changelog

See changelog/releases/0.3.1.md for the full release narrative and changelog/2026-07-06_01.md for the engineering detail.