[BUG] `web_fetch` (Cowork mode) returns stale cached JSON, ignores server no-store

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The mcp__workspace__web_fetch tool in Cowork mode returns a stale (previous-day) JSON response. I fetched the same URL twice, several minutes apart, and both calls returned yesterday's generated timestamp. An independent curl request to the same URL, made outside the session at roughly the same time, correctly returned today's data. The server sends Cache-Control: no-store on its responses.

What Should Happen?

When the origin server sends Cache-Control: no-store, web_fetch should not reuse a cached response — it should fetch fresh every time and return the same up-to-date data that curl returns.

Error Messages/Logs

(separate error hit while trying to bypass the suspected cache)
URL not in provenance set. web_fetch can only retrieve URLs that appeared in a user message or a prior web_fetch result. Ask the user to include the URL in a message first.

Steps to Reproduce

1. Stand up a JSON API endpoint that regenerates daily and sends Cache-Control: no-store (e.g. a Cloudflare Worker).
2. In a Cowork session, call web_fetch on that URL and record the timestamp field in the response.
3. Outside the session, curl the same URL directly and confirm the server is currently serving up-to-date data.
4. In the same Cowork session, call web_fetch again on the identical URL.
5. Observe that the response timestamp is still the stale value from steps 2, not the current value confirmed in step 3.
6. (Optional) Try to force a cache bypass by appending a cache-busting query param (e.g. &_cb=1). This fails with "URL not in provenance set" — since only URLs already seen in the conversation can be fetched, there's no way to force a fresh request either.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

N/A

Claude Code Version

N/A — this occurred in Cowork mode (Claude Desktop), not the Claude Code CLI.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

A third sibling endpoint fetched in the same batch returned the correct same-day timestamp both times, suggesting the staleness is per-URL/cache-key rather than a total fetch outage. Not certain this repo (claude-code) is the right channel for a Cowork-mode bug — flagging that uncertainty for triage.

Evidence (raw excerpts)

• screen fetch #1: "generated":"2026-07-15 08:06 KST"
• screen fetch #2 (retry, same URL, minutes later): "generated":"2026-07-15 08:06 KST" (unchanged)
• portfolio fetch #1: "generated_at":"2026-07-15T08:08:34"
• portfolio fetch #2 (retry, same URL): "generated_at":"2026-07-15T08:08:34" (unchanged)
• briefing fetch (same batch, both times): "generated":"2026-07-16 08:06 KST" (correctly current)
• Independent curl against the same three URLs, run outside the Claude session at roughly the same time, returned all-current timestamps (2026-07-16 for all three).