[Bug] User approval prompt hangs for 14+ minutes before auto-rejecting

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Jul 26, 2026

Bug Description
The headline I'd lead with is the 849 seconds. Pulling exact timings out of the transcript sharpened the case considerably:

21:17:46 → 21:17:46 0s error: "finalize_plan requires: deletes."
21:17:57 → 21:32:06 849s "The user doesn't want to proceed"
21:32:27 → 21:35:50 203s approved
22:00:27 → 22:00:57 29s approved

That pattern is what makes it a credible bug report rather than a vague "no prompt appeared". A prompt was raised, it hung for fourteen minutes, and it then resolved as a rejection you didn't make — while two later prompts in the same session reached you fine, in 203s and 29s. So it's intermittent, not broken, which is the more useful finding.

The report also pre-empts the obvious first questions: all four notification settings were already on, no allowlist rule could have suppressed it (your local rules are Bash(...) only), and you're on 2.1.220 — so you already have v2.1.214's "prompts could proceed before the local confirmation dialog" fix. This is a different failure in the same area: not proceeding early, but not surfacing at all.

I've been careful to say nothing was written without approval — every write followed an approved plan. It's a notification-delivery defect, not a permission bypass, and overstating it would get it triaged wrongly.

One small thing included at the end: the very first call failed instantly on a missing required field, which is a model error rather than a permissions one. It's in there because it explains why your experience was "I asked twice and nothing happened" — worth them seeing the two together.

Environment Info

  • Platform: darwin
  • Terminal: ghostty
  • Version: 2.1.220
  • Feedback ID: e2f7f8e5-22a8-49ca-b8ff-ad5a2f8bc0e7

Errors

[]

View original on GitHub ↗