›_ Claude Code Issues
Claude Code Issues / #93471

[BUG] Claude Desktop Linux: Alt/AltGr key auto-shows hidden menu bar, conflicts with IME toggle keybinding — also menu bar/titlebar being hidden by default hurts usability

Status Open
Maintainer reply None cached
Activity 5 comments · opened Sep 10, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Note: This bug is in the Claude Desktop application UI on Linux
(not Claude Code CLI). Some form fields above are not applicable
and marked N/A accordingly.

On Claude Desktop for Linux, pressing the Alt key alone (or a key bound to
"AltGr"/left-Alt) toggles visibility of the app's hidden native menu bar
(File / Edit / View / Go / Help). This appears to be Electron's default
setAutoHideMenuBar behavior.

This directly conflicts with common IME setups on Linux, where a bare Alt
key (or a key labeled AltGr) is commonly bound to toggling input methods
(e.g. English / Japanese input via fcitx5). Every time the user switches
input language, the menu bar pops up and steals keyboard focus, requiring
an extra Escape press to dismiss before typing can continue.

Separately, but related: the menu bar (and a visible titlebar) is no
longer shown persistently by default. Previously the menu bar/titlebar
was always visible, which made the app's window easy to identify,
navigate, and use normally (drag to move, see window title, access menu
items without a modifier key). Now that it's hidden by default and only
reachable via the Alt-key toggle described above, basic usability has
regressed — users can no longer see or access menu items without
triggering the same Alt-key conflict, and the window feels harder to
recognize/manage on screen.

There is currently no setting in Settings > General (or elsewhere in the
UI) to disable this auto-hide/auto-show menu bar behavior, to keep the
menu bar/titlebar permanently visible, or to switch to a different
titlebar/menu style. This makes the app effectively unusable for anyone
using Alt-based IME toggle shortcuts, and degrades basic window usability
for everyone else.

What Should Happen?

  • The menu bar / titlebar should be able to remain permanently visible

(not hidden-by-default, Alt-triggered-only) via a user setting.

  • Alt-key-based auto-hide/auto-show menu bar behavior should be

configurable (or disabled by default) in Claude Desktop for Linux.

  • A setting under Settings > General to control menu bar visibility mode

and/or titlebar style would resolve both issues above.

Error Messages/Logs

Steps to Reproduce

  1. On a Linux desktop with fcitx5 (or similar IME) installed, bind the

input-method toggle shortcut to a bare Alt key (commonly referred to
as "AltGr" in some keyboard layouts).

  1. Launch Claude Desktop and focus the chat window.
  2. Observe that no menu bar or titlebar is visible by default.
  3. Press the Alt/AltGr key to toggle input method as usual.
  4. Observe: instead of switching input method cleanly, the native menu

bar (File/Edit/View/Go/Help) pops open in the top-left corner and
grabs keyboard focus.

  1. Escape must be pressed to dismiss the menu bar before typing can

resume.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown – regressed after a recent update; exact prior version not recorded

Claude Code Version

N/A – this is a Claude Desktop app bug, not Claude Code CLI

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

This appears to be Electron's built-in setAutoHideMenuBar /
Alt-keydown-focuses-menu behavior, which is known to cause similar
conflicts with other Alt-based system shortcuts (see related discussion
in aaddrick/claude-desktop-debian#630, filed against the earlier
community build before the official Linux beta shipped). Requesting that
menu bar/titlebar visibility be exposed as a user-configurable setting,
defaulting to always-visible, in the official Linux build.

View original on GitHub ↗

4 Comments

golgo-11 · 1 month ago

Re: the automated invalid label — flagging for human review.

This report is about the Claude Desktop application UI on Linux
(the GUI app, version 1.49585.0), not the Claude Code CLI. Several of
the form fields above (Claude Code Version, Terminal/Shell) were marked
N/A for exactly this reason, since this issue tracker's template is
built around Claude Code CLI reports.

To summarize the actual bug for clarity:

  • Claude Desktop for Linux auto-hides its native menu bar/titlebar by

default (Electron's setAutoHideMenuBar behavior).

  • Pressing Alt alone toggles the menu bar into view and steals keyboard

focus.

  • This conflicts with common Linux IME setups where a bare Alt key is

bound to input-method switching (e.g. fcitx5, English/Japanese
toggle).

  • There is no setting in Settings > General to disable this behavior

or keep the menu bar/titlebar permanently visible.

This is a genuine regression in the Claude Desktop Linux build, not a
Claude Code CLI issue. Could a maintainer take a look and re-triage?
Happy to provide logs, claude-desktop --doctor output, or any other
diagnostics if helpful.

jordancarmel · 22 days ago

as a dual language user this drives me crazy :)

IlyaMikhaylovTim · 21 days ago

Same problem here, with two things to add: my setup has no IME at all — just a plain XKB layout switch — and this is a regression, with a known-good version and a clean bisect to the release that broke it.

Also seconding the request to re-triage this off the automated invalid label: this is the desktop GUI app, not the Claude Code CLI.

Environment

  • Ubuntu 24.04.5 LTS, GNOME Shell 46.0, X11
  • Claude Desktop, official .deb from downloads.claude.ai
  • Layout switching via the XKB option grp:alt_shift_toggle, layouts us and ru. No fcitx5, no IME toggle; ibus runs only as part of the stock Ubuntu setup.

What happens

Alt+Shift switches the keyboard layout at the XKB level, and Claude Desktop additionally treats the Alt press as a bare Alt: the auto-hidden menu bar (File / Edit / View / Go / Help) pops up and takes keyboard focus. Everything typed after the switch lands in the menu instead of the chat input, so every single language switch costs an extra Esc. Alt+Shift is one of the most common layout toggles for anyone who came to Linux from Windows, so this is not a niche binding.

Note there is no input method involved here at all, just two XKB layouts. A fix scoped specifically to IME toggles would miss this case.

This is a regression, and it bisects to a single release

Version history on this machine, taken from /var/log/dpkg.log, so the dates are exact:

  • 2026-09-07 upgraded to 1.46388.2 — Alt+Shift works correctly
  • 2026-09-15 11:22 upgraded to 1.52386.6 — Alt+Shift broken
  • 2026-09-15 15:45 rolled back to 1.46388.2 the same day
  • 2026-09-23 13:43 upgraded to 2.2553.13, the current release — still broken
  • 2026-09-23 13:46 rolled back to 1.46388.2 again, three minutes later

I am on 1.46388.2 today, and holding it with apt-mark hold, because it is the last version I can type in two languages in.

The report that opened this issue was filed against 1.49585.0, which is already broken — and in the apt repository 1.49585.0 is the immediate successor of 1.46388.2. So the regression is not a window, it is one release step: 1.46388.2 → 1.49585.0.

What changed in that step

Not the application code. All three builds use the same menu-bar setup — autoHideMenuBar: true in the window options, plus a global handler:

app.on("browser-window-created", (e, w) => { w.setAutoHideMenuBar(true); w.setMenuBarVisibility(false) })

What changed is the runtime underneath. Taken from the shipped claude-desktop binary of each .deb:

| Build | Electron | Chromium | Alt+Shift |
|---|---|---|---|
| 1.46388.2 | 42.10.0 | 148.0.7778.280 | works |
| 1.49585.0 | 44.2.0 | 152.0.7977.76 | broken |
| 1.52386.6 | 44.2.0 | 152.0.7977.76 | broken |
| 2.2553.13 | 44.2.0 | 152.0.7977.76 | broken |

The break lines up exactly with the Electron 42 → 44 bump, and every broken build since has shipped the same Electron 44.2.0. Under Electron 42 this same autoHideMenuBar setup simply did not react to Alt+Shift; under Electron 44 it does, because Alt released as part of a modifier combination is now treated as a bare Alt.

That also means users cannot defend themselves: the auto-hide behaviour is unconditional, there is no setting in the UI and no environment variable in the bundle that turns it off. The only escape is to give up Alt+Shift and rebind layout switching system-wide — a lot to ask of muscle memory built over years.

A known-good fix already exists

The community Debian repack hit exactly this bug in aaddrick/claude-desktop-debian#630 and fixed it in aaddrick/claude-desktop-debian#642 (merged 2026-05-24). The approach: suppress the Alt keydown via before-input-event, track whether any other key — modifiers included — was pressed while Alt was held, and toggle the menu bar on Alt keyup only when Alt was genuinely pressed alone. The tracker is reset on window blur so Alt+Tab does not leave stale state behind.

Waiting for Electron is not an option: the 2021 fix electron/electron#29328 ("Fix pressing Alt+Shift and Alt+Ctrl toggling menu bar on KDE") does not cover this case, and the general request for a way to switch the Alt-focus behaviour off, electron/electron#34211, has been open since May 2022 with no API to show for it. VS Code ended up handling it in the application layer for the same reason.

What would fix it, in order of preference

  1. Do not toggle the menu bar when Alt is released as part of a modifier combination such as Alt+Shift or Alt+Ctrl — the #642 approach above.
  2. A setting to keep the menu bar permanently visible, or to disable the Alt auto-show entirely.

Happy to test a build on this setup.

golgo-11 · 21 days ago

Thank you @IlyaMikhaylovTim for the incredibly thorough follow-up —
the version bisect, the Electron 42→44 root cause, and the pointer to
the existing fix are extremely helpful. And thank you @jordancarmel
too for confirming this is hitting other dual-language users as well —
sorry it's driving you crazy too, but glad to know it's not just an
edge case on my end.

I should mention I'm relatively new to Linux myself, so I can't verify
the Electron internals firsthand, but the technical detail here matches
exactly what I'm seeing on my end (Debian 12 / KDE Plasma, fcitx5 Alt
toggle) — same symptom, same version range affected.

Given that a working fix already exists upstream
(aaddrick/claude-desktop-debian#642 — suppressing the Alt keydown via
before-input-event and only toggling the menu bar when Alt is released
alone, not as part of a modifier combo), would it be possible for a
maintainer to look into porting that approach into the official build?

This seems to affect anyone using Alt-based shortcuts for anything
other than opening the menu (IME toggles, XKB layout switching, etc.),
and with three of us now reporting the same regression independently,
I'd guess the impact is broader than this thread suggests. Happy to
test a build if one becomes available.

Showing cached comments. Read the full discussion on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Browse all Claude Code issue topics →