I’m not sure why there is radio silence from Cursor on this bug. It could be due to Composer Agent being an experimental feature, but I don’t want to speculate any further on that. I’m hoping it’s fixed soon so I can take advantage of the improvements on newer versions. They have the moat currently, so I can’t scream and shout here 
This issue has also been raised on GitHub.
The “I see there was an issue with the command. Let me try a different approach:” is due to the fact the PSReadLine error we are seeing is also fed to the LLM as the command output response, and it has no context this is a cursor bug, so it thinks the command that was ran was just incorrect and tries to issue another command it thinks will work (trying to use /bin/ls instead of just ls), issuing another function call starting a loop that will just fail every time as the shell is never respawned until “Pop out terminal” is selected.
I’m certain there will be other users who are confused thinking their commands aren’t right and just allowing it to continue in this failed loop.
On 0.44.11 the process which starts the commands from Cursor composer agent window is:
/usr/local/bin/pwsh -l -noexit -command . “/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration.ps1”
Previous on 0.43.5 where it worked it is:
/bin/zsh ‘-il’
Both versions hold onto the same process to run further commands until you pop out the terminal and then another process is spawned when it generates the next command. “Pop out terminal” after each command is a workaround for me.
I tried debugging further by looking at the dev tools and tracing the processes but ultimately didn’t have the time or knowledge to go any further.
If you pop out the terminal after each one it is a workaround. Still I keep downgrading to 0.43 as the workflow I had with composer agent was really powerful and I would be at a big loss without it now.