[BUG] Title: Agent substitutes its own curl success for browser-fetch evidence, ignoring user-supplied "zero log entries" proof
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?
---
Title: Agent substitutes its own curl success for browser-fetch evidence, ignoring user-supplied "zero log entries" proof
Body:
What happened
During a debugging session, a frontend fetch() call was silently failing to reach a Flask backend — the actual cause was a relative URL path that resolved against the browser page's own origin instead of the backend's origin (a classic same-origin-by-accident bug: it worked whenever page and server happened to share a host:port, and broke otherwise with zero trace).
The user had already supplied the single strongest piece of evidence available: the Flask access log for the failure window, showing zero requests to the endpoint in question. That is direct proof the request never left the browser correctly.
Instead of treating that log as the primary clue and investigating the request layer (URL construction / page origin vs. server origin) first, I:
- Ran curl directly against the endpoint from my own shell to check the backend was healthy. It returned 200 with correct data.
- Treated that curl success as equivalent to "the browser's fetch call reaches the backend fine," and stated this to a sub-agent I dispatched as settled fact ("the backend is correct and not in question").
- The sub-agent, briefed this way, investigated the charting library/rendering pipeline instead — and in its own fresh browser tab (which happened to be same-origin with the backend), the bug didn't reproduce, so it reported "no defect found." A false negative, directly downstream of my false premise.
Why this is a real gap, not just one mistake
curl has no concept of "page origin" — it always targets the literal URL given. A browser's fetch('/relative/path') resolves against whatever origin the page itself was loaded from. These are not interchangeable tests, but I used the first to validate the second without noting the difference.
Suggested improvement
- User-supplied evidence of "zero requests received" should outweigh and be checked before "I verified the server directly."
- A CLI call to a backend endpoint is not a valid stand-in for reproducing a browser's actual request path.
- When briefing a sub-agent with a claim like "X is confirmed working," the claim's actual evidentiary basis should be stated too.
What Should Happen?
it should have fix bug and check flaskserever out put while ishared
Error Messages/Logs
Steps to Reproduce
dont know i am not techie ... issue report is clear in curl process
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.201 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗