SAP ADT (ABAP) editors are invisible to getOpenEditors / getCurrentSelection / getWorkspaceFolders #153

Plugin version

3.2.9.202609272153

Eclipse version and OS

2026-09

What happened?

I tried to use the ClaudeCode plugin in combination with the SAP ADT plugin (https://tools.hana.ondemand.com/#abap), but unfortunately that didn't work very well. So obviously I tasked Claude to debug the problem, and here is his report (If you need more information, I will try my best to provide it):

Summary

When using the plugin with SAP ABAP Development Tools (ADT), Claude Code cannot see any open ABAP editor, the current selection, or the ABAP project:

• getOpenEditors → {"editors":[]} (two ABAP editors are open)
• getCurrentSelection / getLatestSelection → {"text":"","isEmpty":true} (text is selected in an ABAP editor)
• getWorkspaceFolders → {"folders":[]}, although the log says Lock file written (Rust) for port 10000 workspace=... projects=1

The IDE connection itself works fine (lock file, port and PID match the running Eclipse). The cause is two assumptions in the Java side of the plugin that don't hold for ADT; details below.

Environment

• Plugin: com.anthropic.claudecode.eclipse_3.2.9.202609272153
• Eclipse: 4.41 (build 4.41.0.20260903-0719), JustJ OpenJDK 25
• SAP ADT: 3.60.4 (com.sap.adt.oo.ui_3.60.4, com.sap.adt.programs.ui_3.60.4)
• OS: Windows 11

Steps to reproduce

1. Install ADT and create an ABAP project connected to any SAP system.
2. Open an ABAP class and an ABAP report (program) in their editors.
3. Select some text in one of them.
4. In Claude Code, call getOpenEditors, getCurrentSelection and getWorkspaceFolders.

Expected: both editors are listed, the selection is returned, and the ABAP project shows up.
Actual: all three return empty results.

Root cause

I analysed the installed 3.2.9 jar with javap (I couldn't locate the Java sources in the repo, so class and method names below come from the bytecode).

1. ADT editors are MultiPageEditorParts, not ITextEditors

GetCurrentSelectionTool, SelectionTracker.onSelectionChanged() and SelectionTracker$PartActivationListener.partActivated() all do:

if (!(part instanceof ITextEditor)) return /* empty */;

ADT's source editors are multi-page editors:

com.sap.adt.oo.ui.internal.classes.editors.MultiPageClassEditor        (editor id com.sap.adt.abapClassEditor)
  └ com.sap.adt.tools.abapsource.ui.sources.editors.AbapSourceMultiPageEditor
      └ org.eclipse.ui.part.MultiPageEditorPart

com.sap.adt.programs.ui.internal.programs.editors.ProgramEditor         (editor id com.sap.adt.programs.ui.AdtProgramEditor)
  └ com.sap.adt.tools.abapsource.ui.sources.editors.AbapSourceSinglePageEditor
      └ AbapSourceMultiPageEditor
          └ org.eclipse.ui.part.MultiPageEditorPart

The actual text editor is the selected page (IAbapSourcePage extends ITextEditor), so the instanceof check always fails. (AbapSourceMultiPageEditor.getAdapter() does not appear to handle ITextEditor.class either.)

2. ADT files are not on the local file system

ABAP projects live in the Eclipse semantic file system. The project's location URI is semanticfs:/E10_900_user_de, so IResource.getLocation() returns null for the project and for every file in it.

• EditorUtils.getFilePath(IEditorInput) returns null when IFile.getLocation() is null.
• GetOpenEditorsTool silently skips every editor whose path is null → empty list.
• SelectionTracker.onSelectionChanged() returns early when the path is null → selection is never tracked, even if issue 1 is fixed.
• GetWorkspaceFoldersTool skips projects whose IProject.getLocation() is null → no folders.

Suggested fix

a) Resolve the embedded text editor (use it in GetCurrentSelectionTool, SelectionTracker and PartActivationListener):

static ITextEditor resolveTextEditor(IWorkbenchPart part) {
    if (part instanceof ITextEditor te) return te;
    if (part instanceof MultiPageEditorPart mp
            && mp.getSelectedPage() instanceof ITextEditor te) return te;
    return part != null ? part.getAdapter(ITextEditor.class) : null;
}

Selection events from a MultiPageEditorPart already arrive as ITextSelection via MultiPageSelectionProvider, so once the editor is resolved the rest of the existing logic should work. This isn't ADT-specific: it would also help other multi-page editors (PDE manifest editor, m2e POM editor, etc.).

b) Don't drop non-local resources; fall back to a URI or workspace path:

// EditorUtils.getFilePath
IFile file = fileInput.getFile();
IPath loc = file.getLocation();
if (loc != null) return loc.toOSString();
URI uri = file.getLocationURI();            // e.g. semanticfs:/E10_900_user_de/...
return uri != null ? uri.toString() : file.getFullPath().toString();

Do the same in GetWorkspaceFoldersTool (fall back to getLocationURI()). Also, GetOpenEditorsTool could list an editor with its label even when no path can be resolved, instead of skipping it.

Claude Code can't read such a path from disk. Still, with (a) and (b) the open editors become visible, and getCurrentSelection returns the selected text inline, which covers the most common use case ("explain the selected method").

Possibly affected as well (not verified)

openFile, getDiagnostics, openDiff / acceptDiff and saveDocument probably make the same local-path assumption. For full ADT support, these tools would need to resolve workspace paths or semanticfs: URIs through the workspace (e.g. ResourcesPlugin.getWorkspace().getRoot().getFile(...), or findFilesForLocationURI) instead of the local file system. Since ADT sources aren't on disk, an optional tool that returns the content of an open editor's document would be useful too.

Happy to test a build against ADT if that helps.

Relevant logs