Issues in grouped sessions

[BabakAmini]

Oryxis version

0.11.0

Operating system

Windows

OS version / distribution

Windows 11 25H2

How did you install Oryxis?

Other

What happened?

When working with grouped sessions, I have encountered two issues:

1. In some cases, the title of the group doesn't change when you close one or more panes in a group.
2. When splitting a tab, selecting Local Shell adds Command Prompt by default instead of prompting for available local shells.

P.S. I'm using the portable version of Oryxis.

Steps to reproduce

To reproduce the first issue, follow these steps:

1. Open a local shell session.
2. Split the tab and select a different type of host.
3. Select the local shell pane and close it.
4. The only open tab will now be the one you opened most recently, but the tab's name will be that of the one you opened first.

Expected behavior

No response

Logs / environment info

[wilsonglasser]

Both are fixed on the nightly. Your steps 1 to 4 were exact, which made the first one quick to pin down.

1. The tab kept the closed pane's name. While a tab is split it shows the focused pane's label, but once it is back to a single pane it falls back to the TAB's own label, and that field was set when the tab was created and never updated again. So closing the first pane left the tab wearing the name of the pane that had just gone away, while showing the survivor's terminal.

It was not only cosmetic: the same field is what the host-accent colour and the detected-OS badge look up, so those were mismatched too. Collapsing a split now re-anchors the tab on the pane that is left. A tab you renamed by hand keeps your name, and a tab that is still split is untouched.

2. Local Shell in a split opened Command Prompt directly. This was a routing bug rather than a Windows one. Picking "Local Shell" for a NEW TAB runs the decision that honours your curated shell list and the "always open X" default, and raises the shell picker when there is a real choice. Picking it for a SPLIT PANE called straight into the split path, which hard-coded the OS default shell. On Windows that is cmd, which is exactly what you saw.

Both destinations now go through the same decision, and the split target survives the picker instead of being consumed before it opens (abandoning the picker abandons the target, as it already did for the new-tab picker).

Two smaller things came along with it: a split pane now records which shell it actually opened, so saving the tab as a session group restores that shell rather than the OS default, and it inherits the working directory of the pane you split when that pane is itself a local shell.

Item 2 is the one I could not exercise here (this machine only exposes one shell, so the picker never appears), so a confirmation from you on a box with several shells configured would be welcome.

[BabakAmini]

As for split panes, I believe there are other related issues. The items and data in the sidebar panel do not automatically update when a new pane is added unless you click inside the pane. The same thing happens when you close a pane: the sidebar doesn't update unless you click inside one of the remaining panes.

a confirmation from you on a box with several shells configured would be welcome.

As I can't build the app on my machine, I will test it again when you released the new version.

[wilsonglasser]

@BabakAmini you can change to nightly builds in settings or install manually from the releases. Or you can also wait, usually on weekends.