Summary

Flags backed by pflag StringSlice split each value on commas, so a value that legitimately contains a comma is broken into multiple entries. This affects all StringSlice-backed flags (for example --exclude-extensions, --severity, --tags, --review-meta) and the custom enum-slice flags. It is currently benign because none of the values these flags take contain commas, but it is a latent limitation worth tracking. Related to #1026.

Detail

The split happens at two independent layers:

1. pflag, at parse time. StringSlice CSV-splits each occurrence: --tags "a,b" becomes ["a", "b"], and there is no way to pass a single value that contains a comma.
2. viper, on read. viper's find() also CSV-splits stringSlice (and stringArray) values, so even a value that survived parsing would be re-split when read through viper.

The obvious fix (switch to pflag StringArray, which does not split on commas) is blocked by layer 2: viper treats stringArray the same as stringSlice (both go through readAsCSV, viper.go around line 1184), so reading a StringArray flag via viper.GetStringSlice re-splits it.

Possible directions

• For any flag that must accept comma-bearing values: register it as StringArray and read it directly from pflag (cmd.Flags().GetStringArray(name)), bypassing viper for that flag. The trade-off is losing viper config-file/env merging for it, which is acceptable for flags that are only ever passed on the command line.
• Alternatively, define an escaping scheme or a non-comma delimiter for the affected flags.
• Upstream: viper applying readAsCSV to stringArray defeats the purpose of stringArray; worth a viper report if we end up depending on it.

Impact

Latent only. None of the current flag values contain commas, so there is no live bug. Tracking so that a future comma-bearing value (or a fix to viper's stringArray handling) is handled consistently across all slice flags rather than per-flag.