Jar files auto-created and added to classpath on Cursor startup

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Bug Report: Java project classpath reintroduces internal build/libs jars after restart
Summary
Cursor’s Java tooling reintroduces internal subproject build/libs/*.jar entries into the live Eclipse/JDT classpath after restart, even when the Gradle/Buildship model resolves those same dependencies as project references.

This causes local multi-project Gradle dependencies to behave like jar dependencies instead of live project/classfile dependencies during development.

Environment
OS: Windows 11
Cursor
Java extension stack bundled with Cursor
Workspace: multi-project Gradle build
Repo root: C:\Users<USER>\git<REPO>
Observed Java server startup includes:

-Djava.import.generatesMetadataFilesAtProjectRoot=false
Affected example
Project:

admin-tools
Internal Gradle project dependencies:

project(“:server-common”)
project(“:db-common”)
project(“:runtime-common”)
Expected behavior
After restarting Cursor and importing the Gradle workspace:

local Gradle subproject dependencies should remain project references in the live Java project model
Cursor should not re-add internal jars from:
server-common/build/libs/.jar
db-common/build/libs/.jar
runtime-common/build/libs/*.jar
Actual behavior
After restart, admin-tools shows internal jars again in Project Settings / Classpath / Libraries, for example:

C:\Users<USER>\git<REPO>\runtime-common\build\libs\runtime-common-20260420175810.jar
C:\Users<USER>\git<REPO>\db-common\build\libs\db-common-20260420175810.jar
C:\Users<USER>\git<REPO>\server-common\build\libs\server-common-20260420175810.jar
These entries come back even if manually removed before restart.

  1. Buildship saved model is correct
    File:

C:\Users<USER>\AppData\Roaming\Cursor\User\workspaceStorage\5baaec092d306f62d1591afa2ed486bd\redhat.java\jdt_ws.metadata.plugins\org.eclipse.buildship.core\project-preferences\admin-tools

Observed contents:

contains project refs such as:
/server-common
/db-common
/runtime-common
contains external dependencies from .gradle\caches
does not contain internal repo jar paths under /*/build/libs
This indicates Buildship is generating the desired model.

  1. Live Eclipse/JDT classpath is wrong
    File:

C:\Users<USER>\AppData\Roaming\Cursor\User\workspaceStorage\5baaec092d306f62d1591afa2ed486bd\redhat.java\jdt_ws.metadata.plugins\org.eclipse.core.resources.projects\admin-tools.classpath

Observed contents include:

This indicates the live Eclipse/JDT project classpath is being materialized incorrectly after the Buildship model is already correct.

Additional findings
Repo-root admin-tools/.classpath was deleted before restart and did not get recreated.
The active bad classpath came back under workspaceStorage, not the repo root.
Java logs show multiple importers are active, including:
GradleBuildServerProjectImporter
GradleProjectImporter
EclipseProjectImporter
This suggests the incorrect jar entries are likely being introduced in Cursor’s Java import/runtime pipeline after Buildship model generation.

Impact
breaks expected live multi-module development workflow
causes stale or timestamped jar references to reappear on restart
makes Cursor prefer built jar artifacts over local project/classfile references
can trigger missing-library errors when timestamped jars change
Workarounds tried
Gradle eclipse.classpath.file.whenMerged customization
direct .classpath cleanup
targeted project-reference injection
deleting cached classpath files before restart
These confirm the Buildship model can be made correct, but Cursor still reintroduces internal jar entries in the live classpath.

Suggested investigation area
Please inspect how Cursor materializes org.eclipse.buildship.core.gradleclasspathcontainer into the live JDT/Eclipse project classpath, especially when Buildship’s saved model already contains project references for local Gradle subprojects.

Steps to Reproduce

Open the Gradle multi-project workspace in Cursor.
Ensure admin-tools depends on local subprojects via implementation project(…).
Restart Cursor and let Java/Gradle import complete.
Open admin-tools Project Settings / Classpath / Libraries.
Observe that internal build/libs/*.jar entries have been added.

Expected Behavior

Generated jar files should not be automatically added to the classpath on restart of cursor

Operating System

Windows 10/11

Version Information

Version: 3.1.17 (system setup)
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. Great investigation.

But the key point is that this behavior isn’t Cursor-specific. Java tooling like project import, Buildship, and materializing the classpath from org.eclipse.buildship.core.gradleclasspathcontainer into a live .classpath file all comes from the Red Hat Java extension and the built-in Eclipse JDT and Buildship. Cursor doesn’t patch or override that pipeline. You can reproduce the same thing in VS Code with the same extension. The -Djava.import.generatesMetadataFilesAtProjectRoot=false flag you’re seeing is also a standard one from redhat.java.

The three active importers you saw in the logs, GradleBuildServerProjectImporter, GradleProjectImporter, EclipseProjectImporter, are a known conflict point in redhat.java. This looks like a good candidate for an upstream issue.

Things you can try locally:

  • In Settings, check and disable competing importers:
    • java.import.gradle.enabled: true
    • java.import.gradle.wrapper.enabled: true
    • disable java.import.projectSelection or the Eclipse importer if it’s a Gradle project
    • try java.gradle.buildServer.enabled: false or toggle it the other way to see which importer adds the extra jar entries
  • Delete workspaceStorage/.../redhat.java/jdt_ws completely and let the import run again. Sometimes the cache keeps an old .classpath even after the model is cleared.
  • Check whether eclipse.classpath.file.whenMerged is being applied in the opposite direction. Re-sorting can bring entries back if the Buildship container resolves before the merge.

For a proper fix, it makes sense to file an issue here and include your files, .classpath plus the Buildship project preferences:

If you find the specific importer that’s causing it, send it here and we can check if there’s anything we can tweak by default in Cursor.

6

Thanks for the feedback. I tried a the suggestions you provided and no luck. I’ve filed an upstream ticket here - Gradle multi-project import materializes internal build/libs jars into live JDT classpath · Issue #4399 · redhat-developer/vscode-java · GitHub

7

Circling back to close the loop on this ticket, RedHat vscode-java development suggested disabling the new Scala-in-Gradle support by adding the following to your settings.json file (in my case project.code-workspace in my git folder). This did the trick for me.

"java.jdt.ls.scalaSupport.enabled": false

It seems there may have been some undesired behavior recently released in that plugin. See linked ticket in my previous comment for more details.