Add tests for user-reported rm security bypass variants

[rtfeldman]

Builds on top of #48620 to add explicit test coverage for the exact bypass scenarios reported by users:

• rm -rf /etc/../ — path traversal via single parent dir that normalizes to /
• rm -rf --no-preserve-root / — long flag without =value that could bypass the old regex
• rm --no-preserve-root -rf / — long flag positioned before short flags
• rm / -rf --no-preserve-root — trailing long flag without =value after the path operand
• sudo rm -rf /, sudo rm -rf /*, sudo rm -rf --no-preserve-root / — sudo-prefixed variants

All of these cases are already correctly blocked by the hardened regex patterns and path normalization logic added in #48620. These tests confirm that the reported bypasses are addressed and guard against regressions.

Release Notes:

• N/A

[KieranP]

@rtfeldman This doesn't appear to account for line separators (\) either, or subshells, among other things. rm -rf \/, \rm \-rf \/, /bin/bash -c 'rm -rf /', echo $(rm -rf /), etc. I appreciate the effort you're making, but trying to harden security in this way will never fully work, there will always be 100s of ways to bypass a regex.

The best approach would be to ensure the AI cannot make shell commands at all, and instead Zed provides various tools the AI can use that constrain any actions to the open workspace only. But that would require a lot of work to make every CLI tool (cat, ls, rm, mkdir, git, etc) a supported tool, but would give the best security and flexibility long term.

The other approach would be to use chroot before any AI executed commands to constrain all AI commands to the current working directory. https://wiki.archlinux.org/title/Chroot - The downside is that this often requires sudo to execute.

[rtfeldman]

I appreciate the effort you're making, but trying to harden security in this way will never fully work, there will always be 100s of ways to bypass a regex.

@KieranP Totally agree - the goal here is really just to 80-20 address some things that are definitely banworthy.

[davc0n]

From #48209

Ideally, the agent would only allow changes within the working directory, I can't think of any good reason why running agents in my project should modify files/paths outside...

I agree with @KieranP's point here.

Restricting the agent to only allow changes within the working directory makes sense, as it minimizes the risk of unintended modifications outside the project scope.

If this could be implemented, it would be a great step forward imho.