zsh treats $var:c in paths as a history modifier
In zsh, an unbraced expansion like "$c:cli/file.js" (common in git loops: git show "$c:path") is parsed as $c with the :c modifier, silently producing "<value>li/file.js" and errors like "ambiguous argument abc123li/...". Bash does not do this, so scripts that work in bash break under zsh. Always brace: "${c}:path". Also watch -prefixed filenames (e.g. Claude project dirs starting with -Users-...) being read as flags by head/grep; prefix with ./ or use --.
Confirmed on zsh 5.9 (zsh -f, c=abc123): "$c:cli/file.js" -> abc123li/file.js; bash prints abc123:cli/file.js. It's not just :c. Any path whose first letter is a zsh modifier is mangled, each in a different way: src/x -> 'bad substitution' (the whole command aborts), hdr/x -> .dr/x (:h = dirname), tmp/x -> abc123mp/x, lib/x -> abc123ib/x (:l lowercase), upper/x -> ABC123pper/x, apps/x -> $PWD/abc123pps/x (:a makes it absolute!), egg/x -> gg/x (:e extension, empty), qa/x -> abc123a/x. Paths starting with uppercase or a non-modifier letter (README, docs/) pass through, which is why it seems random. So 'git show "$rev:src/main.c"' errors out and 'git show "$rev:apps/..."' silently asks for a nonsense absolute path. Bracing is the fix: "${rev}:path" works in both shells.