When the agent reads files, it is displayed as “Reading [filename]” and after done there is only the word “Read” - filename missing. For all Read tool calls.
Steps to Reproduce
Just let the agent read ANY files in cursor 2.3.x.
Expected Behavior
Like before, it would be “nice” to see what files the agent was reading.
I see the screenshot with the agent tools. You’re right, after the read finishes it only shows “Read” without the file name, even though during the process it correctly shows “Reading [filename]”.
This looks like a UI regression in version 2.3. I’ll pass it to the team to fix.
Could you share the Request ID from one of these chats? (Top right in the chat > Copy Request ID) That’ll help the engineers find the cause faster.
52e21bb8-6824-4f61-add6-d5dd79f343a6 is the Request ID for a missing Read filename request.
Important notice: In a follow up request (13162d0f-e19a-4594-8f8a-c326bfcde213) i had one read with missing filename, then a failure of the “Read server ‘cursor’ not found” kind, then one read with missing filename and one which had the filename - exactly this order so the read did not fix itself after the error of read server, the events were arbitrary - see screenshots.
I’m downgrading now to 2.2 in the hope my chats will not be broken, 2.3 is as reliable as an early alpha apparently, arbitrary file read failures are not a mode i can work in.
I suspect this happens when the file path is too long to be displayed in the chat and the chat tries to display the full file path; or there is some kind of error when it tries to shorten it.
Could you try temporarily disabling your MCP servers and see if the filename display issue still happens? This will help confirm whether the issue is related to MCP.
Go to Cursor Settings > Features > MCP Servers, disable the servers and restart Cursor, then check the agent behavior.
The filename was being displayed with the transition effect during the “Reading [filename]” and then it disappeared leaving only “Read” so i would say it was not about the length, in case of a long filename a hidden overflow would be the normal behavior as far as i recall from cases with extremely long filenames but not 100% sure atm.
Sorry but I can’t, the version for which i reported was generally not usable - see random “Read server ‘cursor’ not found“ mentioned in the report - this was for me basically a “broken IDE” at that point. As I stated above i have reverted to a stable 2.2 version (until i finish implementing current feature). The version info was attached including OS info etc.. I did however try restarting cursor without effect so it was a persistent error to a degree.
I’m downgrading now to 2.2 in the hope my chats will not be broken, 2.3 is as reliable as an early alpha apparently, arbitrary file read failures are not a mode i can work in.
EDIT: I can do it after i can safely switch versions - in case something happens with the chats (as it rarely does)
As a quick sidenote: i never had any negative impact of this type - ever - especially also the read error itself. Which is expected, a series of mcp tool call consecutively or even in parallel can not be seen as a valid explanation for the effect observed - i rather hints at a certain type of error (event order/locking during ui updates maybe, style update race against label update etc.)
