split-window target resolution is unstable in live sessions (wrong cwd and wrong attached client)

[WangErgouaaaa]

Summary

I hit two related split-pane problems on Linux with rmux 0.5.0 in live use:

1. split-window -c "#{pane_current_path}" can create the new pane in $HOME instead of the current pane's real working directory.
3. When multiple attached clients share the same rmux daemon/socket, prefix + % can create the new pane in a different attached session/client than the one where the key was pressed.

These look like target resolution / context resolution bugs in live sessions.

Environment

• rmux: 0.5.0
• OS: Linux x86_64
• shell: bash
• terminal: Cursor terminal / interactive shell
• multiple attached rmux clients/sessions on the same default socket

Problem 1: wrong cwd with inline #{pane_current_path}

Repro

sid="rmux-cwd-repro-$$"
rmux new-session -d -s "$sid" -c /data/sync/obsidian/科研写作 'bash'
pane=$(rmux list-panes -t "$sid" -F '#{pane_id}' | head -n1)
rmux split-window -h -t "$pane" -c '#{pane_current_path}'
rmux list-panes -t "$sid" -F '#{pane_id} #{pane_current_path} #{pane_current_command}'

Actual

The original pane stays in the expected directory, but the new pane can start in $HOME:

%11 /data/sync/obsidian/科研写作 bash
%12 /home/ergou-aa bash

Expected

Both panes should use the current pane's real working directory.

Problem 2: split can land in the wrong attached session/client

Repro shape

• open two top-level rmux clients/sessions attached to the same daemon/socket
• press prefix + % in one visible client
• sometimes the new pane appears in the other attached session/client instead of the one where the key was pressed

Actual

The split succeeds, but it can affect the wrong attached session/client.

Expected

The split should always target the client/session where the keybinding was triggered.

Local workarounds

Workaround for problem 1

Instead of relying on inline -c "#{pane_current_path}", I had to:

1. read the current pane's cwd first
3. pass the cwd as a literal path to rmux split-window -c <literal-path>

That path works reliably.

Workaround for problem 2

I had to avoid sharing one default rmux socket across multiple top-level interactive clients. Using one rmux socket per outer terminal/client avoided the cross-session split behavior.

Why I think this is upstream-facing

The first issue reproduces in a minimal scratch session without my full wrapper stack.

The second issue is easier to trigger in my real interactive setup, but it still looks like the split path is resolving the wrong attached-client context when multiple clients share one daemon.

If useful, I can also provide:

• exact keybindings used
• a smaller multi-client repro script
• logs / additional diagnostics