LSP initialize timeout too short for Java/Gradle projects (~15s vs ~114s needed)

[norbu35]

Description

lsp_diagnostics always fails with Error: LSP request timeout (method: initialize) when used against a Java/Gradle project managed by JDTLS (Eclipse JDT Language Server). The built-in timeout for the LSP initialize request appears to be ~15 seconds, but JDTLS requires ~114 seconds to perform Gradle sync and workspace indexing for a moderately-sized project.

Steps to Reproduce

1. Configure opencode.json with "tools": { "lsp": true }
2. Open a Java/Gradle project (e.g., 3,000+ Java source files, ~60 dependencies, annotation processing enabled)
3. Trigger lsp_diagnostics on any .java file via an agent tool call
4. Observe the error: Error: LSP request timeout (method: initialize)

Expected Behavior

JDTLS should be given enough time to complete Gradle project import and workspace initialization. For Java/Gradle projects, this routinely takes 60–180 seconds depending on project size. The initialize timeout should be configurable and/or default to a value that accommodates JVM-based language servers.

Actual Behavior

opencode times out the initialize request after ~15 seconds, killing the JDTLS process and returning an error. Each failed attempt also leaves the JDTLS workspace in a dirty state (see evidence below), causing a cascading failure that makes subsequent attempts even slower.

Evidence

JDTLS workspace log (~/.cache/jdtls/.../.metadata/.log):

!MESSAGE Importing Gradle project(s)
!MESSAGE Workspace initialized in 114279ms    ← 114 seconds needed

Repeated workspace corruption from failed kills:

!SESSION 2026-04-23 20:04:12.723  ← JDTLS started
!MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes.

!SESSION 2026-04-23 20:04:27.912  ← killed after ~15s, started again
!MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes.

This pattern repeats 6+ times in the log — each failure leaves dirty state, each new attempt must recover + re-sync.

opencode stderr at time of failure:

⚙ lsp_diagnostics [filePath=.../ReviewPromptScenarioTests.java, severity=error]
Error: LSP request timeout (method: initialize)
recent stderr: WARNING: Using incubator modules: jdk.incubator.vector

Environment

• opencode version: 1.14.19
• JDTLS version: 1.57.0-SNAPSHOT
• Java: OpenJDK 21.0.11
• Project: ~3,036 Java files, 59 Gradle dependencies, annotation processing enabled (mapstruct, querydsl)
• OS: Arch Linux (x86_64)

Suggested Fixes

1. Make the LSP initialize timeout configurable in opencode.json, e.g.:

   "tools": {
     "lsp": {
       "initializeTimeout": 180000
     }
   }

   or increase the default significantly for JVM-based language servers.

2. Reuse a persistent LSP server process instead of spawning a fresh JDTLS per tool invocation. Once JDTLS has initialized, subsequent diagnostics requests are fast (<1s). The current per-call spawn architecture guarantees this timeout is hit every time for Java projects.

3. Graceful shutdown — send shutdown + exit before killing the process to prevent workspace corruption that compounds the problem on retries.

Workaround

None currently available — there is no config option to increase the LSP timeout, and the per-call spawn behavior cannot be overridden.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Java Save Actions LSP Timeout (Tool execution interrupted) #18185: Java LSP timeout issue ("Java Save Actions LSP Timeout")
• [FEATURE]: add timeout configuration for configured LSP entries #21005: Closed feature request to add configurable timeout for LSP initialize/diagnostics (very similar scope)
• [Bug] LSP freezes and diagnostics timeout too short (3s) for heavy language servers #13328: Closed bug report about LSP diagnostics timeout being too short for heavy language servers
• [FEATURE]: Allow configurable timeouts to be set on LSPs #7477: Closed feature request for configurable LSP timeouts

These cover the same root cause (LSP initialize/diagnostics timeouts too short for heavy language servers) and the same requested fix (configurable per-server timeouts). It may be worth checking if those issues capture your scenario or if this warrants a fresh report given the JDTLS/Java-specific evidence you've provided.

[lgladysz]

@Hona pls 🙇.
I have a similar problem with kotlin lsp (+ more):