The new feature “suggest candidates to LLM” in “read file” operation is bogus and may result in out of control endless loop. LLM tried to open “■■■/yyy/service.go”, no such file exists. Local cursor code tries to suggest candidates. “■■■/yyy/” exists and has the only file “entrypoint.go”. Instead cursor offered two alternative paths to LLM (don’t remember names), but those variants were awful. LLM read one and said, ok, it’s not what I need. Returned back to step “read ■■■/yyy/service.go”. Two ended up in a loop.
There is no button “Stop” anymore or it’s masked. May be it only happens when you have “not accepted” changes and decides to continue conversation. In a such conversation agent went rogue, I saw it, but had to click “Accept” in order for “Stop” button to show up.
Context in the compose is switching to the current file in the following case and it’s wrong. Opened a file, started a new compose, wrote some instructions, realized that I don’t have pre-reqs in other file and it’s way easier to write them manually. Switched to editor, opened other file, wrote pre-reqs and switched back to compose/agent sidebar. Didn’t notice that cursor changed context to this second file with pre-req as the only context. I believe that if the input with instructions is not empty then compose shouldn’t be changed in any way without my explicit action.
Previous case ended in another bug manifesting. Sure I hit enter and got weirdest results generated in a wrong place. Scrolled to the top. Clicked “restore checkpoint”. Corrected context and hit “Send” to see another bogus generation. Looks like “restore checkpoint” on the very first message didn’t restore state, it kept all those code changes in the wrong file.
All of the above doesn’t seems like LLM’s culprit, but rather sloppy code in the cursor itself.