claude-code - 💡(How to fix) Fix Mobile: tool-approval modal pops up over the on-screen keyboard, causing accidental denies while typing

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

On mobile (Claude Code mobile app), tool-approval / decision modals appear in a position that overlaps the on-screen keyboard. When the modal pops up while I'm actively typing a message, a keystroke lands on one of the modal buttons (most commonly the deny button at the top of the modal, which is roughly where the keyboard's top row sits) and silently denies the tool call.

Root Cause

The denial is not recoverable in-band — the assistant has to either retry the exact call or wait for me to redirect, and there's no UX cue that the deny was an accidental typing collision vs. an intentional rejection. In a session today I lost a researcher dispatch (CUSTOMER_NOTES.md edit) to this; the agent reported "edit denied" and stood by, and I had to type "edit was denied because it popped up while I was typing. try again" to get it re-attempted.

Fix Action

Fix / Workaround

The denial is not recoverable in-band — the assistant has to either retry the exact call or wait for me to redirect, and there's no UX cue that the deny was an accidental typing collision vs. an intentional rejection. In a session today I lost a researcher dispatch (CUSTOMER_NOTES.md edit) to this; the agent reported "edit denied" and stood by, and I had to type "edit was denied because it popped up while I was typing. try again" to get it re-attempted.

  • Claude Code mobile app, 2026-05-17
  • Tool-approval modals during agent dispatch flow (the case above was an Edit tool call from a sub-agent)
  • Platform: filer can clarify on request — bug is keyboard-overlap, likely platform-agnostic but verified on at least one mobile target today
RAW_BUFFERClick to expand / collapse

Summary

On mobile (Claude Code mobile app), tool-approval / decision modals appear in a position that overlaps the on-screen keyboard. When the modal pops up while I'm actively typing a message, a keystroke lands on one of the modal buttons (most commonly the deny button at the top of the modal, which is roughly where the keyboard's top row sits) and silently denies the tool call.

Impact

The denial is not recoverable in-band — the assistant has to either retry the exact call or wait for me to redirect, and there's no UX cue that the deny was an accidental typing collision vs. an intentional rejection. In a session today I lost a researcher dispatch (CUSTOMER_NOTES.md edit) to this; the agent reported "edit denied" and stood by, and I had to type "edit was denied because it popped up while I was typing. try again" to get it re-attempted.

Expected behavior

The approval modal should not overlap the active input region. Options:

  • Anchor the modal above the keyboard (so the keyboard remains usable and the modal buttons are clear of the typing surface)
  • Suppress / queue the modal while the keyboard is open and the user is actively typing
  • Require a deliberate gesture (long-press, swipe) rather than a single tap to confirm deny, when the modal opened within N ms of a keystroke

Environment

  • Claude Code mobile app, 2026-05-17
  • Tool-approval modals during agent dispatch flow (the case above was an Edit tool call from a sub-agent)
  • Platform: filer can clarify on request — bug is keyboard-overlap, likely platform-agnostic but verified on at least one mobile target today

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The approval modal should not overlap the active input region. Options:

  • Anchor the modal above the keyboard (so the keyboard remains usable and the modal buttons are clear of the typing surface)
  • Suppress / queue the modal while the keyboard is open and the user is actively typing
  • Require a deliberate gesture (long-press, swipe) rather than a single tap to confirm deny, when the modal opened within N ms of a keystroke

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Mobile: tool-approval modal pops up over the on-screen keyboard, causing accidental denies while typing