[Bug] Permission prompt disappears after Ctrl+O toggle with concurrent tool calls

Resolved 💬 16 comments Opened May 18, 2026 by veger Closed Jul 2, 2026

Bug Description
Title: Permission prompt vanishes after Ctrl+O → Ctrl+O, command appears stuck with no way to approve/deny

Claude Code version: 2.1.143 (Claude Code)
OS: Linux 7.0.8-arch1-1 (Arch)
Shell: zsh
Model: Opus 4.7 (1M context)

## Steps to reproduce

Issue a Bash tool call that requires permission (e.g. a command not in the auto-allow list).

2a. When the "Allow this command?" prompt appears, press Ctrl+O to expand and view the full output / command text.
2b. When Ctrl-O was active and a new Bash tool call was activated (in the background)

Press Ctrl+O again to return to the normal view.

## Expected

The permission prompt is restored; user can approve or deny.

## Actual

The permission prompt is gone. The command is in a stuck state — there is no visible way to approve or deny it, and Claude appears to be waiting indefinitely. The only escape is Esc cancel and re-issue (user requests to continue).

## Frequency

Reliably reproducible. Hit it 3+ times in a single session today.

## Workarounds tried

Pressing another CTRL-O + CTRL-O to see if permissions is back did not work

## Notes

Cache stays warm across this state, so context isn't lost — just the UI affordance for approving the in-flight tool call.
Recent v2.1.141–143 changelogs mention fixes for "terminal becoming unresponsive after certain operations" — this may be a related case that wasn't covered.

Environment Info

Platform: linux
Terminal: ghostty
Version: 2.1.143
Feedback ID: 4789c86c-4937-404e-9c90-c172f262ed2f

Errors

[]

View original on GitHub ↗

16 Comments

github-actions[bot] · 1 month ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

veger · 1 month ago

The first 'duplicate' mentions:

Press Ctrl+O again to collapse the expanded output view, then the question prompt will be visible.

This was the case (IIRC), but seems to be broken in the current version, as the workaround I tried describes.

Duplicate 2 is marked as another duplicate which is about sandboxes, which is not the case here...

And duplciate 3 is about some freeze:

The Claude Desktop app (and Claude Code CLI) crashes or freezes, displaying a "Claude will return soon" service disruption screen.

It is not frozen here, but it does not show the question whether to run the Bash tool or not (and waiting for this) the rest of the application (CLI) is just working fine.

dwaltrip · 1 month ago

I'm having this same issue. It happens very frequently, if you use ctrl+o often.

The only workaround I've found is to cancel the tool use request and ask the model to try again, which isn't great.

---

Edit: I've just found another workaround for some cases.

For certain tool requests, you can hit ctrl+b to have it run in the background (e.g. bash commands), and you don't have to ask the model to redo the command. Still not ideal, but perhaps slightly better.

johannes-engler-mw · 1 month ago

I have the same issue and its really annoying.

phpmac · 1 month ago

+1 on this issue. I can reproduce this 100% of the time on macOS.

My environment:

Platform: macOS (Darwin 25.5.0)
Terminal: fish shell in Claude Code CLI
Version: latest

Reproduction rate: 100% - every single time I use Ctrl+O while a tool call is pending permission, the prompt vanishes and the session hangs. The only workaround is pressing Esc and asking the model to retry.

This is a critical UX bug that makes the Ctrl+O feature essentially unusable for me. Please prioritize a fix.

iammohitsakhuja · 1 month ago

Same issue. Seems to be relatively recent. Have been facing this for around 1-2 weeks now.

dwaltrip · 1 month ago

The worst is when it happens when the agent has been working for multiple minutes. You don't know if it's still thinking or if has submitted a tool request that you can't see.

The "esc" workaround feels risky here because then the model has to redo all of the thinking. As thinking blocks don't persist across conversation turns as far as I'm aware.

Probably the most frustrating bug I've seen.

phpmac · 1 month ago

The worst is when it happens when the agent has been working for multiple minutes. You don't know if it's still thinking or if has submitted a tool request that you can't see. The "esc" workaround feels risky here because then the model has to redo all of the thinking. As thinking blocks don't persist across conversation turns as far as I'm aware. Probably the most frustrating bug I've seen.

piagent

Metamess · 1 month ago

I'm also constantly hitting this issue and it's very frustrating; Thanks for reporting it veger! Commenting to lend weight to this issue and hoping a fix will soon be found and released!

TobPetDE · 1 month ago

Still reproducible on Claude Code 2.1.156 — but with a changed symptom (possibly indicating a cleanup-behavior change since 2.1.143):

Repro (verified just now):

Assistant issues a tool call requiring permission (e.g. sudo cat /etc/sudoers).
While the "Allow / Always allow / Deny" prompt is shown, press Ctrl+O.
The tool call is actively recorded as rejected with the message "The user doesn't want to proceed with this tool use. The tool use was rejected" — instead of getting stuck/waiting like in the original report.

The underlying interaction (Ctrl+O interfering with the open permission prompt) seems to be the same; the cleanup just now aborts the call instead of leaving it stuck.

Environment

Claude Code: 2.1.156 (also seen on 2.1.146)
OS: CachyOS, kernel 7.0.10-2-cachyos
Terminal: alacritty 0.17.0
Compositor: Hyprland 0.55.2 (Wayland)
Node: v26.1.0
Model: Opus 4.7
No custom ~/.claude/keybindings.json (default bindings)

_Created with Opus 4.7_

blightbow · 1 month ago

@dwaltrip The safest workaround I've found for the "hidden permissions prompt" variant of this bug is to use shift-tab to cycle between ask/accept-edits/etc. Cycling the permissions mode seems to "shake out" the pending permission event that isn't being shown to the user.

Of note, this can cause a deferred request to write a file to appear when toggling from the default "ask" mode to "accept edits". The fact that you get prompted to approve a request that "accept edits" mode would have allowed tells us that this was an approval sitting in the background and waiting for the user, but the associated user question was never rendered.

twinotter · 1 month ago

I'm also having this problem. It is an issue for my workflow because I like to look at the files the claude is creating before accepting them.

jhfry · 29 days ago

Just to pile on... I have the same issue on MacOS using a local model via LMStudio. I will hear the coil wine stop on my MBP, as well as observe that LMStudio has stopped processing, but there is nothing observable in the CLI other than some output in CTRL-o that may suggest it was about to perform an action. If I hit escape, it will tell me "User rejected update to..." or something similar, and I have to tell it to retry the update to see the prompt.

I can only imagine how annoying this must be using a remote LLM with no way to observe that it stalled.

johanvdlaak · 16 days ago

I've not seen the bug anymore on Claude Code v2.1.181 (with Opus 4.8). And neither on the version that I was on before, which I believe was v.2.1.179.

So feels like its fixed (at least for me).

lvlh2 · 15 days ago

I can also confirm this is fixed on the latest version (v2.1.196). Tested both scenarios:

Pressing Ctrl+O while a permission prompt is showing — no longer hides the prompt, goes to "dialog waiting" correctly.
Pressing Ctrl+O to expand a long-running script's output, then a new permission prompt appears while in the expanded view — the prompt displays correctly instead of being broken.

veger · 14 days ago

I also can confirm that it seems to be fixed, I'll close this issue