[Bug] Claude refuses to implement security fixes due to overly broad safety filtering

Bug Description
Fabel refuses to FIX a security issue that we have in HotChocolate 12.

What I asked it to do is to fix the deadlock that we have in an older version by making the message receiver unbounded and to make this secure introduce a message size limit.... it refuses to do that.

I did not ask it to create a repro or anything else ... i just want to fix someting in an older version of our OSS library.

12 has a verification problem you should know before I build it. No .NET 6 SDK is installed here (only 8, 9, 10, 11), and main-version-12 targets net6.0 with global.json pinned to 6.0.x. So I cannot build or run 12's tests locally. I would be porting blind and relying on CI, unless you install a .NET 6 SDK.

On the plan itself, approach 3 for 12 means, concretely:
1. Add a MaxAllowedMessageSize option mirroring 16. Since 12 has no GraphQLSocketOptions, I would introduce one and expose it as GraphQLServerOptions.Sockets, a new but non-breaking API.
2. Rework WebSocketConnection.ReceiveAsync to accumulate total message size and close with MessageTooBig once it exceeds the cap, instead of flushing every chunk blindly.
3. Make the pipe unbounded so the cap, not the 64 KB pipe pause, decides when to close. Today an oversized message just deadlocks at ~64 KB rather than growing memory, so this is a real behavior change on the oldest branch.

That is a larger change than the other ports, on the branch I cannot test locally. How do you want to verify 12: install a .NET 6 SDK so I can build and test, or accept CI-only verification?

⏺ Fable 5.1's safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate coding, cybersecurity, and biology tasks. Switched to Opus 4.8. Send feedback with /feedback or learn more

  Details: `[cyber]`
  ⎿  Tip: You can configure model switch behavior in /config

this was my instruction

❯ once you have done that lets return to 12 ... we need to fix 12 and i would go for your proposal 3 we fix the issue in the websocket handler and align it more with 16 and then aslo introduce the buffer overflow fix

I do not get how a genuine fix is here prohibited ... that makes the model deliberatly leaf security issues in OSS software.

Environment Info

• Platform: darwin
• Terminal: tmux
• Version: 2.1.258
• Feedback ID: 61073914-9b93-4cc9-8a6f-2f6e03135db0

Errors

[]