`zmx attach` hangs silently when session daemon is from an older version (0.6.0 daemon + 0.7.0 client)

[silvansky]

Summary

After upgrading zmx 0.6.0 → 0.7.0 (Homebrew tap), zmx attach to any session whose host daemon is still running 0.6.0 hangs indefinitely: the client connects but renders nothing, never replays scrollback, and never returns. There is no error message. Sessions created after the upgrade (0.7.0 host) attach fine.

Environment

• macOS Darwin 25.2.0, Apple Silicon
• zmx 0.7.0 via neurosnap/tap (upgraded from 0.6.0)
• Terminal: Ghostty 1.3.2-dev

Steps to reproduce

1. Install zmx 0.6.0 and create a session: zmx attach mysession, detach, leave the host daemon running.
2. Upgrade to 0.7.0 (brew upgrade zmx).
3. Run zmx attach mysession with the new binary.

Observed

• zmx attach mysession hangs forever with a blank screen. The log shows the connection succeeding and then nothing:

  [info] (default): socket path=$TMPDIR/zmx-501/mysession
  [info] (default): ensure session session=mysession
  [info] (default): attached session=mysession
  [info] (default): client loop fd=4
  

• Other commands against the old daemon behave inconsistently:

  • zmx list — works (though one 0.6.0 session's entry is printed malformed, missing its name=/pid= fields)
  • zmx history mysession — works
  • zmx get mysession — fails fast with a clear error: error: session "mysession" does not support labels (daemon too old?)

• Clients that were already attached before the upgrade keep working.

Expected

Attach should detect the daemon/protocol version mismatch and fail fast with an actionable error (like zmx get already does), e.g. error: session "mysession" was created by an older zmx; restart it to attach. Silent hang makes it look like the session itself is wedged.

Workaround

Kill the old host process (plain kill <host pid>) and recreate the session with the new binary. zmx history still works against the old daemon, so scrollback can be salvaged first.

[neurosnap]

Hmm, that's a bummer. The IPC should be ABI compatible -- we made sure of that -- so I don't quite understand why the old sessions would hang. To be fair, I did test the new binary using my mac mini but not with v0.6.0 sessions.

[silvansky]

@neurosnap I opened a PR with a fix, now it attaches to 0.6.0 sessions on my macmini

[AnasIsmai1]

Another symptom of this same pair, in case it helps narrow the cause: send
across the version boundary doesn't hang. It returns exit 0 and delivers
nothing.

Supacode bundles 0.6.0 at
/Applications/supacode.app/Contents/Resources/zmx/zmx and creates all of its
sessions with it, so anyone with 0.7.0 from the tap on $PATH is writing to
0.6.0 daemons without realising. I lost an evening to this, convinced the
problem was vim mode in the program I was driving.

Same asymmetry you noted, where list and history keep working:

B=/Applications/supacode.app/Contents/Resources/zmx/zmx   # 0.6.0
H=$(command -v zmx)                                       # 0.7.0
T=/tmp/zmxcross; mkdir -p "$T"

# 0.6.0 creates the session, parked on something that records what it receives
"$B" run zmxcross -d bash -c "cd $T && cat > got.txt"

"$H" ls --short | grep zmxcross     # found
"$H" history zmxcross               # works

"$H" send zmxcross "HELLO-FROM-070
"
echo $?                             # 0

"$B" send zmxcross $'\004'          # EOF via the bundled binary, to flush cat
cat "$T/got.txt"                    # empty

Sending the same bytes with $B writes them as expected.

get fails fast with "daemon too old?", which is the behaviour I'd want here
too. send reporting success is worse than hanging, because a hang is at least
visible. My code checked the exit code, saw 0, and reported the message as
delivered for weeks.

I see #212 was closed without merging. If the fix is being reworked, this might
be worth folding into the same change, since it looks like the same negotiation
rather than something specific to attach.

zmx 0.6.0 (bundled by Supacode 0.10.8) and 0.7.0 (Homebrew) on macOS 26.6.1,
MacBookPro18,1, M1 Pro. I haven't tested other version pairs, so I can't say
whether this is specific to 0.6 against 0.7.

[neurosnap]

Hmm I didn't think about embedded versions. I might merge the associated pr