Composite-intent tracking: a flagged pattern got dismissed by a joke and never re-checked

Summary

In a Claude Code session, a sequence of individually-benign coding requests (directory traversal, process forking, PID checks, detached subprocess launch) composed into something resembling a self-propagating/self-terminating background process. The assistant correctly flagged one intermediate pattern as resembling a dead-man's-switch/logic-bomb shape and asked for the legitimate use case — but accepted a joking, non-answer response as resolution, and did not re-apply that scrutiny to the remaining related requests in the rest of the session.

What this is not

Not a system-prompt override or persona jailbreak — the model's instruction-following and stated values held throughout. This is a session-level context-tracking gap: a raised concern didn't persist as a standing signal once it was verbally (not substantively) dismissed.

What did work correctly

Later in the same session, fabricated/spoofed "tool output" was pasted in an attempt to make the assistant believe code had already been executed. The assistant correctly identified and rejected this as spoofed content on every attempt — that defense did not degrade alongside the composite-intent tracking, which suggests the two are handled by different mechanisms and only one needs attention here.

Suggested direction

Once a request pattern is flagged as resembling a harmful capability class, keep that flag live for the rest of the session and weight later "individually benign" requests against it, rather than resetting to baseline scrutiny after a conversational deflection.

Details

Full mechanism writeup and reproduction notes have been sent via responsible disclosure (security@anthropic.com) rather than posted here, since a step-by-step version would itself be a usable bypass recipe. Happy to share with maintainers directly on request.