iOS: parallel permission-gated tool call hangs on busy signal (no prompt, no timeout)

Open 💬 0 comments Opened Jul 8, 2026 by russalo

Bug report — parallel permission-gated tool call hangs the iOS app on a busy signal (no result, no timeout)

Product: Claude Code — iOS app
Severity: High (blocks all input for the duration; only escape is cancel)
Date observed: 2026-07-08

Summary

When the model issues two Write (file-write) tool calls in parallel and the second one
requires a permission approval, the approval prompt never surfaced in the iOS app. The session
sat on a busy signal for ~78 minutes with no way to input except cancelling. No completion,
no failure, no timeout — a silently hung tool call.

Evidence (from the session transcript timestamps, UTC)

13:42:45  tool_use: Write  (file A — recall draft)     ← issued
13:43:00  tool_use: Write  (file B — fo draft)         ← issued (parallel)
13:43:08  tool_result       (file A) succeeded
   ...      78 minutes, zero events, busy signal, input blocked ...
15:01:16  tool_result       (file B) = "user doesn't want to proceed"  ← user forced a cancel

File A's write (which did not need a fresh approval, or whose prompt surfaced) completed in 8s.
File B's write returned nothing for 78 minutes until the user cancelled. Cumulative model
processing for the whole multi-hour session is only a few minutes — nothing accounts for the
78-minute window; it was a blocked tool call, not compute.

Expected

  • A tool call awaiting permission should surface its approval prompt reliably in the iOS app, OR
  • time out / report a failure the model can observe, OR
  • at minimum, leave the input field usable so the user isn't forced to cancel to regain control.

Actual

  • The approval prompt for the second parallel write never rendered.
  • The app showed a persistent busy signal; the user could not type.
  • The only way out was to cancel, which surfaced as a "user doesn't want to proceed" tool_result

~78 minutes later.

Likely mechanism

Parallel tool calls where >1 needs permission: the iOS approval UI appears to handle only the
first, leaving subsequent permission-gated calls with no rendered prompt and no timeout — so the
session hangs indefinitely on the un-surfaced approval.

Repro hypothesis

  1. iOS app, a project/mode where Write triggers a permission prompt.
  2. Have the model issue two Write calls to new files in one turn (parallel).
  3. Observe whether the second call's approval prompt surfaces; observe the busy-state / input lock.

Environment

  • Claude Code iOS app
  • Model: Opus 4.8 (1M context)
  • Platform (host executing tools): Linux (origin-core)

View original on GitHub ↗