[BUG] Title: Agent substitutes its own curl success for browser-fetch evidence, ignoring user-supplied "zero log entries" proof

Status Open
Reported on v2.1.201
Maintainer reply None cached
Activity 1 comment · opened Oct 14, 2026

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:

  1. Ran curl directly against the endpoint from my own shell to check the backend was healthy. It returned 200 with correct data.
  2. 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").
  3. 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.

feedback_draft.md

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_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗