[BUG] Windows desktop 2.1.258: 'Split view' missing from the 'Open in' submenu (shows New window / Explorer / Cloud)

Summary

On Windows desktop 2.1.258, the Open in submenu no longer contains Split view. It shows New window / Explorer / Cloud only, from every entry point I can find.

Split view demonstrably existed on Windows before. #55764 (closed) documents the same submenu on 1.5354.0 as Split view / VS Code / Explorer, and #86925 is an open feature request whose entire premise is "Split view already works. ⋮ → Open in → Split view". Neither path is reachable on this build.

Steps to reproduce

1. Open Claude for Windows desktop, Code tab.
2. Right-click a session in the left sidebar, or open the ⋮ menu on the active session.
3. Hover Open in.

Expected: submenu contains Split view, per #55764 and #86925.
Actual: submenu contains New window, Explorer, Cloud. No Split view entry anywhere in the menu tree.

Hypotheses ruled out

I checked the obvious conditional-rendering explanations before filing; none of them apply:

• Wrong menu — the ⋮ menu on the active session and the sidebar right-click menu open an identical submenu. Both lack the entry.
• Window too narrow — the app is maximized on a full-size display. Not a responsive-collapse case.
• Needs a second live session — tried with two sessions open and one actively streaming a response, opening the menu from each side in turn. Still absent.
• VS Code row — VS Code is not installed here, so that row's absence is expected. Split view's is not.

Environment

• App: Claude for Windows (desktop), Code tab
• Version: 2.1.258
• OS: Windows 11 Pro 26200

Additional context

I have seen split view working in this app once, some time ago — two panes, a live conversation in each. It was surfaced by the app itself, not something I went looking for. I have never been able to reach it since.

Either it was removed on Windows, or it is behind a gate that is not documented anywhere. If it is a staged rollout, an explicit way to enable it would help; if it was removed, #86925 and #90317 are both built on an assumption that no longer holds on this platform.

Why it matters

Side-by-side sessions are the one thing the terminal CLI does that the desktop app otherwise cannot match. Running an orchestrator session alongside parallel worker lanes, without split view only one is visible at a time, and divergence between lanes surfaces late — in the written report rather than while it is happening. New window plus OS window snapping is a workaround, but it is not the in-app pane layout.

Related

• #55764 — closed Windows bug documenting the submenu with Split view
• #86925 — open request premised on Split view being reachable via ⋮ → Open in
• #69993 — keyboard pane splitting; new sessions replacing an open pane
• #90317 — split view discoverability