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.