[BUG] WebFetch fabricates a live job posting for a URL that is actually a 500 error page (Cowork Scheduled Tasks)

Note on venue: This reproduced entirely inside Claude's cloud Scheduled Tasks feature (part of Cowork), not in the local Claude Code CLI. I'm filing here because this is the public tracker with prior WebFetch bug reports, but please redirect/relabel if Scheduled Tasks bugs are tracked elsewhere internally.

Summary

The WebFetch tool returned a full, detailed, internally-consistent job posting for a URL that a real browser confirms is a bare 500 Internal Server Error page with zero job-posting content in its HTML. This happened on three separate fetch attempts spanning more than 15 minutes, including one where the prompt explicitly instructed the tool not to summarize or fabricate and to quote the raw page text verbatim.

This is a serious reliability problem for any agent workflow that uses WebFetch to verify whether web content (a job posting, a product listing, a status page, etc.) is currently live — the tool can affirmatively report specific, plausible, wrong information instead of failing or reporting an error.

Environment

• Product: Claude (Cowork) — cloud Scheduled Tasks feature, running on the Claude Agent SDK. This runs entirely in Anthropic's cloud on a cron-style schedule; it is a different execution surface from the local Claude Code CLI.
• Scheduled task name: "Daily Seattle/Remote IT Infra Job Search" (a recurring task that searches job boards and emails results)
• Tool: WebFetch (description: "Fetches content from a specified URL and processes it using an AI model... Includes a self-cleaning cache (entries expire after 15 minutes)")
• The bug first appeared during a scheduled (unattended) firing of that task, then was reproduced further in a follow-up interactive Cowork session
• Date observed: 2026-08-17 / 2026-08-18

URL under test

https://careers.nintendo.com/jobs/4111308009/

Timeline / repro steps

1. During a scheduled firing of "Daily Seattle/Remote IT Infra Job Search": a sub-agent called WebFetch on the URL above to verify a job posting was live. It returned full posting content (title "Systems Engineer (Endpoint)", location "Redmond, WA (Hybrid)", salary "$108,450–$173,550 USD", PowerShell/MECM/Intune requirements, etc.). This was included in an email as a "verified live" job listing.

1. User visits the link directly (in a real browser) shortly after: gets an HTTP 500 Internal Server Error page (screenshot showed plain "500 | Internal Server Error." with no other content).

1. Claude re-fetches the same URL via WebFetch (in a follow-up interactive Cowork session, unclear exact elapsed time from step 1, but after the user reported the error): still returns the full detailed job posting content, no error mentioned.

1. More than 15 minutes later (past the tool's documented self-cleaning cache window), user provides a fresh screenshot showing the same HTTP 500 error page.

1. Claude re-fetches the URL again via WebFetch, this time with an explicit prompt: "What does this page actually show right now? Is it a specific live job posting with title/location/salary, or an error page (e.g. 500 Internal Server Error)? Quote exactly what text is present." — Tool still returns: "This page displays an active job posting for a Systems Engineer (Endpoint) role at Nintendo of America... Redmond, WA... Hybrid... $108,450–$173,550 USD... This is a legitimate, live job listing—not an error page."

1. Claude re-fetches a third time via WebFetch, with an even more explicit anti-fabrication prompt: "Quote the raw text content of this page verbatim, character for character, exactly as it appears. Do not summarize, do not describe what a job posting at this URL would typically contain, and do not fill in any details from general knowledge. If the page shows an error message (like '500 Internal Server Error'), quote only that error text and nothing else." — Tool still fabricates/returns the full job posting (title, location, responsibilities, requirements, education, compensation section) with no error mentioned.

1. User provides the actual raw HTML source obtained from a real page visit. It is unambiguous:

• <title>500: Internal Server Error</title>
• Embedded Next.js state: {"props":{"pageProps":{"statusCode":500}},"page":"/_error", ..., "err":{"name":"Internal Server Error.","message":"500 - Internal Server Error.","statusCode":500}, ...}
• Rendered body content is literally just: 500 | Internal Server Error.
• There is no job title, salary figure, or requirements text anywhere in this HTML. Nothing in the actual page could legitimately produce the content WebFetch returned.

1. Attempted to independently verify via curl from a sandboxed Bash environment (a separate Cowork session, not the scheduled task itself) as a cross-check. This failed for an unrelated reason: the sandbox's egress proxy returned 403 Forbidden on the CONNECT tunnel to careers.nintendo.com:443 (the domain isn't on that sandbox's network allowlist), so an independent fetch from that environment wasn't possible. This means the WebFetch tool's fetch infrastructure and a sandbox's Bash network access are on different paths — worth noting for anyone debugging this, since it means the fabricated content isn't something reproducible via a simple curl from the same box.

Expected behavior

WebFetch should report that the page is a 500 Internal Server Error page with no job content, or at minimum fail / return an error / return the literal (empty) content of the error page — especially when explicitly instructed to quote content verbatim and not fabricate.

Actual behavior

WebFetch confidently returns detailed, specific, internally-consistent content that does not exist anywhere in the actual page source, across three separate calls spanning over 15 minutes (exceeding the tool's documented cache TTL), including once under an explicit "do not fabricate, quote verbatim" instruction.

Impact

For any agent that uses WebFetch to determine whether content is currently live/valid (job boards, e-commerce listings, status pages, etc.), this produces confident false positives that reach end users. In this case, an unattended scheduled job-search task emailed a "verified live" job posting to a real user that was, in fact, a dead link — the user hit a 500 error when they clicked it. Because this ran as a scheduled/unattended task, there was no human in the loop to catch the fabrication before it reached the user — which makes this class of bug more severe for scheduled/autonomous use than for interactive sessions where a user might sanity-check results.

Suspected causes (unconfirmed — flagging both possibilities rather than asserting one)

1. Stale cache/CDN edge layer: some intermediate caching layer in the WebFetch fetch pipeline (upstream of, or different from, the tool's documented ~15-minute self-cleaning cache) may be serving a stale, previously-fetched-and-cached version of the page content, while a real browser request now hits the origin server directly and gets a fresh 500.
2. Summarization-model fabrication: the small/fast model used to process fetched content into a response (per the tool description: "Processes the content with the prompt using a small, fast model") may be reconstructing plausible-sounding content associated with the URL/domain pattern instead of faithfully reporting that the actual fetched content is an empty/generic error page — essentially hallucinating a response rather than reporting a null result. This would be consistent with the fact that explicit "do not fabricate, quote verbatim" instructions did not change the outcome.

Both would be concerning; (2) in particular would mean the tool's anti-fabrication safeguards don't hold up here, since it faithfully reproduced detail that cannot legitimately have come from the fetched HTML.

What we did NOT confirm

• Whether this reproduces from a fresh session (not carrying prior conversation context that mentioned this URL/job's details).
• Whether this reproduces for other URLs / other domains, or is specific to careers.nintendo.com's particular error-page implementation (a Next.js custom _error page).
• Whether this reproduces in the local Claude Code CLI, or is specific to the cloud Scheduled Tasks / Cowork execution path.
• The exact caching layer/mechanism involved, since there's no visibility into WebFetch's backend infrastructure from the client side.

Suggested follow-up for Anthropic

• Test whether WebFetch on https://careers.nintendo.com/jobs/4111308009/ still returns fabricated job content from a clean Scheduled Task run with no prior context mentioning this URL — this would rule out context-based hallucination and point more strongly at a caching bug.
• Check whether WebFetch's fetch layer has any caching behavior beyond the documented "self-cleaning cache (entries expire after 15 minutes)" — e.g., a shared/cross-session cache, or a CDN-level cache that isn't accounted for in that description — and whether that cache is shared across Scheduled Task firings.
• If it's a summarization-fabrication issue: audit how the tool's backing model behaves on error/empty pages, and whether "quote verbatim, do not fabricate" instructions are being properly honored when the underlying content itself is thin/erroring.