[macOS][Computer History] Accessibility traversal repeatedly freezes IntelliJ IDEA Git Log for 10–13 seconds

Independent reproduction with a newer Computer Use build and an older JetBrains Runtime confirms the same failure mode across versions.

Environment

• macOS 26.6.2 (25G83), Apple Silicon, 48 GB RAM
• Codex Desktop 26.814.41407
• Computer Use service 26.817.1000761
• IntelliJ IDEA Ultimate 2025.3.6.1
• JetBrains Runtime 21.0.11+10-b1163.116
• All third-party IntelliJ plugins disabled during reproduction
• Large repository: approximately 57,500 Git commits and 28,000 indexed files

Additional evidence

IntelliJ recorded:

UI was frozen for 11065 ms

The freeze report spent about 5.8 seconds on the EDT in this path:

CAccessibility.getChildrenAndRolesImpl
CAccessibility._addChildren
JTable$AccessibleJTableCell
GraphTableModel
PrintElementGeneratorImpl
CollapsedGraph

A separate live thread dump showed AWT-AppKit blocked in CAccessibility.invokeAndWait, while the EDT was computing IntelliJ VCS Log table cells and Git graph edges.

Computer History recorded repeated IntelliJ fullTree/diff captures during the same minute, followed by an approximately 11-second capture gap matching the IDEA freeze. Sanitized macOS TCC attribution also showed:

accessing  = com.openai.sky.CUAService
requesting = com.jetbrains.intellij

This still reproduced with all third-party IDEA plugins disabled, so plugins are not required.

A/B results

1. Adding the following VM option and fully restarting IDEA immediately stopped the freezes:

``text
-Dsun.awt.mac.a11y.enabled=false
``

1. Computer History was then changed to allowlist only two unrelated applications. After restarting the helper, the allowed applications produced 37 events, while IntelliJ produced 0 events and 0 fullTree captures.

The VM workaround was still enabled during the allowlist measurement, so the second result proves that IDEA tree collection stopped, but is not yet an independent UI-performance A/B test.

No raw logs, project names, source content, window titles, local paths, or host identifiers are included here. This appears to be a second independent reproduction of the exact issue, and also shows that it affects JBR21 as well as the JBR25 setup in the original report.

Independent reproduction on the same current Computer Use build. This also affects IntelliJ's Project tree (JTree), not only the Git Log JBTable, and I completed a direct helper-stop A/B.

Environment

• macOS 26.5.1 (25F80), arm64
• ChatGPT/Codex Desktop 26.814.41407
• Computer Use service 26.817.1000761 (build 1000761)
• IntelliJ IDEA Ultimate 2025.3.3 (IU-253.31033.145)
• JetBrains Runtime 21.0.10+7-b1163.108

Additional failure surface

While Computer History was running, clicking directories and other controls in IntelliJ's Project view produced repeated long stalls. A spot sample during the affected interval showed:

• SkyComputerUseService: approximately 108.6% CPU
• IntelliJ IDEA: approximately 38.5% CPU
• WindowServer: approximately 42.6% CPU
• 5 live SkyComputerUseClient computer-history mcp processes

IntelliJ logs repeatedly showed macOS accessibility failures involving the project tree, including:

JTree$AccessibleJTree$AccessibleJTreeNode.getBounds()
IllegalComponentStateException

The same interval contained sun.lwawt.macosx.CAccessibility activity. Sanitized macOS TCC attribution showed:

accessing  = com.openai.sky.CUAService
requesting = com.jetbrains.intellij

Direct A/B result

I stopped only SkyComputerUseService; IntelliJ remained open and macOS Accessibility permission was not revoked.

Immediately afterward:

• IntelliJ CPU fell from approximately 38.5% to approximately 0.3%.
• The user-visible directory/control lag disappeared.
• The five computer-history mcp client processes remained alive at low CPU, while the native service was absent.

This makes the Accessibility collector the distinguishing variable in this reproduction, rather than indexing, memory pressure, or the size of the project alone.

As a scoped workaround, IntelliJ (com.jetbrains.intellij) has now been added to Computer History's application blocklist while retaining macOS Accessibility permission. Computer History is currently stopped, so I do not yet have a post-resume performance A/B for the exclusion itself.

No raw logs, project names, source content, window titles, local paths, hostnames, or private identifiers are included.

Independent reproduction on a newer Desktop and Computer Use build confirms the same issue in PyCharm, during ordinary editor/UI interaction (not limited to IntelliJ's Git Log).

Environment

• macOS 26.6.2 (25G83), Apple Silicon, 96 GB RAM
• ChatGPT/Codex Desktop 26.818.61809 (build 7019)
• Computer Use service 26.823.1000854 (build 1000854)
• PyCharm 2026.2.1 (PY-262.9437.214), bundle com.jetbrains.pycharm
• JetBrains Runtime 25.0.3+9-b508.16

Evidence

Computer History was configured with the default observe all applications policy and no application blocklist. During a recording interval from approximately 12:24:26 to 13:12:45 local time, PyCharm repeatedly showed the macOS beachball and became unusable.

macOS generated two pycharm.cpu_resource.diag reports during the affected interval:

• 12:56:41–12:58:46: 72% average CPU. The report attributes 22 of 48 samples “On Behalf Of” PID 15155, which was the active SkyComputerUseService.
• 13:07:22–13:10:12: 53% average CPU and Note: Unresponsive. One sampled UI path was:

_XCopyHierarchy
  -> _AXXMIGCopyHierarchy
  -> __AXCopyAttributeValueForHierarchy
  -> NSAccessibilityChildren
  -> NavigableTextAccessibility.accessibilityParent

That stack is explicitly marked as executing on behalf of the same SkyComputerUseService PID.

The macOS unified log recorded 3,284 AccessibilitySupport.UIElementError entries from SkyComputerUseService during this recording interval (1,128 code 0 and 2,156 code 2). The event stream ended at 13:12:45 when Computer History was paused; the service's error burst ended about five seconds later. After pausing Computer History, the user-visible PyCharm beachball/freeze stopped.

This is consistent with the issue's existing evidence: synchronous or overly broad accessibility-tree traversal by Computer History is making a JetBrains application's UI thread do expensive accessibility work. This reproduction also shows the problem remains present with Desktop 26.818 and Computer Use 26.823, and affects PyCharm/editor accessibility elements rather than only the VCS Log table.

No raw logs, source content, project names, workspace paths, window titles, typed text, hostnames, or other local identifiers are attached. Redacted diagnostic excerpts can be provided if maintainers need them.

Additional controlled reproduction from 2026-08-25: this is not limited to the Git Log table. Ordinary typing in IntelliJ also stalls when Computer History is enabled, and the lag disappears when Computer History is disabled.

Evidence captured during the typing stall:

• A 20-second Java runtime recording showed no Java-side saturation: JVM CPU averaged about 10.6% user + 3.5% system; the UI event-processing thread used about 1.6% CPU.
• Garbage-collection pauses totaled about 20 ms, and the only observed lock contention was about 12 ms.
• Indexing had already completed, and there was no sustained editor or plugin hot path.
• During an independent native sample, IntelliJ was using more than 100% CPU. Its macOS interface thread spent nearly all samples in Core Foundation run-loop/set lookup code with accessibility frames present.
• The AppKit thread had accumulated about 101.9 seconds of CPU over roughly 299 seconds and was RUNNABLE in sun.lwawt.macosx.CAccessibility.getFocusOwner via LWCToolkit.invokeAndWait.
• At the same moment, IntelliJ's normal UI event queue was idle waiting for the next event.

This points to repeated macOS accessibility focus queries from Computer History, rather than indexing, garbage collection, editor analysis, or a specific IntelliJ plugin. It broadens the impact described here from expensive Git table traversal to ordinary editor focus/typing.

No project names, workspace paths, hostnames, raw logs, or session content are included.

Independent reproduction on Android Studio with a direct Computer History on/off A/B. This appears to be the same underlying issue, but it exposes an additional AccessibleHTML failure path while the Settings/Plugins UI is visible.

Environment

• ChatGPT/Codex Desktop: 26.820.60940 (build 7119)
• Computer Use service: 26.819.1000816 (build 1000816)
• macOS 26.5.2 (25F84), Apple M4 Pro, 48 GB RAM
• Android Studio 2026.1, build AI-261.26222.65.2613.16025427
• JetBrains Runtime 25.0.2+-15348964-b329.117, arm64

Symptom and live evidence

After Computer History had been enabled, Android Studio began showing the macOS beachball and becoming unresponsive during ordinary interaction, especially with Settings > Plugins open.

During a live freeze:

• Android Studio used approximately 103.2% CPU with about 2.39 GB RSS.
• Java heap usage was only about 516 MB of a 4 GB maximum, so this was not heap exhaustion or GC pressure.
• SkyComputerUseService was simultaneously using approximately 39.5% CPU.
• Three JVM thread snapshots taken over about 6.5 seconds repeatedly showed the AppKit Thread running through:
• CAccessibility.getAccessibleDescription
• CAccessibility.getAccessibleName
• CAccessibility.getAccessibleRole
• LWCToolkit.invokeAndWait
• AppKit thread CPU increased from about 26.25 s to 30.07 s while elapsed process time increased from about 50.3 s to 56.8 s.
• At the same time, AWT-EventQueue-0 was generally idle in EventQueue.getNextEvent, rather than blocked in Gradle, Dart, indexing, or a third-party plugin.

Android Studio's log also recorded:

InvocationEvent was disposed ... Originated at
sun.lwawt.macosx.CAccessibility.getChildrenAndRoles

followed by this accessibility-related exception:

Cannot invoke "javax.swing.text.html.ImageView.getAltText()"
because AccessibleHTML$IconElementInfo.getView() is null

AccessibleHTML$IconElementInfo$IconAccessibleContext.getAccessibleIconDescription
AccessibleHTML$IconElementInfo$IconAccessibleContext.getAccessibleName
sun.lwawt.macosx.CAccessibility$18.call
sun.lwawt.macosx.LWCToolkit$CallableWrapper.run

A background write action also reported waiting for 10 seconds during the same interval. Indexing had completed, there was ample heap headroom, and no OOM was present.

Direct A/B result

The user disabled Computer History in ChatGPT/Codex settings. No Android Studio plugin, JVM option, heap setting, or project configuration was changed.

After Computer History was disabled, the recurring Android Studio freezes stopped during continued use. The user reports that the IDE is now fully responsive.

This strengthens the attribution to Computer History's Accessibility traversal and shows that the problem also affects Android Studio's Settings/Plugins HTML accessibility tree, not only Git Log tables, project trees, editor focus, or DataGrip result grids.

No raw logs, project names, source content, window titles, account identifiers, hostnames, or local paths are included. Redacted thread-dump excerpts can be provided if maintainers need them.