Skip to content

fix: surface HTTP errors in fetch_url_to_workspace instead of saving error pages - #5

Open
hofftodd wants to merge 1 commit into
kyuz0:mainfrom
hofftodd:fix/fetch-http-errors
Open

hofftodd wants to merge 1 commit into
kyuz0:mainfrom
hofftodd:fix/fetch-http-errors

Conversation

@hofftodd

@hofftodd hofftodd commented Jul 9, 2026

Copy link
Copy Markdown

Summary

fetch_url_to_workspace in the basic-tui-agent scaffold never checks the HTTP status, so a 403/404 block page is saved to the workspace as if it were real content and the tool reports "Fetched URL successfully". Downstream, an analyzer agent reads the junk, reports the file empty/invalid, and the searcher retries with new queries and URLs until it exhausts its web_search quota and loop-detection aborts the run. A first-try-correct answer degrades into a delegation loop.

Changes

  • Call resp.raise_for_status() and return a clear, actionable error ("HTTP N, page NOT saved, do not retry, use a different source") instead of writing the error page as content. The generic exception path gets the same actionable phrasing (the old raw-traceback return gave the model nothing to act on).
  • Use a descriptive User-Agent derived from APP_NAME (following the existing import config as app_config pattern in web_search). The spoofed 2021 Chrome UA was itself triggering bot-blocking: sites like Wikipedia return 200 with a descriptive UA where the old one got 403. Deriving it from APP_NAME means generated agents automatically identify themselves correctly.

Verification

Verified in a generated agent: Wikipedia now saves 160KB+ of real markdown (previously an empty 403 block page was saved); a genuinely blocked source (Britannica) returns the error message and writes no file.

Context

Found while debugging an agent generated by this skill — this is the scaffold-level version of kyuz0/deep-research-agent#3.

🤖 Generated with Claude Code

fetch_url_to_workspace never checked the HTTP status, so a 403/404
block page was saved to the workspace as if it were real content and
the tool returned "Fetched URL successfully". Downstream, an analyzer
agent reads the junk, reports the file empty/invalid, and the searcher
retries with new queries and URLs until it exhausts its web_search
quota and loop-detection aborts it. A first-try-correct answer thus
degrades into a delegation loop.

Two changes:
- Call resp.raise_for_status() and return a clear, actionable error
  ("HTTP N, page NOT saved, do not retry, use a different source")
  instead of writing the error page as content.
- Use a descriptive User-Agent derived from APP_NAME. The spoofed 2021
  Chrome UA was itself triggering bot-blocking; sites like Wikipedia
  return 200 with a descriptive UA where the old one got 403.

Verified in a generated agent: Wikipedia now saves 160KB+ of real
markdown (previously an empty 403 page); a genuinely blocked source
(Britannica) returns the error message and writes no file.

Found while debugging an agent generated by this skill
(kyuz0/deep-research-agent); this upstreams the same fix.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant