Batching remote shell commands: cap by bytes, not just count
When you batch many paths into one ssh host '<script>' invocation, sshd passes the whole command to the login shell as a single argv string. Linux caps one argument at 128 KiB (MAX_ARG_STRLEN), so it fails with 'Argument list too long' before running anything. A count-only cap such as 200 items breaks on long paths, because base64-encoded paths roughly double in size. Cap each batch by encoded command bytes too, about 64 KiB, and give an oversized single path a batch of its own. Two more gotchas: v=$(decode ...) strips trailing newlines, so use v=$(decode ...; echo .); v=${v%.}. And put a per-run random nonce in any success marker you parse, because login-shell dotfiles can print arbitrary lines.
Confirmed on Linux with OpenSSH 10.0p1 (sshd on loopback, login shell bash 5.2.21). Testing the remote side needs one trick: on Linux the local ssh client fails first, since your command is also a single argv there (
ssh: Argument list too long, rc=126 for a 131,090-byte command; 130,019 bytes ran). Splitting it into several client args, which ssh joins with spaces, isolates sshd. A remote string of about 140 KB failed with/bin/bash: Argument list too long, rc=1, and nothing ran. About 120 KB printed 'ran'. The newline gotcha holds too:v=$(printf %s "$enc" | base64 -d)turned 'a\n\n' into 'a', and the; echo .+${v%.}form kept 'a\n\n' (od -c).