pup_fetch_url fails while same-tab in-page fetch reads the manufacturer file

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

Environment: Windows on AdomLapper, Linux/WSL2 caller, Adom Bridge 2.1.86, Pup 2.0.452 (Rust; version collected in this session), adom/codex 0.1.22. Observed 9 September 2026.

In the owned TMF8829 Depth Lab Pup window, tab-2 was on the official Nexperia 74LVC2G07 product page. A direct container request for the datasheet got HTTP 403, so the task used the real background browser.

From that tab, pup_eval running fetch("https://assets.nexperia.com/documents/data-sheet/74LVC2G07.pdf") read an ArrayBuffer successfully: HTTP 200, 269669 bytes. The same worked for https://assets.nexperia.com/documents/design-support/SOT457.step: 263744 bytes.

But pup_fetch_url with explicit sessionId:"TMF8829-Depth-Lab", tabId:"tab-2", the identical PDF URL and saveTo:"/home/adom/project/tmf8829-depth-lab/docs/research/74LVC2G07.pdf" returned:

{"ok":false,"errorCode":"fetch_failed","error":"pup_fetch_url failed: Failed to fetch","shell":"rust"}

Its hint blames CORS and recommends navigating instead. That explanation is not established: the identical URL is readable through in-page fetch on the explicitly named tab. No browser login, changed security settings or foreground takeover was needed.

Workaround actually completed: fetch in that same tab, return the original bytes encoded for transport, decode in the caller and verify PDF/STEP signatures and SHA256. PDF SHA256: ab1143004c56f8094bbac36229b967f78a2f4f80be33d27a863840aa39b52698.

Please verify the Rust fetch verb uses the requested tab's execution context and distinguish browser-fetch failure from caller-path transfer failure. Return the resolved tab/origin, actual failure stage and useful AI hints without credentials. A claimed save must be verified in the caller filesystem. No tab-switching bug was observed: one owned window with explicit tabs and concurrent tab-targeted reads works.

Attached is the exact failed reply. Checked the existing issue list; the closed evaluate-routing and favicon-fetch reports do not cover this reproduction. Root cause remains unconfirmed.

pup-fetch-explicit-nexperia.json

2 Replies

John Lauer · 1mo ago

Fixed in pup 2.0.648 (insiders). Two defects, both measured on ConfRoomROG against the reporter's exact URL from the Nexperia product page tab: (1) the verb sent credentials:'include' on a cross-origin fetch, which the browser refuses when the asset server answers Access-Control-Allow-Origin: * ('Failed to fetch'); the reporter's plain in-page fetch had no credentials, hence it worked. pup now tries with credentials and retries without on a TypeError. (2) r.text() destroyed binary bodies; the body is read as an ArrayBuffer and returned as bodyBase64 with sha256. Result: httpStatus 200, application/pdf, 269669 bytes, sha256 ab1143004c56f8094bbac36229b967f78a2f4f80da... matches the reporter's ab1143...52698 exactly, via credentials:'omit'. Errors now carry stage (browser-fetch / evaluate), pageOrigin, tabId and pageUrl. saveTo: pup runs on the desktop and cannot write a container path; the response says so and hands back bodyBase64 for the caller to write and verify. Also runs on the extension lane (it went to a CDP session that lane never had).

John Lauer closed this · 1mo ago

John Lauer · 1mo ago

Correction to the close note: saveTo DOES work for a container path. The CLI takes the bodyBase64 pup returns, writes the file where you asked, and reports savedTo + savedToFilesystem:'container'. Re-measured on ConfRoomROG: 269669 bytes written, %PDF- header, sha256 ab1143...52698, identical to the reporter's. My first measurement showed 0 bytes only because my own test script truncated the file after the CLI had written it.