Codex Computer Use Accessibility permission causes DataGrip UI to freeze on macOS

Summary

When Codex Computer Use has macOS Accessibility permission enabled, JetBrains DataGrip becomes completely unresponsive shortly after rendering a non-trivial SQL result grid. Disabling Accessibility permission for Codex Computer Use.app makes the issue disappear.

This looks like an interaction between Codex Computer Use's Accessibility inspection and JetBrains Runtime's macOS accessibility bridge.

Environment

• Codex Desktop: 26.818.41509
• Codex release date: Aug 22, 2026
• Computer Use: enabled
• macOS: Tahoe 26.1
• Hardware: Apple M4 Pro
• DataGrip: 2026.2.4, build DB-262.10315.24 (built Aug 20, 2026)
• JetBrains Runtime observed in thread dump: OpenJDK 25.0.4+1-b508.27

Reproduction

1. Grant Accessibility permission to Codex Computer Use.app in macOS System Settings > Privacy & Security > Accessibility.
2. Launch DataGrip.
3. Connect to a MySQL-compatible database.
4. Run a query that returns a normal table result grid, for example several hundred rows.
5. The query completes and the result grid is fully rendered.
6. After a short delay, DataGrip becomes completely unresponsive and macOS reports the application as not responding.

Small queries such as SELECT 1 do not reproduce consistently. LIMIT 1 and LIMIT 10 are generally fine, although UI stalls become noticeable as the result grid grows.

Control test

Turning off only the macOS Accessibility permission for Codex Computer Use.app, restarting DataGrip, and running the same query stops the freeze.

Re-enabling the permission makes the problem reproducible again.

Other Accessibility-enabled applications were tested during diagnosis; Codex Computer Use.app was the specific toggle that controlled the behavior.

JDBC / database controls

The issue reproduced with two different JDBC stacks:

• legacy AWS JDBC Driver for MySQL
• current AWS Advanced JDBC Wrapper

The SQL result had already been fully displayed before the freeze, so the problem does not appear to be query execution or result fetching.

Thread dump evidence

A JVM thread dump captured during the affected session showed the macOS AppKit thread spending substantial CPU time in the Java accessibility bridge:

"AppKit Thread" ... cpu=64814.81ms elapsed=87.00s ... RUNNABLE
  at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(Native Method)
  at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(...)
  at sun.lwawt.macosx.LWCToolkit.invokeAndWait(...)
  at sun.lwawt.macosx.CAccessibility.invokeAndWait(...)
  at sun.lwawt.macosx.CAccessibility.isFocusTraversable(...)

At the same time, the Java EDT was idle waiting for the next event:

"AWT-EventQueue-0" ... WAITING
  at java.awt.EventQueue.getNextEvent(...)
  at com.intellij.ide.IdeEventQueue.getNextEvent(...)
  at java.awt.EventDispatchThread.run(...)

The DataGrip JDBC engine was also idle, waiting for work:

"JdbcEngine" ... WAITING
  at java.util.concurrent.LinkedBlockingQueue.take(...)
  at java.util.concurrent.ThreadPoolExecutor.getTask(...)

This suggests the freeze occurs in or around macOS Accessibility/AppKit processing rather than JDBC execution.

Expected behavior

Granting Accessibility permission to Codex Computer Use should not cause unrelated applications to freeze while their UI hierarchy changes.

Actual behavior

With Codex Computer Use Accessibility permission enabled, rendering a sufficiently large DataGrip result grid can cause DataGrip's native macOS UI thread to become unresponsive.

Workaround

Disable macOS Accessibility permission for Codex Computer Use.app.

I can provide the full DataGrip JVM thread dump if useful.