An example of Cursor failing to send file data to Claude, for the third time in a row. These are chewing up my precious Fast-Replies, and it happens all the time.
I am using this version:
Version: 0.44.11
VSCode Version: 1.93.1
Commit: fe574d0820377383143b2ea26aa6ae28b3425220
Date: 2025-01-03T07:59:06.361Z
Electron: 30.5.1
Chromium: 124.0.6367.243
Node.js: 20.16.0
V8: 12.4.254.20-electron.0
OS: Windows_NT x64 10.0.22621
Hey, we are looking at a bug that causes this currently, and will hopefully resolve it soon!
I should like to point out how this effects the use of cursor. The feature that sends up the file data to the LLM fails to provide the file data. The LLM on the receiving end does not know this. It then goes from memory, which is often different than the actual file, or it simply guesses at what should be in the file(s). It then makes flawed recommendations, which often look similar to the original code when it is going from memory, and so errors of judgement are hard to detect. The Apply model then often misapplies the flawed recommendations in addition to them being flawed, frequently deleting good code, or mangling it in ways that are hard to detect while scanning the changes. In the end, because of the flawed FileSend() and Apply() we wind up going back and forth with the LLM – consuming precious Fast-Reply slots in the process and wasting quite a large percent of the money we spent on Cursor. These are internal Cursor flaws, and it costs quite a bit to have to go back and troubleshoot code that has been damaged in the process. The expense is in both time and money, since we pay a premium for Fast-Replies and when they are wasted this way many times in the course of operations it causes normally happy customers feel dissatisfied. I hear a lot about this on the discord. It was recommended to post the issue here. I hope you understand our position and will empathize with the sense of dissatisfaction over this. If you were a paying customer, I think you’d likely feel the same way. Anyway, aside from that, I wanted to express how this impacts the use of Cursor to give a more rounded appreciation of the problem and its effects. Thanks.
PS - Cursor is great. If it weren’t for this I’d be absolutely delighted with the product.
Hey, I understand this is a pain, and we are working hard to reproduce this internally!
Making a new fresh chat session should fix it as a workaround, and some users report being able to close and reopen Cursor to get things working if keeping your same chat session is important.
I would recommend regularly splitting off not a new chat / composer session, as some diseconomies of scale occur with long chats, where lots of messages and context can reduce the performance of the LLM compared to short, precise conversations!
This doesn’t excuse the bug, and I reiterate that we are working to fix this since we’ve known about it.
I think I may have a bead on what the problem is, and why you may not be able to easily replicated it. This is just a guess, but it may make sense. The internal model in cursor is probably well trained on currently popular languages, and probably far less trained on less popular languages. When encountering languages which it is not as well trained on, it may be making crucial judgement errors, and therefore failing to identify how to proceed, both in the Send() and the Apply() functions. The environment I am programming in is ASP.Net Web Forms with VB.Net Framework 4.7.2. This may be the missing link in terms of your analysis… or not. Anyway, as I suspect this is the case, and it is not unreasonable for you to focus training resources on popular languages, I suspect there may not be an easy fix for this. Anyway, I thought I would mention the idea, in case it helps.
Today I randomly lost the ability to share any files via @ with Cursor. I checked the logs but I don’t see any debug or error information. I tried new sessions, restarting my machine, and even upgrading. I was on a hobby plan so I even subscribed to see if it would fix itself in Pro mode but it did not.
2.6GHz 6-Core Intel Core i7
macOS Sequoia 15.0.1
I can enable any local logs and share them.
My current rules and config -
.cursorrules
.cursorignore
.cursor/
rules.md // rules to apply to templates
./templates/ // saved codegen templates
.notes/
// several .md files that cursor has generated for me
Ugh I figured it out the .gitignore file cannot ignore the cursor files or it borks loading and being able to share them.
Yeah
Just an FYI - that is not my issue as my .gitingore doesn’t include any cursor files.
Any progress on this?
Hey, we have now fixed the bug that caused files you @ to not be sent to the AI as expected. You may have to start a new Composer if you are still facing it now!
Good to hear. Thanks. Just to clarify, however… I am not using Composer, but I am using Chat. With Chat the issue has been consistently what I described in the OP. Sorry for not providing that clarification in the OP. At any rate, do you think the fix will work for both Composer and Chat? Thanks for your help!
This exact same thing happens to me all the time using Claude 3.5 and Composer. I found the best way to combat it until they fix it is to ask the AI to search for the file if it doesn’t see it. When it searches, it always gets it.
I have this same issue with Chat - although I have no context by default (because of issues with cursor accessing private keys) it still often shows the file included in chat, and still often doesn’t include it when i specifically add it
Hey, the fix should work for both! For context, it was a bug that occurred with long conversation history, but should be resolved now.
Hi Dan - have the default context options been removed? I can’t seem to see them any more.
Technically it’s now working for me, in that it’s adding the context automatically, but I had that option turned off because my cursorignore file doesn’t work - so i now risk leaking the keys if I use chat while my .env is open
Any ideas?
Hey, which contact options are missing for you?
As long as you don’t have auto-context enabled in the settings, your .env file will only be included by default if it is the current open tab, which you can remove before you submit your prompt.
I’m having the same issue after upgrading to the latest version yesterday. It was not an issue on the version I was using previously from September 2024. Claude sonnet is often unable to see files that I share with it. Copy/pasting directly always works but that shouldn’t be necessary.
Just to recap, re-indexing my codebase and starting a new chat should fix it?
Update: tried deleting the index and reindexing codebase. Deleting all chats and starting a new chat. Claude was unable to see my shared file. I’m going to revert to the earlier version because it was working as expected. Please let me know if there’s anything else I should try.
Hey, we did have a bug here, but I believe this should now be fixed - just check you are on the latest version available to you. You may also need to start a fresh Composer session, if you are seeing issues!
