agent: Stop over-escaping dashes in tool_permissions regex patterns

[mvanhorn]

Fixes #51537

regex::escape() escapes dashes, but dashes are only special inside [] character classes in regex. This means tool_permissions patterns end up with unnecessary backslashes:

Before: ^https?://typescript\-eslint\.io, ^git\-lfs\s+pull(\s|$)
After: ^https?://typescript-eslint\.io, ^git-lfs\s+pull(\s|$)

The fix adds a small escape_for_pattern() helper that calls regex::escape() then strips the unnecessary dash escaping via .replace("\\-", "-"). This is applied to all five call sites in pattern_extraction.rs.

Tests updated to expect unescaped dashes, plus a new test_dashes_are_not_escaped test covering terminal commands, URLs, and paths with dashes.

This PR was developed with AI assistance.

Release Notes:

• Fixed unnecessary escaping of dashes in agent tool permission patterns (e.g. typescript\-eslint is now typescript-eslint)

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @mvanhorn on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[mvanhorn]

@cla-bot check

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @mvanhorn on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[mvanhorn]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[ConradIrwin]

Thanks for adding this, and sorry for the slow reply. Are you able to rebase this?

[mvanhorn]

Rebased on main in 1623df7c. Upstream had refactored extract_command_prefix to return normalized_tokens: Vec<String> (replacing the old command + subcommand split), so I kept the new match-on-tokens structure and swapped the three regex::escape call sites for escape_for_pattern, preserving the PR's original intent (leave dashes unescaped outside [] character classes).

Verified: cargo check -p agent clean. Full tests need Metal toolchain which I don't have locally, so deferring to CI.

[ConradIrwin]

Thank you!

Also may be worth sending a PR upstream (though they may want this behavior intentionally so you can escape a set of characters, it seems a bit odd)

[mvanhorn]

Thanks @ConradIrwin! Worth a look upstream - my read is regex is being conservative since - is meta inside character classes, so regex::escape plays it safe by escaping it everywhere. Will think about whether a PR there is worth the noise.

Separately, the failing CI runs all blow up on role "root" does not exist in the postgres setup, which doesn't look related to this patch. Happy to rebase again or push an empty commit if a fresh run would help.

[ConradIrwin]

I see tests relating to this failing on the macOS CI:

You should be able to run it locally with cargo test -p agent test_extract_terminal_pattern

[mvanhorn]

Thanks @ConradIrwin. That test expectation hadn't been updated when 1623df7c introduced escape_for_pattern. Pushed 34efb94 with the fix on test_extract_terminal_pattern: the PAGER='less -R' git log fixture now expects the unescaped dash inside the env var value.

Couldn't reproduce locally (this Mac is missing the Metal toolchain so the agent crate won't build), so this is verified by reading the diff. The single-quoted env-var path runs through the same escape_for_pattern as everything else, which strips \- back to -. CI should be green on the next run.

[ConradIrwin]

Thanks!