v1.17.0

A browser tab can clear a site’s challenge, follow its redirect, and render a PDF. Then a second request for that same PDF can still get blocked.

That was the remaining hole in inline-PDF retrieval.

Thanks to Anand Patel for reporting #9334, reproducing this with PubMed Central’s challenge flow, and contributing #10784.

Inline PDFs now use what the browser actually received

POST /tabs/:tabId/fetch-current-resource now first uses the matching main-frame PDF response already received by the managed browser tab.

This matters for sites where the tab can render the PDF after a JavaScript or bot-check redirect, but a separate Node-side request gets HTML or a 403.

The route still stays scoped to the current managed tab and its existing download-artifact flow. It does not add arbitrary authenticated fetches.

Known oversized PDFs are rejected from their Content-Length before their body is read. The existing 50 MiB limit remains in place.

More reliable recovery

• A create-tab request now has enough time to rebuild one unhealthy browser session and create its replacement page.
• The E2E client retries the documented recoverable session-restart response instead of treating a browser RSS-safety restart as permanent failure.

OpenClaw and Windows maintenance

• Updated the OpenClaw plugin to the current Plugin SDK contract.
• The package now uses the declared Camoufox downloader directly.
• Added reproducible macOS/UTM tooling for investigating hosted Windows E2E failures locally. Generated VM media and disks are not part of the repo.