0.42.0: V2 commands resolve to the wrong window once a second window exists, and unknown flags silently execute with defaults #143

wmux version: 0.42.0
OS: Windows 11 Pro 10.0.26200
Shell in pane: powershell.exe

Two CLI correctness problems found while verifying the #141 fix (which is fixed — details in a comment there). Both matter mainly to scripts and agents driving wmux from inside a pane.

1. WMUX_SURFACE_ID resolves to the wrong window once a second window exists

The 0.42.0 release note says "V2 commands now use caller's WMUX_SURFACE_ID to identify owning window". With a single window this appears to work. As soon as a second window exists, passing WMUX_SURFACE_ID makes commands resolve to a constant, wrong window — and the caller's own surface is not in the result.

Setup

• Caller shell lives in surf-360768cf-…, in pane pane-c36f0826-…, in workspace "Workspace 3", in window win-fda7feb5-….
• A second window win-2806cd6c-… was opened with wmux new-window.
• There is also a workspace "Session 1" containing three terminal panes (pane-f45f55c3, pane-b11e7cf2, pane-89504319).

Observed

Grepping the WMUX_SURFACE_ID result for the caller's own surface id returns 0 matches. The result is byte-stable across focus changes: it always resolves to "Session 1", a workspace the caller is not in.

So the env var makes resolution worse: removing it at least follows the focused window.

tree and list-surfaces now agree with each other (that part of #141 is fixed) — they are simply wrong together.

Reproduce

# from a shell inside a wmux pane, with at least one other workspace present
echo "$WMUX_SURFACE_ID"          # note this id
wmux tree                        # ✓ shows your pane
wmux new-window
wmux tree                        # ✗ different window; your surface id is absent
env -u WMUX_SURFACE_ID wmux tree # ✓ shows your pane again

Why it matters

A script running inside a pane always has WMUX_SURFACE_ID set — there is no way to opt out short of scrubbing the environment. So any agent or script that inspects or mutates surface state starts operating on someone else's window the moment the user opens a second one, and it looks successful. Scrubbing the variable is not a fix either, since the result then depends on which window happens to be focused.

What I would expect: caller should resolve to the window/workspace that actually contains that surface id, and fall back to the focused window only when the id is unknown.

2. There is no --help, and unknown flags are silently ignored — the command runs anyway

wmux new-surface --help    # creates a terminal surface
wmux split --help          # splits the pane

getFlag() in resources/cli/wmux.js picks out the flags it knows and ignores everything else, so a typo or an exploratory flag becomes "run with defaults". Only bare wmux prints usage.

This is a small thing for a human, but for an agent it means probing the CLI mutates the user's layout, and the JSON response looks like success. I hit it while investigating issue 1 and accidentally created a surface and split a pane.

Suggestion: reject unknown flags with an error and print that subcommand's usage, and/or support --help / -h per subcommand.