Freeze on big monorepo with skills

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

On a big monorepo, the CLI freezes on launch if there is a .cursor/skills folder commited (even without skills).

Steps to Reproduce

On a big monorepo (mine has 56203 files), create the folder .cursor/skills and commit it (add an
empty file to it if needed). Then launch agent and watch it freeze.

Expected Behavior

It should start.

Operating System

Linux

Version Information

2026.04.17-787b533

For AI issues: which model did you use?

N/A (we don’t get to this part)

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Thanks for the detailed report. On a monorepo that large, one hypothesis is that the presence of .cursor/skills is triggering a broader file discovery scan across the workspace at startup, which would explain the freeze.

If you remove (or rename) the .cursor/skills directory, does the freeze go away and the CLI start normally?

7

Hi. Simply deleting the folder does not solve the issue, I have to delete and commit the changes, then it works again.

8

Thanks for the report! I tried reproducing this on a large monorepo but wasn’t able to get it to freeze. The code guards against this scenario pretty well.

A few follow-up questions:

  • Is this reliably reproducible for you? i.e., if you remove .cursor/skills it works, and adding it back causes the freeze again every time?
  • Was the .cursor/skills folder at the root of the monorepo (next to .git)?
9

I’m having trouble producing a MWE too. But the problem is submodule-related. If I checkout the repo, switch to the branch which has the .cursor/skills folder (.cursor is alongside .git at the root) and run agent, it works. Then I run git submodule update --init and it doesn’t (--recursive changes nothing here). I tried each submodule in isolation and found out that there are three that produces the problem when they are only submodule checked out:

  • github: xR3b0rn/dbcppp
  • github: dhermes/bezier
  • github: KumarRobotics/ubox

However creating an empty repo and adding them did not reproduce the problem.

I don’t know if it matters, but the URL for our submodules are all relative (we fork them to not depend on github’s infra):

`[submodule "ublox"]`
`path = src/drivers/ublox`
`url = ../../../../../info/ros/ublox`
`[submodule "dbcppp"]`
`path = src/drivers/bla/submodules/dbcppp`
`url = ../../common/dbcppp`

So the problem is 100% reproducible on this repo, even on a fresh clone. Either removing the skills folder or keeping it but removing the submodule makes it work again (to remove the submodule I have to remove both the checked out folder and its .git/modules folder). But I didn’t get it to trigger in a MWE.

10

I don’t know how useful it is, but every time I pause the attached debugger, it is at this place.
It’s not so visible in the screenshot, but it’s the add in s.add("${o}/") that is highlighted.

image
image2543×2095 352 KB

11

Thanks! The plot thickens…

I think the freeze is coming from a ripgrep process. Could you try adding a .ignore file at the repo root to exclude the submodule directories?

# .ignore
src/drivers/dbcppp/
src/drivers/bezier/
src/drivers/ublox/

Doesn’t explain everything, but would rule some stuff in / out!

12

That’s interesting. The presence of a .ignore, even if empty, solved the freeze. I thought it was
the for loop going back up to . in a string that doesn’t have . on it, but apparently not. Or
maybe that’s still the case but the .ignore file being present changes something before that,
which makes the paths get the . on them. And how did you suspect ripgrep? That was quite a nice
shot. Just to provide more information: the rg process is there in the tree, but it’s at 0% CPU usage while the MainThread is at 100%.

13

I made a video to show it happening, just to show I’m not making anything up, because I know it’s weird and I wasn’t able to produce an MWE: https://www.youtube.com/watch?v=5VXp9UraMoA