Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
标题
Cursor Agent hangs on a specific repository due to .git contents; main thread spins in V8 Set.prototype.add / string hashing
环境
OS: Linux / OpenCloudOS
Command:
bash
1
/home/hanglu/.local/bin/cursor-agent --use-system-ca /home/hanglu/.local/share/cursor-agent/versions/2026.04.13-a9d7fb5/index.js -p --force
cursor-agent version:
2026.04.13-a9d7fb5
问题现象
cursor-agent hangs only for one specific repository:
bash
1
/code/fr_f_api_agg
Other repositories under the same parent directory work normally, so this does not appear to be a general environment issue.
Initially I suspected it might be related to scanning a large working directory, but after narrowing it down, the trigger is specifically the repository’s .git directory.
Key finding
If I temporarily remove or move away .git, the hang disappears.
If .git is present, the process hangs again.
So the issue is very likely caused by some metadata inside .git, not by regular project files.
pstack
Main thread is stuck in V8 internals:
v8::internal::String::ComputeAndSetRawHash
v8::internal::OrderedHashMap::GetHash
Builtins_SetPrototypeAdd
This strongly suggests the process is repeatedly hashing strings and inserting them into a JS Set / ordered hash map.
Meanwhile, most other threads are idle or blocked in expected wait states:
pthread_cond_wait
epoll_wait
futex
libuv threadpool waiting
tokio runtime threads waiting
There is also a loaded native module:
bash
1
merkle-tree-napi.linux-x64-gnu.node
which may indicate the issue happens during repository indexing / merkle tree construction / metadata traversal.
strace
strace -f -tt -T -p shows:
most worker threads waiting normally
the main thread repeatedly issuing getpid() syscalls without making visible progress
This does not look like an IO block or classic deadlock.
It looks more like a CPU-bound loop / pathological hot path in indexing logic.
我的判断
The agent seems to enter a pathological code path while processing .git metadata for this repository.
Given the stack trace, this likely involves:
generating a large number of strings
repeatedly inserting them into a JS Set
heavy string hash computation in V8
Possible trigger areas inside .git:
.git/objects
.git/refs
.git/logs
.git/packed-refs
.git/index
.git/worktrees
.git/modules
This may be:
an issue with git metadata traversal,
a deduplication bug,
a symlink/worktree/submodule-related recursion issue,
or a performance bug/regression in the merkle-tree indexing path.
复现特征
Reproducible only on one repository
Repro disappears when .git is absent
Other repositories on the same host do not reproduce the issue
期望行为
cursor-agent should either:
index the repository normally, or
skip / safely handle problematic .git metadata,
and should not hang indefinitely
已做的排查
Confirmed this is not caused by launching in the wrong directory
Confirmed other sibling projects work normally
Confirmed removing .git avoids the hang
Confirmed main thread is not blocked on mutex/epoll, but spinning in V8 string hash / Set.add
Steps to Reproduce
标题
Cursor Agent hangs on a specific repository due to .git contents; main thread spins in V8 Set.prototype.add / string hashing
环境
OS: Linux / OpenCloudOS
Command:
bash
1
/home/hanglu/.local/bin/cursor-agent --use-system-ca /home/hanglu/.local/share/cursor-agent/versions/2026.04.13-a9d7fb5/index.js -p --force
cursor-agent version:
2026.04.13-a9d7fb5
问题现象
cursor-agent hangs only for one specific repository:
bash
1
/code/fr_f_api_agg
Other repositories under the same parent directory work normally, so this does not appear to be a general environment issue.
Initially I suspected it might be related to scanning a large working directory, but after narrowing it down, the trigger is specifically the repository’s .git directory.
Key finding
If I temporarily remove or move away .git, the hang disappears.
If .git is present, the process hangs again.
So the issue is very likely caused by some metadata inside .git, not by regular project files.
pstack
Main thread is stuck in V8 internals:
v8::internal::String::ComputeAndSetRawHash
v8::internal::OrderedHashMap::GetHash
Builtins_SetPrototypeAdd
This strongly suggests the process is repeatedly hashing strings and inserting them into a JS Set / ordered hash map.
Meanwhile, most other threads are idle or blocked in expected wait states:
pthread_cond_wait
epoll_wait
futex
libuv threadpool waiting
tokio runtime threads waiting
There is also a loaded native module:
bash
1
merkle-tree-napi.linux-x64-gnu.node
which may indicate the issue happens during repository indexing / merkle tree construction / metadata traversal.
strace
strace -f -tt -T -p shows:
most worker threads waiting normally
the main thread repeatedly issuing getpid() syscalls without making visible progress
This does not look like an IO block or classic deadlock.
It looks more like a CPU-bound loop / pathological hot path in indexing logic.
我的判断
The agent seems to enter a pathological code path while processing .git metadata for this repository.
Given the stack trace, this likely involves:
generating a large number of strings
repeatedly inserting them into a JS Set
heavy string hash computation in V8
Possible trigger areas inside .git:
.git/objects
.git/refs
.git/logs
.git/packed-refs
.git/index
.git/worktrees
.git/modules
This may be:
an issue with git metadata traversal,
a deduplication bug,
a symlink/worktree/submodule-related recursion issue,
or a performance bug/regression in the merkle-tree indexing path.
复现特征
Reproducible only on one repository
Repro disappears when .git is absent
Other repositories on the same host do not reproduce the issue
期望行为
cursor-agent should either:
index the repository normally, or
skip / safely handle problematic .git metadata,
and should not hang indefinitely
已做的排查
Confirmed this is not caused by launching in the wrong directory
Confirmed other sibling projects work normally
Confirmed removing .git avoids the hang
Confirmed main thread is not blocked on mutex/epoll, but spinning in V8 string hash / Set.add
Operating System
Linux
Version Information
Linux (OpenCloudOS)
cursor-agent version: 2026.04.13-a9d7fb5
Does this stop you from using Cursor
Yes - Cursor is unusable