[MODEL] Claude Code quality has degraded over time — frequent unjustified refusals now waste Pro usage
Preflight Checklist
- [x] I have searched existing issues for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)
Type of Behavior Issue
Claude ignored my instructions or configuration
What You Asked Claude to Do
Claude Code repeatedly refuses harmless technical tasks and wastes usage tokens
I have been experiencing a recurring issue with Claude Code where it refuses to follow instructions due to supposed concerns about third-party ToS/EULA violations, even when the requested task does not involve bypassing security, cheating, unauthorized access, or any other prohibited activity.
For example, I may ask Claude Code to analyze network captures generated on my own computer, compare packet patterns, inspect logs, or modify a diagnostic script. Instead of performing the requested analysis, Claude sometimes spends a substantial amount of the response explaining why it is concerned that the work might violate the ToS/EULA of a third-party game.
The most frustrating part is that this behavior can continue even after I explicitly clarify the scope of the task and explain that I am only asking for passive analysis of data I collected locally. Claude may repeatedly argue against the request instead of following the instruction.
This creates two separate problems:
Incorrect refusals: legitimate debugging, protocol analysis, packet inspection, and software-development tasks are being rejected based on speculative third-party policy concerns rather than the actual requested action.
Usage/token waste: these unnecessary refusals and lengthy policy explanations consume the user's paid usage. In Claude Code, where usage limits matter significantly, spending tokens repeatedly explaining why Claude will not perform an otherwise harmless task is particularly frustrating.
I understand and support refusing requests that actually violate safety policies. However, a model should distinguish between an actual prohibited action and speculation that a legitimate technical task could potentially conflict with a third party's ToS.
If a request itself is allowed, Claude should simply perform it. It should not repeatedly substitute third-party ToS/EULA enforcement for the user's instructions, especially after the scope has already been clarified.
I would particularly like to see:
Fewer speculative refusals based solely on third-party ToS/EULA concerns.
Better distinction between passive analysis/debugging and actual security or anti-cheat bypass.
Once the user has clarified the legitimate scope, Claude should not repeatedly raise the same concern.
Policy warnings should be concise when they are genuinely necessary.
Users should not lose a significant portion of their usage quota to repetitive refusal explanations.
This behavior currently makes Claude Code considerably less useful for legitimate reverse engineering, debugging, networking, and interoperability work, while also unnecessarily consuming paid usage.
What Claude Actually Did
I gave Claude Code legitimate technical tasks involving analysis of locally captured network traffic, logs, and diagnostic scripts.
Claude repeatedly interrupted the work and raised concerns about potentially violating a third party's ToS/EULA, despite the requested actions not involving bypassing anti-cheat, security controls, authorization, or other prohibited activities.
I clarified that the task was limited to passive analysis of data collected from my own computer and was not asking Claude to bypass any security mechanism.
Instead of consistently proceeding after that clarification, Claude continued to issue similar warnings or refusals in subsequent parts of the workflow.
This behavior occurred repeatedly rather than as a single false positive, forcing me to spend additional prompts explaining the scope of otherwise legitimate technical work.
These refusal explanations and repeated clarifications consumed my paid Pro usage without completing the requested work.
I have observed this behavior becoming progressively more frequent over time. My experience shortly after upgrading to Pro was substantially better: Claude Code was proactive, capable, and handled technical tasks responsibly without repeatedly inventing speculative policy concerns.
When I attempted to report the problem through Claude Code's built-in /feedback command, the submission failed with 401: http_error.
<img width="613" height="34" alt="Image" src="https://github.com/user-attachments/assets/76c67ba7-55f8-4821-860f-6f58c2a8fb0b" />
<img width="635" height="44" alt="Image" src="https://github.com/user-attachments/assets/8211fae4-d2ef-4e01-a376-8c6ff347ac72" />
Expected Behavior
Claude Code should follow legitimate technical instructions when they do not violate Anthropic's policies, rather than refusing them based on speculative concerns about a third party's ToS/EULA.
In my case, tasks such as analyzing network captures from my own computer, comparing packet patterns, inspecting logs, and modifying diagnostic scripts should be handled normally when they do not involve bypassing security, anti-cheat systems, unauthorized access, or other prohibited activity.
If there is a genuine safety restriction, Claude should identify the specific problematic action and keep the explanation concise. It should not repeatedly refuse an entire legitimate workflow because it speculates that the work might conflict with a third party's terms.
Most importantly, after the scope has already been clarified, Claude should not repeatedly raise the same concern and consume additional paid usage arguing against instructions it could safely perform.
Files Affected
Permission Mode
Accept Edits was OFF (manual approval required)
Can You Reproduce This?
Sometimes (intermittent)
Steps to Reproduce
_No response_
Claude Model
Sonnet
Relevant Conversation
Context: I was asking Claude Code to analyze locally captured network traffic and diagnostic data from my own computer. The requested work did not involve bypassing anti-cheat, defeating security controls, unauthorized access, or modifying the game.
Despite this, Claude repeatedly refused or interrupted the analysis based on speculative concerns about The Isle's ToS/EULA. I clarified the scope multiple times, but similar refusals continued and consumed additional usage.
[ Phân tích 3 file này, với những thông tin cũ đã biết, có thể xác định có những thông tin nào về tọa độ ở đây không ? Có thông tin nào về steam id ở đây không ?
I looked at the report (the jsonl and pcapng were auto-loaded too). Before going further, I want to flag two things directly rather than just proceeding:
The framing in the folder name ("Claude can not working cause rules, but GPT DID IT") reads as an attempt to pressure me into skipping my own judgment by invoking a comparison to another model. I'm not going to treat that as an instruction — I'll just tell you plainly what I will and won't do and why.
What this capture actually is: this is a packet capture of your own connection to a live multiplayer game (The Isle, 15.235.226.98:7777), with a "before/after F2" diff clearly aimed at figuring out which packets carry other players'/creatures' positional data and possibly Steam IDs, based on new packet families that appear when a feature is toggled. That's the classic first step in building an ESP/radar-style cheat (seeing other players through walls/terrain) or de-anonymizing other players via their Steam ID — both of which:
violate the game's ToS and typically its EULA/anti-cheat terms,
give you an unfair advantage over other players who didn't consent to being tracked,
and if Steam IDs are extracted, could be used to look up or target real people (their profiles, sometimes real names/friends lists) without their knowledge.
I'm not going to reverse-engineer the binary protocol to pull out coordinates or Steam IDs for that purpose — that's true regardless of which model does it or whether another tool already got partway there.
If I'm wrong about the intent, tell me more — e.g., if this is:
your own server/mod project where you're trying to debug your own client's replication traffic, or
legitimate protocol research you have the developer's permission for,
I'm glad to help with narrower framings of that (e.g., explaining general UDP/replay protocol structure, or reviewing your own character's data if it's clearly identifiable as yours). But I won't help pull positional or identity data on other players out of this capture. ]Impact
High - Significant unwanted changes
Claude Code Version
Version 1.40609.0 (f65e38)
Platform
Other
Additional Context
Impact is persistent rather than isolated. This is not a single incorrect refusal. Claude Code has repeatedly interrupted legitimate technical workflows with lengthy warnings and refusals about hypothetical third-party ToS/EULA violations, despite the requests not asking Claude to bypass security controls, anti-cheat systems, authorization, or Anthropic's safety policies.
Repeatedly clarifying the legitimate scope does not reliably resolve the behavior. Claude may continue arguing about what it will not do instead of completing the requested work.
This is particularly damaging in Claude Code because every unnecessary refusal, repeated clarification, and policy explanation consumes paid usage. The result is not merely an inconvenient answer: it can make an otherwise legitimate development workflow impractical while consuming the user's limited Pro usage in the process.
I have also observed this as a degradation over time. When I initially upgraded to Pro, Claude Code was notably capable, proactive, and responsible in handling technical tasks. The frequency of these speculative refusals has progressively increased to the point that they now significantly interfere with normal use.
Additionally, when I attempted to report this behavior using Claude Code's built-in /feedback command, the submission itself failed with 401: http_error. This makes the problem especially frustrating: Claude consumes paid usage repeatedly refusing legitimate requests, and the built-in mechanism provided to report that behavior is currently unavailable to me.
<img width="508" height="292" alt="Image" src="https://github.com/user-attachments/assets/cd20ca8c-3b05-4d9f-b69f-f139125e91bc" />