VoiceOver focus gets trapped in Codex CLI input in Warp and announces internal MaybeHoverSecret value

When using VoiceOver with Codex CLI in Warp, focusing/clicking the Codex chat input causes VoiceOver to move to a bad accessibility target and announce:

MaybeHoverSecret { secret_handle: None }.

This appears to be exposed through the macOS accessibility tree rather than spoken text invented by VoiceOver.

Environment

• macOS: 26.5.1, build 25F80
• Codex CLI: codex-cli 0.140.0
• Terminal: Warp Stable 0.2026.06.10.09.27.01
• VoiceOver: enabled
• Frontmost app during AX inspection: dev.warp.Warp-Stable

Reproduction

1. Start Codex CLI in Warp.
2. Enable VoiceOver.
3. Click or focus the Codex chat/input area.
4. Observe the VoiceOver caption/speech output.

Expected

VoiceOver should identify the focused Codex input with a useful label such as “Codex message input” or equivalent, and the user should be able to navigate away normally.

Actual

VoiceOver announces:

MaybeHoverSecret { secret_handle: None }.

The VoiceOver cursor appears to get pulled back to the Codex/Warp region after attempts to move it elsewhere or send a VoiceOver output announcement.

AX Evidence

macOS accessibility inspection after focusing the Codex input showed the focused element as a generic text area with no useful accessible metadata:

AXRole: AXTextArea
AXTitle: <nil>
AXDescription: <nil>
AXHelp: <nil>
AXIdentifier: <nil>
AXPlaceholderValue: <nil>

The parent window exposed the internal-looking value:

AXRole: AXWindow
AXTitle: ⠹ autonomy
AXValue: MaybeHoverSecret { secret_handle: None }.

Impact

This makes the Codex CLI difficult to use with VoiceOver because the input surface is not announced as a meaningful control and appears to expose an internal/debug value through accessibility.