Whenever the agent runs a command and after the command executes , instead of generating a followup command or taking context from the result for further execution , agent gets stuck and never does anything while the UI says its generating while it generates nothing even after letting it run for extended period of time
Steps to Reproduce
Any command that needs the agent to perform a command on the terminal should trigger the issue
Operating System
MacOS
Current Cursor Version (Menu → About Cursor → Copy)
When I was new to cursor, way back 3 days ago, I noticed this kind of thing. When I clicked, run in background, or maybe hide in background, then it seemed to start back up. But it had been running all the time. My thought was that it just hides all of the writing out of what it’s doing to save resources. However, you might have a totally different problem.
I can confidently say this is a bug as I have been using Cursor for atleast 6 month with the Pro and this is something that never happened before. In the background it will wait for a prompt and the chat will never continue and if I skip then the agent re-caliberates from the start of the chat like it forgot its own words or something.
I faced a very similar issue on MacOS 26.0 — the command runs fine in the terminal, but Cursor Agent never proceeds or generates a follow-up. If you’re using a custom shell setup (like oh-my-zsh, a modified .zshrc, or anything that alters shell behavior), that could be interfering.
Quick question:
Are you using oh-my-zsh or any customized .zshrc or .bashrc config?
In my case, the fix was simply adding this line to the top of my .zshrc:
if [[ "$TERM_PROGRAM" == "vscode" ]] || [[ "$TERM_PROGRAM" == "cursor" ]]; then
return
fi
It prevents any complex shell configs from loading only when Cursor is executing agent commands, and it completely solved the issue.
Let me know your setup — happy to help tailor a fix.
I’m getting something similar and it looks like the vm-daemon setup is creating a read-only databse when it should be writeable. This issue is cascading into process crashes. There’s also further evidence to suggest that these issues might have been triggered by a recent update to the vm-daemon.
When tailing the logs while trying to get the agent to respond I get the following:
[error] [storage state.vscdb] prepare(): Error: SQLITE_READONLY_DBMOVED:
attempt to write a readonly database (INSERT INTO ItemTable VALUES (?,?))
Quite right about my reply. It probably answered some other novice’s question… badly. (Not a novice to tech, though. My first computer was a Sinclair ZX-80.)
If your Cursor Agent terminal hangs or fails to detect command completion, the root cause might be your .zshrc loading a heavy or interactive configuration (e.g., Oh My Zsh, plugins, custom prompts).
This affects the Agent’s ability to detect when a command is completed — even though it may have already run successfully in the background.
How We Solved It
We compared the environment variables of two separate shells inside Cursor:
The interactive terminal (Ctrl + `)
The Agent terminal, which is hidden but runs commands
Using env in both, we discovered that the Agent shell includes specific environment flags not present in the interactive shell.
Notably:
Great question — the posted solution was tested on macOS, where the Cursor Agent injects specific environment variables like PAGER and COMPOSER_NO_INTERACTION that we can reliably detect in .zshrc.
On Windows (especially under VSCode or WSL), the injected environment might differ. You can try running env > ~/env_agent.txt inside the Agent terminal and comparing it to your interactive shell (env > ~/env_interactive.txt), then run:
diff ~/env_interactive.txt ~/env_agent.txt
Look for any unique flags like npm_config_yes, PIP_NO_INPUT, etc. Once you find something consistent, you can use the same logic:
if [[ "$SOME_ENV_FLAG" == "1" ]]; then
return
fi
Let me know what you find — happy to help fine-tune a Windows/WSL-friendly version!
RESOLVED: Agent Terminal / 
How We Solved It