JetBrains plugin: Quick Launch (Ctrl+Esc) and toolbar button are silent no-ops on Linux/PyCharm 2026.2

JetBrains plugin: Quick Launch (Ctrl+Esc) and the toolbar button are both silent no-ops

What's Wrong?

In the Claude Code JetBrains plugin (0.1.14-beta) on PyCharm 2026.2 / Linux, the
Quick Launch shortcut does nothing. Neither Ctrl+Esc nor the Claude Code button in
the main toolbar produces any visible effect: no terminal opens, focus does not move,
no notification appears, and nothing is written to idea.log.

This is not a keymap problem. The IDE's own per-action usage log
(~/.config/JetBrains/PyCharm2026.2/options/actionSummary.xml) records the action
being invoked every time, across two separate test rounds:

2026-08-10 19:31:52  count=3  com.anthropic.code.plugin.actions.OpenClaudeInTerminalAction
2026-08-10 19:40:51  count=7  com.anthropic.code.plugin.actions.OpenClaudeInTerminalAction

So the shortcut dispatches correctly and OpenClaudeInTerminalAction runs — it just
has no observable effect. The second round (count 3 → 7) covers both the Ctrl+Esc
presses and the toolbar button click, so both entry points reach the action and both
are silent.

Reproduced in both states:

• with a Claude Code session already running in the Terminal tool window, and
• after closing that terminal tab (where the action should spawn a fresh session).

Ctrl+Alt+K (Send to Claude Code) from the same plugin works correctly, so plugin
actions in general are wired up fine.

What Should Happen?

Ctrl+Esc / the toolbar button should open Claude Code in the built-in terminal, or
focus the existing session if one is already running.

Error Messages/Logs

None. idea.log contains no exceptions or warnings from com.anthropic.* during the
reproduction window — the failure is entirely silent, which is itself part of the bug.
The plugin loads normally:

INFO - #c.i.p.i.b.AppStarter - Loaded custom plugins: ... Claude Code [Beta] (0.1.14-beta) ...
INFO - #com.anthropic.code.plugin.services.PluginUpdateService - Plugin is up to date

Steps to Reproduce

1. Linux with a KDE Plasma Wayland session; PyCharm 2026.2, plugin 0.1.14-beta.
2. Open any project and put the caret in an editor.
3. Press Ctrl+Esc (the Quick Launch chord the plugin registers for $default).
4. Nothing happens; the editor keeps focus and the selection is untouched.
5. Close the Claude Code terminal tab and click the Claude Code button in the main

toolbar — also nothing.

Environment

| | |
|---|---|
| Plugin | Claude Code [Beta] 0.1.14-beta |
| IDE | PyCharm 2026.2, build PY-262.8665.369 |
| JBR | 25.0.3 (JBR-25.0.3+9-508.16-nomod) |
| CLI | claude 2.1.227 at ~/.local/bin/claude (on PATH) |
| OS | Linux 7.0.0-29-generic, KDE Plasma, XDG_SESSION_TYPE=wayland |
| Keymap | "KDE copy" (parent: "Default for KDE") |

Ruled out during diagnosis

• Not a DE-level shortcut grab. ~/.config/kglobalshortcutsrc binds only

Meta+Ctrl+Esc (Kill Window) and Meta+Shift+Esc; plain Ctrl+Esc is free.
System Monitor is on Meta+Esc.

• Not a keymap conflict. The KDE keymap did also bind Ctrl+Esc to

Vcs.CombinedDiff.ToggleCollapseBlock ("Collapse File"). Removing that binding
changed nothing, and the usage log proves the Claude action is the one being
invoked. (Worth noting separately: the plugin registering ctrl ESCAPE against
$default does collide with that action on KDE keymaps, and the IDE's Keyboard
Shortcut dialog flags it — probably worth avoiding regardless of this bug.)

• Not a missing CLI. claude --version → 2.1.227, on PATH at

~/.local/bin/claude.

• Not a hidden toolbar button. No hideToolbarButton setting is persisted and

CLAUDE_CODE_JETBRAINS_PLUGIN_HIDE_BUTTON is unset in the IDE's environment, so
update() should leave the action enabled and visible — and the button does render.

Possible lead

Reading OpenClaudeInTerminalAction from the shipped bytecode, actionPerformed
looks approximately like:

val mcpService = project.service<MCPService>()
if (!focusClaudeInTerminal(mcpService, project)) {
    val widget = TerminalUtil.openClaudeInTerminal(project)
    // then, unless skipClaudeNotFoundNotification:
    //   launch(Dispatchers.IO) { delay(...); if (mcpService.mcpServerInfos.isEmpty()) notify(...) }
}

There were three claude processes alive on this machine at the time (two of them
with socat bridges under /tmp/claude-http-*.sock). If focusClaudeInTerminal
decides success from MCPService's registered server infos rather than from an
actual terminal widget being focused, a stale or backgrounded registration would make
it return true and the action would short-circuit into doing nothing — matching the
observed silence in both the session-running and session-closed cases.

Is this a regression?

Unknown — this is the first version of the plugin used on this machine.