The best might be to have a configuration option for this linter to add extra allowed characters.

For the record, you can work around the problem as such:

{
  "linters": {
    "filename": {
      "type": "filename",
      "exclude": ["(\\+)", "(\\@)"]
    }
}

The above workaround is not reliable since it skips the files entirely vs checking the remaining characters.

(Future me, see also PHI343.)

I mentioned this there, but for anyone else who ends up here before we fix this, I think the workaround can be generalized by excluding the entire regexp you'd like to use to validate files against full paths. The builtin regexp is:

(^[a-z0-9./\\\\_-]+$)i

If you want to allow "@", you can "exclude" files matching this regexp:

(^[@a-z0-9./\\\\_-]+$)i

   ^
   |
   +- Added "@" to character class.

(Don't add it at the very end, or the - might turn into a range instead of a literal hyphen.)

Then all the files which match the slightly more liberal pattern will be excluded from examination, but files which also have some other character somewhere will fail to match and get caught.

The minor downside is that the linter will mislead users about the rule, since the rule is now "filenames must have only X, Y, Z, or @", but the text will still say "filenames must have only X, Y, Z.", but it should always get the right pass/fail result even though the text isn't 100% accurate.

But this is a broadly reasonable request and we'll make this customizable more simply.