[BUG] [platform::intellij] DiagnosticTools freezes the IDE for 10–35s on EDT (Rider 2026.1, 0.1.14-beta) — regression of closed #10813

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

[BUG] [platform::intellij] DiagnosticTools freezes the IDE for 10–35s on EDT (Rider 2026.1, plugin 0.1.14-beta) — regression of closed #10813

Summary

The Claude Code JetBrains plugin's DiagnosticTools collects editor diagnostics on the EDT (UI thread), freezing the IDE for 10–35 seconds. JetBrains' freeze watchdog captured two separate freezes on the same day.

This is the same root cause as #10813 ("EDT Slow Operation Error in DiagnosticTools causing IDE freezes"), which was closed as "not planned" while on plugin 0.1.12-beta. On the current 0.1.14-beta it has regressed from a logged "slow operation" warning into multi-second hard UI freezes, and now affects Rider (the original report was IntelliJ/Linux). There are two distinct blocking code paths in DiagnosticTools.

Environment

| | |
|---|---|
| Plugin | claude-code-jetbrains-plugin-0.1.14-beta |
| IDE | JetBrains Rider 2026.1 (build RD-261.24374.190) |
| JBR | 25.0.2 |
| OS | Windows 11 Pro (10.0.22621) |

Reproduction / evidence

Two freezes auto-captured by the IDE freeze watchdog on 2026-06-04:

Freeze A — daemonFinished listener walks all highlighters on the EDT (~11s)

Folder: threadDumps-freeze-...-ContainerUtil.process-11sec. The EDT runs plugin code synchronously inside the daemon's applyInformationToEditorsLater write-intent action:

"AWT-EventQueue-0" ... RUNNABLE
  at com.intellij.openapi.editor.impl.RangeMarkerImpl.getStartOffset(...)
  at com.intellij.openapi.editor.ex.MarkupIterator$2.choose(...)
  at com.intellij.openapi.editor.impl.MarkupModelImpl.processRangeHighlightersOverlappingWith(MarkupModelImpl.java:303)
  at com.intellij.util.containers.ContainerUtil.process(ContainerUtil.java:907)          # ~5.1s here
  at com.intellij.codeInsight.daemon.impl.DaemonCodeAnalyzerEx.processHighlights(DaemonCodeAnalyzerEx.java:67)
  at com.anthropic.code.plugin.mcp.tools.DiagnosticTools$addTools$1$1$1.daemonFinished(DiagnosticTools.kt:112)   # <-- plugin
  at com.intellij.codeInsight.daemon.DaemonCodeAnalyzer$DaemonListener.daemonFinished(DaemonCodeAnalyzer.java:123)
  ... (MessageBus publish) ...
  at com.intellij.codeInsight.daemon.impl.DaemonProgressIndicator.stop(DaemonProgressIndicator.java:39)
  at com.intellij.codeInsight.daemon.impl.PassExecutorService.lambda$applyInformationToEditorsLater$3(PassExecutorService.java:568)

Every time the highlighting daemon finishes, the plugin's DaemonListener.daemonFinished (registered at DiagnosticTools.kt:112) iterates every range highlighter in the document and serializes the results to JSON — all on the EDT. On a large/heavily-highlighted file the iteration alone takes ~5s.

Freeze B — MCP getDiagnostics blocks on invokeAndWait to a jammed EDT (~34s)

A background MCP server thread handling a getDiagnostics tool call blocks the EDT:

"DefaultDispatcher-worker-..." (MCP server thread)
  at com.intellij.openapi.application.impl.ApplicationImpl.invokeAndWait(ApplicationImpl.java:667)
  at com.anthropic.code.plugin.mcp.tools.DiagnosticTools$addTools$1.invokeSuspend(DiagnosticTools.kt:81)   # <-- plugin
  at io.modelcontextprotocol.kotlin.sdk.server.Server.handleCallTool(Server.kt:395)
  at com.anthropic.code.plugin.mcp.WebSocketMcpServerTransport$start$2$1.invokeSuspend(WebSocketMcpServerTransport.kt:69)

Meanwhile the EDT is parked ~30s waiting to acquire the write-intent permit:

"AWT-EventQueue-0"
  at jdk.internal.misc.Unsafe.park(...)
  at com.intellij.openapi.progress.util.EventStealer.waitForPing(...)                       # 30000ms
  at com.intellij.openapi.progress.util.SuvorovProgress.dispatchEventsUntilComputationCompletes(...)
  at ...NestedLocksThreadingSupport$ComputationState.acquireWriteIntentPermit(...)

So getDiagnostics schedules work onto the EDT via invokeAndWait and blocks until the EDT is free, but the EDT is itself stuck contending for the lock — a ~34s freeze.

Root cause

DiagnosticTools performs diagnostic collection (highlighter iteration + workspace/index access + JSON serialization) on the EDT:

• DiagnosticTools.kt:112 — daemonFinished listener does the work synchronously on the EDT.
• DiagnosticTools.kt:81 — the MCP getDiagnostics handler uses invokeAndWait to run on the EDT and blocks the calling thread.

This matches the diagnosis in #10813 (isErrorAnalyzingFinished / WorkspaceFileIndexDataImpl.ensureIsUpToDate triggering slow ops on EDT).

Suggested fix

Move diagnostic collection off the EDT:

• In daemonFinished, hand off to ReadAction.nonBlocking(...).submit(...) (or a pooled thread) instead of iterating highlighters inline on the EDT.
• For the MCP getDiagnostics path, avoid invokeAndWait; compute under a background non-blocking read action and return asynchronously.
• Consider debouncing/cancelling stale collection when the daemon restarts, since daemonFinished can fire frequently.

Note

#10813 was closed as "not planned" but the underlying EDT work was never moved off the UI thread, and on current versions it now produces severe (10–35s) freezes on Rider. Requesting it be reopened / re-triaged.

What Should Happen?

it shouldnt crash

Error Messages/Logs

"AWT-EventQueue-0" ... RUNNABLE
  at com.intellij.openapi.editor.impl.RangeMarkerImpl.getStartOffset(...)
  at com.intellij.openapi.editor.ex.MarkupIterator$2.choose(...)
  at com.intellij.openapi.editor.impl.MarkupModelImpl.processRangeHighlightersOverlappingWith(MarkupModelImpl.java:303)
  at com.intellij.util.containers.ContainerUtil.process(ContainerUtil.java:907)          # ~5.1s here
  at com.intellij.codeInsight.daemon.impl.DaemonCodeAnalyzerEx.processHighlights(DaemonCodeAnalyzerEx.java:67)
  at com.anthropic.code.plugin.mcp.tools.DiagnosticTools$addTools$1$1$1.daemonFinished(DiagnosticTools.kt:112)   # <-- plugin
  at com.intellij.codeInsight.daemon.DaemonCodeAnalyzer$DaemonListener.daemonFinished(DaemonCodeAnalyzer.java:123)
  ... (MessageBus publish) ...
  at com.intellij.codeInsight.daemon.impl.DaemonProgressIndicator.stop(DaemonProgressIndicator.java:39)
  at com.intellij.codeInsight.daemon.impl.PassExecutorService.lambda$applyInformationToEditorsLater$3(PassExecutorService.java:568)

"DefaultDispatcher-worker-..." (MCP server thread)
  at com.intellij.openapi.application.impl.ApplicationImpl.invokeAndWait(ApplicationImpl.java:667)
  at com.anthropic.code.plugin.mcp.tools.DiagnosticTools$addTools$1.invokeSuspend(DiagnosticTools.kt:81)   # <-- plugin
  at io.modelcontextprotocol.kotlin.sdk.server.Server.handleCallTool(Server.kt:395)
  at com.anthropic.code.plugin.mcp.WebSocketMcpServerTransport$start$2$1.invokeSuspend(WebSocketMcpServerTransport.kt:69)

Steps to Reproduce

use claude code in rider to make a lot of changes to a large file

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.163 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_