Cursor position not correctly reported to macOS Accessibility API (Input Source Pro compatibility)

[ppoppopy]

What happened?

Details:
Gemini CLI does not seem to update its cursor (caret) position via the macOS Accessibility API.
As a result, input helper utilities like "Input Source Pro" fail to track the cursor, causing the indicator
to appear at the window's default location (bottom-left) instead of near the caret.

What did you expect to happen?

Comparison:
In the same iTerm2/Terminal.app environment, other tools like zsh, tmux, and opencode-cli correctly report their cursor positions, and Input Source Pro works as expected.

Client information

Environment:

• Gemini CLI version: 0.23.0
• OS: macOS (Darwin)
• Terminal: iTerm2
• Utility used: Input Source Pro

• CLI Version: 0.23.0
• Git Commit: 3ff0558
• Session ID: fdc4fe5c-51f8-43be-bac9-6518fc4cb98d
• Operating System: darwin v25.2.1
• Sandbox Environment: no sandbox
• Model Version: auto-gemini-3
• Memory Usage: 270.2 MB
• Terminal Name: tmux 3.6a
• Terminal Background: #18191b
• Kitty Keyboard Protocol: Unsupported

Login information

No response

Anything else we need to know?

No response

[ppoppopy]

I've investigated the difference in AX API behavior between Gemini CLI and other tools (like OpenCode CLI) using Hammerspoon's accessibility inspector. Here are the findings that pinpoint the cause:

1. OpenCode CLI (Working Correctly)
   When typing, it exposes the current input line as a distinct AXTextField element with a reasonable height (e.g., H: 21).

• Log: Role: AXTextField | X:829 Y:267 W:798 H:21

2. Gemini CLI (Issue)
   It exposes the entire terminal buffer as a single huge AXTextArea element, rather than the specific input line.

• Log: Role: AXTextArea | X:58 Y:-14344 W:1452 H:15248

Conclusion:
External tools fail because Gemini CLI provides a 15,000px high container instead of the specific cursor line coordinates. Implementing a proper AXTextField for the prompt line (similar to OpenCode CLI)
should resolve this issue.

Update with new log evidence:
I've compared the dynamic cursor tracking between gemini and opencode (both running in iTerm2 tabs).

OpenCode CLI (`ttys002`)*: Correctly updates AXBoundsForRange. As I type, the X-coordinate changes (e.g., X=97 -> X=125 -> X=209). Utilities can track this perfectly.
Gemini CLI (`ttys001`): Fails to update X-coordinate.* Even when typing multiple characters, it persistently reports X=62 (the start of the line).

This confirms that Gemini CLI's rendering engine is not reporting the real-time horizontal caret position to the macOS Accessibility API, whereas other tools in the same terminal environment do.