[BUG] Windows desktop: clicking 'Split view' in 'Open in' submenu opens 'VS Code' instead (off-by-one on mouse click)

Resolved 💬 2 comments Opened May 3, 2026 by romankanevsky Closed Jun 11, 2026

Summary

In the session right-click context menu, the Open in submenu shows three items:

  1. Split view
  2. VS Code
  3. Explorer

Clicking the first item (1 Split view) with the mouse triggers the second item (2 VS Code) instead. Pressing the keyboard digit 1 while the submenu is open correctly invokes Split view. The mismatch is reproducible and mouse-only.

Steps to reproduce

  1. Open the Claude for Windows desktop app.
  2. In the left sidebar, right-click on a recent session.
  3. Hover Open in to expand the submenu (Split view / VS Code / Explorer).
  4. Click 1 Split view with the mouse.

Expected: the session opens in a split view alongside the current one.
Actual: VS Code launches and opens the session there (item 2 fires).

If instead of clicking I press 1 on the keyboard while the submenu is open, Split view triggers correctly. So the click handler appears off by one, while the keyboard handler is correct.

Items 2 and 3 are not yet confirmed to be off by one as well, will update if I see the same shift there.

Environment

  • App: Claude for Windows (desktop)
  • Version: 1.5354.0 (9a9e3d)
  • OS: Windows 11 Enterprise 26200
  • Repro: 100% on this machine

Hypothesis

Looks like the first row in the submenu is being rendered as a non-interactive header or has a misaligned hit region, and the mouse click falls through to the next row. Keyboard input dispatches by index and so resolves the right action.

Notes

I checked existing issues for "Open in" / submenu / Split view click bugs and did not find a duplicate. Closest is #53427 which is a feature request to make the Open in submenu configurable, not a click handler bug.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗