Read tool hangs indefinitely on Ruby files with a specific block variable name collision

[drhenner (David Henner)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Title: Read tool hangs indefinitely on Ruby files with a specific block variable name collision

Steps to Reproduce

Summary

The Cursor Read tool hangs for 60–130 seconds (then times out) when a Ruby file contains both of these patterns simultaneously:

A block variable named account_id produced by group_by(&:account_id):
array.group_by(&:account_id).each do |account_id, items|
A map call accessing .account_id on a block variable in a different method:
def some_method(events)
events.map { |e| e.account_id }.uniq

or: events.map(&:account_id).uniq

end
Minimal reproduction

class Example
Item = Struct.new(:account_id, :value)
def method_a(items)
items.group_by(&:account_id).each do |account_id, group|
puts account_id
end
end
def method_b(items)
items.map { |e| e.account_id }.uniq # ← triggers hang
end
end
Evidence from systematic debugging

Change Read tool result
map { |e| 1 } (no field access)
Instant
map { |e| e.ticket_id } (different field name)
Instant
map { |e| e.account_id }
Hangs 60–130s
map(&:account_id)
Hangs 60–130s
Rename block var to acct_id → then map { |e| e.account_id }
Instant
Root cause hypothesis

Cursor’s Ruby scope/type resolver encounters the name account_id used both as a local block variable (in method_a) and as a field accessor (in method_b), and enters an expensive or infinite cross-reference loop trying to unify the two references.

Workaround

Rename the block variable to avoid the collision:

array.group_by(&:account_id).each do |acct_id, items|
Notes

Machine restarts temporarily resolve the hang (likely clears a cached/stuck analysis state)
cat/sed via terminal always reads the file instantly regardless
The bug is not about file size — it reproduces at 158 lines

Expected Behavior

should be able to read ruby file

Operating System

MacOS

Version Information

OS: macOS darwin 24.6.0
File type: Ruby (.rb)
Models affected: Claude Sonnet 4.6, also reproduced with ChatGPT models
Cursor version: (check Help > About)

For AI issues: which model did you use?

Claude Sonnet 4.6, but also failed for Chat GPT 5.3 and 5.5

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the detailed report. The description looks interesting, but a couple things don’t quite add up, and I need a bit more info before I file a ticket.

What seems off:

• The Read tool in Cursor doesn’t parse Ruby and doesn’t do scope or type resolution. It just reads the file bytes. So the idea of a cross-reference loop in a Ruby resolver is unlikely. More likely the agent made up the account_id collision explanation when you asked why it was stuck.
• The fact that it reproduces the same way on Sonnet 4.6, GPT-5.3, and GPT-5.5 is another signal it’s not file parsing. It’s more likely something at the agent, network, or indexing layer.
• Restarting the machine fixes it. That looks like transient state like cache, a stuck request, or an indexing job. It doesn’t look like a deterministic parser bug.

To dig deeper, can you share:

1. The exact Cursor version Cursor > About. In the report it was still a placeholder.
2. The Request ID from the stuck request. In chat, open the message menu three dots or the top-right context menu > Copy Request ID. With that we can check what actually happened on the server during the hang.
3. When it hangs, is the spinner on the Read tool call specifically, or is the agent just Thinking. A screenshot of the hang would help.
4. Repo size, and whether indexing is running at that moment. Cursor Settings > Indexing.
5. Network setup. Corporate proxy, VPN, Zscaler. If yes, try enabling Disable HTTP/2 Settings > search HTTP/2 and see if it still happens.

With that info I can either reproduce it or file a proper ticket. The current minimal repro doesn’t hang for me locally, so without a Request ID or version info it’s hard to say what’s actually slowing down.