App freezes in the middle of a session
What happened?
Issue: Gemini CLI application freezes completely, preventing user input (typing) and requiring a full restart of the application.
Impact: This issue severely disrupts workflow and causes significant loss of time due to frequent restarts.
Observed Behavior:
- The entire CLI interface becomes unresponsive.
- User is unable to type any commands or interact with the application.
- The only resolution is to close and restart the Gemini CLI.
What did you expect to happen?
The Gemini CLI should remain responsive and allow user input at all times, even during periods of backend processing or network latency.
If a command is taking too long, it should ideally provide feedback or allow for interruption e.g. via Ctrl+C without freezing the entire application.
Client information
- CLI Version: 0.12.0
- **Git Commit:
Login information
No response
Anything else we need to know?
No response
Found possible duplicate issues:
- #6959
- #6829
- #9970
- #7735
- #10470
- #11935
If you believe this is not a duplicate, please remove the status/possible-duplicate label.
This issue is not a duplicate. Please recheck.
same issue, very frustrating, happens several times a day, wasting hours of planning. might be correlated with gemini making large batch edits at once but it's hard to tell. I have several terminals open of course, and I think I scrolled during an edit. less than 50 files in context.
this should be a sev1. it's unreasonable to prioritize any issue besides this until it's resolved, considering that you don't even have a mechanism to restore state (besides time traveling to before the failure and checkpointing).
you could at least just automatically checkpoint every message as a mitigation - the fact that a persistence mechanism is clearly right there, fully implemented, and you didn't even bother to hook it in is kinda insulting.
What OS are you all running? This could be related to MCP servers. Does the issue go away if you unregister MCP servers and extensions?
I've experienced this too (internally; go/12650-chat). On Mac, Linux as well as web terminals.
It happens maybe every few hours or so, it seems worse since the past week.
It seems like it happens sometimes maybe more after locking/unlocking (on Mac) my laptop; though it might be red herring and just if the terminal is not being use for a while.
Happy to grab more data next time it happens, let me know what you need.
We're having a hard time figuring out what causes this. There's a tiny chance it's due to getting stuck in a bad paste-buffer mode. If that's the case it should timeout in 30 seconds. So, next time you see this, try waiting 45 seconds and seeing if that fixes it (and let me know if!)
Will do. I'm pretty sure I've been more patient than 30-45s in the past when it happened though.
I was also wondering if it might be due to too many "zombie" Gemini processes from past aborted sessions too. I noticed many "gemini" processes were still active despite only having one active terminal. I rebooted my workstation since, so I'll see if the symptoms start to appear again overtime.
Just happened a gain after a fresh reboot (so, no zombies). Still frozen after 30-45s. Let me know what kind of data would be useful if it happens again.
I have repro steps: go/12650-repro-steps, I could repro 3 times with the same steps.
Thank you @tdevaux ! This is very useful. The fact that the UI freezes up (the loading spinner pauses) shows the issue isn't just one of keyboard input being frozen. That's very good to know.
A user reports that they get this reliably when usingtmux but they don't see it when not using tmux on the same machine. So that might be an important clue.
If anyone sees this and is not using tmux, let me know.
The latest nightly release of gemini automatically saves your work history in sessions. If the freeze is triggered by a bad tool call we might be able to see it in the automatic session logs in ~/.gemini/tmp/<project_hash>/chats/ Just find the latest json file in there and send us the last couple messages (redacting any private info of course).
Additionally, if you see it freeze, please take a screenshot and send it to us. That might give us a hint of what's happening.
Sample frozen session: go/12650-sample-session-1
We believe what tdevaux is running into is the same as b/466194131 which other googlers are seeing. Investigating it there...