Summary
A generic HTTP 403 from the agent's own fetch tool does not steer it to webcmd web fetch. There is no structured FETCH_BLOCKED / FETCH_REQUIRES_BROWSER on that path, so the agent retries the same URL or jumps straight to a raw browser session.
webcmd web fetch exists and is listed in webcmd list. The eval never invoked it.
What the eval actually did (v0.7.4, blocked-source-research)
webfetch GET https://www.scrapingcourse.com/cloudflare-challenge → raw StatusCode: non 2xx (403).- Retried the same URL as HTML. Same 403.
- Loaded
webcmd-browser, created a session, completed the page in the browser.
- Never ran
webcmd web fetch / webcmd fetch. Check tls-escalation failed. Score 4.0.
The prompt said: start with direct retrieval; if the demonstration reports browser-required or blocked after automatic retrieval escalation, continue in one browser workspace.
The agent treated the first 403 as the end of the non-browser path. Nothing in that 403 named webcmd web fetch or a TLS-impersonating retry.
Why they did that
webcmd web fetch is the command that does non-browser TLS escalation and can return FETCH_BLOCKED / FETCH_REQUIRES_BROWSER. It is not what webfetch (the agent runtime tool) is. After a raw 403, the next discoverable move is "open a browser," not "try the other fetch."
#247 / #252 / #264 / #283 covered fetch internals. This is the discovery gap: a blocked generic fetch does not point at Webcmd's fetch.
Fix
- Skills (
webcmd-usage, smart-search): after a non-2xx / challenge on a direct fetch, the next command is webcmd web fetch --url …, not browser run.
webcmd web fetch errors must stay structured (FETCH_BLOCKED, FETCH_REQUIRES_BROWSER) and name the one browser fallback.webcmd list / --help should make fetch findable from "blocked," "403," and "Cloudflare."
Check
An agent that only has a raw 403 and webcmd --help / webcmd list can name webcmd web fetch as the next call. A webcmd web fetch of the eval URL returns a structured blocked/browser-required result, not a raw status line.
Summary
A generic HTTP 403 from the agent's own fetch tool does not steer it to
webcmd web fetch. There is no structuredFETCH_BLOCKED/FETCH_REQUIRES_BROWSERon that path, so the agent retries the same URL or jumps straight to a raw browser session.webcmd web fetchexists and is listed inwebcmd list. The eval never invoked it.What the eval actually did (v0.7.4,
blocked-source-research)webfetchGEThttps://www.scrapingcourse.com/cloudflare-challenge→ rawStatusCode: non 2xx (403).webcmd-browser, created a session, completed the page in the browser.webcmd web fetch/webcmd fetch. Checktls-escalationfailed. Score 4.0.The prompt said: start with direct retrieval; if the demonstration reports browser-required or blocked after automatic retrieval escalation, continue in one browser workspace.
The agent treated the first 403 as the end of the non-browser path. Nothing in that 403 named
webcmd web fetchor a TLS-impersonating retry.Why they did that
webcmd web fetchis the command that does non-browser TLS escalation and can returnFETCH_BLOCKED/FETCH_REQUIRES_BROWSER. It is not whatwebfetch(the agent runtime tool) is. After a raw 403, the next discoverable move is "open a browser," not "try the other fetch."#247 / #252 / #264 / #283 covered fetch internals. This is the discovery gap: a blocked generic fetch does not point at Webcmd's fetch.
Fix
webcmd-usage,smart-search): after a non-2xx / challenge on a direct fetch, the next command iswebcmd web fetch --url …, notbrowser run.webcmd web fetcherrors must stay structured (FETCH_BLOCKED,FETCH_REQUIRES_BROWSER) and name the one browser fallback.webcmd list/--helpshould makefetchfindable from "blocked," "403," and "Cloudflare."Check
An agent that only has a raw 403 and
webcmd --help/webcmd listcan namewebcmd web fetchas the next call. Awebcmd web fetchof the eval URL returns a structured blocked/browser-required result, not a raw status line.