Configurable editing shortcuts (copy/paste/cut) for the Claude Code prompt input

[jmoraleda]

The prompt input in the Claude Code view (a <textarea id="input"> inside the SWT Browser/WebView2 view, resources/claudegui/claudegui.html) has no editing keyboard shortcuts of its own — copy/cut/paste currently only work because they fall through to the webview's native textarea defaults. There's no way to customize or extend them.

I use Eclipse's "Emacs" key binding Scheme (Window → Preferences → General → Keys), so my muscle-memory editing keys are Alt+W (copy), Ctrl+Y (paste), Ctrl+W (cut). None of these do anything in the prompt input, since — being a webview, not a native SWT widget — it has no connection to the Eclipse workbench's Commands/Contexts/Scheme framework at all; that Scheme setting can't reach it by any means.

From a quick look at the code, I think that maybe one possible approach would be a new entry in ClaudePreferencePage.java (which already exposes several FieldEditor-based settings) passed through to the webview at load time, so #input's existing keydown listener in resources/claudegui/scripts/ui.js (currently handles Enter/Escape/arrow keys only, around line 152) reads copy/cut/paste bindings from that preference.

Env: Linux, Eclipse, "Emacs" key binding Scheme.

[eilonwy06]

I'll take a look at this, but its doable.

[eilonwy06]

Addressed in d3c2e26, released in v3.1.11.

The Claude Code view now activates org.eclipse.ui.edit.copy / cut / paste / selectAll / delete handlers on its own site, so the prompt input follows whatever you have bound under Window → Preferences → General → Keys — the Emacs scheme (Alt+W / Ctrl+W / Ctrl+Y), your own customizations and multi-keystroke sequences included. Nothing is hardcoded on our side: Eclipse does the key matching and just tells us which operation to run, which is why chords and per-platform modifiers come along for free. Ctrl+X / Ctrl+C / Ctrl+V / Ctrl+A still work on the default scheme, and the right-click menu now labels each entry with the key you actually have bound.

Two things came out of this that were not in the original report:

• Pasting an image no longer depends on the keystroke being Ctrl+V. Only Ctrl+V produces a DOM paste event in the embedded browser, so every other paste binding silently attached nothing; the clipboard is now read on the Java side instead.
• The Delete key never worked in the prompt input at all. JFace deliberately exempts Browser widgets from the plain-DEL binding, but the check tests event.character == SWT.DEL and SWT's WebView2 path fills in only keyCode — so the exemption stopped applying and the key was being consumed with no handler behind it.

Update site: https://eilonwy06.github.io/claudecode-eclipse-ide/com.anthropic.claudecode.eclipse.site/

Leaving this open for feedback on other schemes and platforms.

[jmoraleda]

Thank you for the quick response and for the new release. I have been testing it, but unfortunately the new keybindings still do not work for me.

The commands themselves appear to be registered correctly:

• The right-click context menu shows the expected custom key bindings for Copy/Cut/Paste/etc.
• Invoking the actions from the context menu works.
• The standard Ctrl+C/Ctrl+V/Ctrl+X bindings still work.

However, custom keybindings from my Eclipse scheme (for example Emacs bindings Alt+W, Ctrl+W, Ctrl+Y) do nothing in the Claude Code view.

One additional observation: I enabled:

Window → Preferences → General → Keys → "Show key bindings when command is invoked"

but I do not see any key binding activation reported for this view. (The same feature works normally in other Eclipse windows.) This makes me wonder whether the remaining issue is not command registration, but rather the keyboard event path between the embedded Browser/WebView2 control and Eclipse's key binding service.

Since the context menu actions work, it seems the handlers and commands are available; perhaps the missing piece is that some key events are not reaching Eclipse's key binding framework when focus is inside the browser control.

I am not sure whether this is a limitation of the underlying Browser/WebView2 integration or something that can be handled in the plugin, but I thought the distinction might help narrow down where to look.

If useful, I would be happy to provide additional debugging information. For example, I imagine it might help to know whether the Browser control is receiving the relevant SWT key events for Alt+W/Ctrl+W/Ctrl+Y, or whether those events are being consumed before reaching Eclipse.

Thanks again for working on this!

[eilonwy06]

This is probably environment-related since Emacs works on my end (Windows). I'll try to dig deeper into the issue and yeah, I would appreciate more information (and some logs if possible) regarding this one.

[jmoraleda]

Thank you. I am happy to help debug this. I am running Linux, so the environment may be the main difference from your Windows testing.

My environment:

• OS: Debian GNU/Linux 13 (trixie)

• Desktop: XFCE

• Session type: X11

• Eclipse IDE: 2026-06

• Java:

  openjdk version "21.0.11" 2026-04-21
  

• SWT:

  org.eclipse.swt_3.134.0.v20260515-1429.jar
  org.eclipse.swt.gtk.linux.x86_64_3.134.0.v20260515-1429.jar
  

• GTK:

  3.24.49
  

• Browser backend packages installed:

  libwebkit2gtk-4.1-0  2.52.3-2~deb13u1
  libwebkitgtk-6.0-4   2.52.3-2~deb13u1
  

I would be happy to run any experiments or a debug build with additional logging.

The most useful distinction may be whether the failing key events (for example Alt+W, Ctrl+W, Ctrl+Y) are reaching SWT/Eclipse at all when focus is inside the Claude Code Browser view, or whether they are being consumed by the browser layer.

Please let me know what logging or tracing you would like me to enable.

[eilonwy06]

@xgsa you might be able to help in diagnosing the issue. I can only depend on what Claude throws at me but it's not really testable from my end. Anyway, @jmoraleda here is what vibe coding with Claude got me that admittedly I have no confidence with, you can try and diagnose the problem with this:

It remains to be seen whether that re-dispatch actually produces an SWT.KeyDown. Eclipse's key-binding dispatcher is just a Display filter on SWT.KeyDown, so if the event never shows up there, no handler I register can possibly run — and everything else I try is guesswork.

Good news is we can answer it without a debug build. Save this as KeyProbe.java:

import org.eclipse.swt.SWT;
import org.eclipse.swt.browser.Browser;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.*;

public class KeyProbe {
public static void main(String[] args) {
Display display = new Display();

    System.out.println("SWT version : " + SWT.getVersion());
    System.out.println("GTK version : " + System.getProperty("org.eclipse.swt.internal.gtk.version"));
    System.out.println("SWT_GTK4    : " + System.getenv("SWT_GTK4"));
    System.out.println("GDK_BACKEND : " + System.getenv("GDK_BACKEND"));
    System.out.println();

    Shell shell = new Shell(display);
    shell.setText("SWT Browser key probe");
    shell.setLayout(new FillLayout(SWT.VERTICAL));

    new Text(shell, SWT.BORDER | SWT.MULTI);

    Browser browser = new Browser(shell, SWT.NONE);
    browser.setText("<html><body style='font:14px sans-serif'>"
            + "<p>Click in the box below, then press the keys.</p>"
            + "<textarea rows='6' cols='60'>type here</textarea>"
            + "</body></html>");

    // What Eclipse's key-binding dispatcher would see.
    display.addFilter(SWT.KeyDown, e -> System.out.println("FILTER  " + describe(e)));
    // What the Browser widget itself reports.
    browser.addListener(SWT.KeyDown, e -> System.out.println("BROWSER " + describe(e)));

    shell.setSize(760, 480);
    shell.open();
    while (!shell.isDisposed()) {
        if (!display.readAndDispatch()) display.sleep();
    }
    display.dispose();
}

private static String describe(Event e) {
    return "KeyDown keyCode=0x" + Integer.toHexString(e.keyCode)
            + " character=0x" + Integer.toHexString(e.character)
            + " stateMask=0x" + Integer.toHexString(e.stateMask)
            + " widget=" + e.widget.getClass().getSimpleName();
}

}

SWT=/path/to/org.eclipse.swt.gtk.linux.x86_64_3.134.0.v20260515-1429.jar
javac -cp $SWT KeyProbe.java && java -cp .:$SWT KeyProbe

There's a plain Text field on top and a Browser underneath. Click into the Text field and press Alt+W, Ctrl+W, Ctrl+Y, Escape, then a plain w — all five should print, which tells us the probe itself is wired up. Then click into the browser's textarea and press the same five. If you can paste both sets of output, that settles it.

What I expect to learn: Escape should print from the browser either way, since SWT handles that one specially. It's Alt+W I care about. If it prints, the events are reaching Eclipse and my handler registration is at fault — something I can fix. If it doesn't, then only Tab and Escape ever escape the webview on GTK, the Java-handler approach is a dead end there, and I'll match the bindings inside the page instead.

While you're in Eclipse, one unrelated five-second check: put the caret in the Claude prompt input and press Ctrl+3. Does Quick Access open? That's a stock Eclipse binding with nothing of mine behind it, so it's a second read on the same question from a different angle.

One correction on the key-binding popup, since I don't want to send you chasing it: I couldn't get it to appear on Windows either, in a case where the copy definitely worked. So its silence may not mean anything for this view on any platform. Your instinct about the event path still looks right to me — I just can't treat that particular signal as evidence until I work out why it's quiet.