run_command: tmux completion wrapper breaks over SSH panes (error connecting to socket) #132

Activity

1. isamu commented on Sep 18, 2026

   

   isamu

   on Sep 18, 2026

   More actions

   The same failure reproduces on one host with no SSH. What the wrapper needs is for the pane's shell to resolve the same socket the server does, and a remote filesystem is only one way to lose that. A different $TMUX_TMPDIR in the pane's shell does it too.

   Two arms, identical except for that variable:

   # Both arms of the wrapper, on one host, no SSH.
   SERVER_TMPDIR=$(mktemp -d /tmp/srv.XXXX); PANE_TMPDIR=$(mktemp -d /tmp/pane.XXXX)
   srv() { TMUX_TMPDIR=$SERVER_TMPDIR tmux -L probe "$@"; }
   
   srv new-session -d -s s -x 200 -y 50
   sleep 1
   
   # Arm 1: the pane's shell shares the server's TMUX_TMPDIR.
   srv send-keys -t %0 "tmux -L probe set-option -p -t %0 @arm_control ok" Enter
   
   # Arm 2: only the pane's shell has a different TMUX_TMPDIR.
   srv send-keys -t %0 \
     "TMUX_TMPDIR=$PANE_TMPDIR tmux -L probe set-option -p -t %0 @arm_test ng" Enter
   srv send-keys -t %0 \
     "TMUX_TMPDIR=$PANE_TMPDIR tmux -L probe wait-for -S ch_test" Enter
   sleep 2
   
   echo "--- what the pane printed ---"
   srv capture-pane -p -t %0 | grep 'error connecting'
   echo "--- options that got set ---"
   srv show-options -p -t %0 | grep @arm
   echo "--- does wait-for ever signal? ---"
   TMUX_TMPDIR=$SERVER_TMPDIR timeout 3 tmux -L probe wait-for ch_test
   echo "wait-for exit: $?   (124 = timed out)"
   
   srv kill-server; rm -rf "$SERVER_TMPDIR" "$PANE_TMPDIR"

   --- what the pane printed ---
   error connecting to /private/tmp/pane.vZw4/tmux-501/probe (No such file or directory)
   error connecting to /private/tmp/pane.vZw4/tmux-501/probe (No such file or directory)
   --- options that got set ---
   @arm_control ok
   --- does wait-for ever signal? ---
   wait-for exit: 124   (124 = timed out)
   

   Arm 1 sets its option. Arm 2 prints error connecting, never sets @arm_test, and its wait-for -S never reaches the server, so the matching wait-for on the server side runs to the timeout.

   _tmux_argv carries -L/-S into the pane, which pins which socket is asked for. Resolving that name is still done by the pane's shell, against its own $TMUX_TMPDIR, its own euid, and its own filesystem. Any of the three can differ from the server's:

   • an SSH session: different filesystem (this report)
   • a different $TMUX_TMPDIR: above
   • a shell under another uid, since the path carries tmux-<euid>
   • a container shell (docker exec): same as SSH

   The outcome is the same in each. The authored command runs, its output is visible, and only the completion signal is lost — so run_command waits out the ceiling before reporting anything, and the two error connecting lines are the only clue, sitting in the pane's scrollback rather than in the tool's result.

   One note on detection: #{pane_current_command} catches ssh and docker, but not the $TMUX_TMPDIR case, where the pane's shell is an ordinary local shell.

   ❤️React with ❤️1Reacted by Dat Nguyen Duy