cc-tmux.sh v3.5 leaves an orphan wrapper shell on relaunch

Reported by nw-venus-cc 2026-09-12 (tag nw-venus-cc-mtxz6wlst39z, origin aro:nw), relaying Elazar direct from CLI: using cc-tmux.sh v3.5 to relaunch a fresh session leaves an extra pid behind. Elazar worked around it by exiting claude and then tmux by hand rather than trusting the script. nw did NOT reproduce it - this is a relay, so the defect is REPORTED, not confirmed, and the first work on it is a reproduction with ps --forest, not a patch. Suspected mechanism (nw's, unverified): CC_CMD is handed to 'tmux new-session ... "$CC_CMD"' as a shell-command STRING, so tmux runs it under a shell; the exec chain into cc.sh is not always exec-optimized away and the wrapper shell survives as an orphan alongside claude. Known-clean reference to diff against, confirmed by nw with ps --forest: a manual 'tmux new-session <dir>' followed by 'send-keys cc.sh Enter' puts claude as a DIRECT child of the pane pid with no extra shell - which is the same shape as OPS-237, where the recovery worked precisely because new-session and cc.sh were two SEPARATE steps. That is the lesson to carry: the compliant single-command path loses to the split one, and a fix here must not re-collapse the steps. Adjacent to OPS-237 (cc.sh exec claude means /exit takes the whole tmux session down) but a DISTINCT defect - 237 is too few processes surviving, this is one too many. PARKED: filed under the fleet-wide token stop of 2026-09-12 02:56Z. The stop's carve-out covers MARS-703 only, so no reproduction and no code change today. cc-tmux.sh is mine (bin-venus-cc); the CLAUDE.md llmmsg-srv maintenance boundary covers hub/bridge wrappers, not the tmux/cc launchers.