Has anyone tried version 0.5.0 to see if this issue has been resolved?
Hey, looks like the extension is doing something weird to the Git config, as the original post looks like Cursor is trying to run git config --get remote.origin.url
and the command is crashing.
Can you confirm this is still the error you are seeing, and if so, can you try run it manually and confirm the output? @OniReimu
Thanks for following up. Yes, the git config --get remote.origin.url command still appears in View > Output > Codebase Indexing. But just to clarify, this happens when I’m using the Overleaf Workshop extension, which connects to Overleaf using cookies rather than opening a local git repo. That means there is no local .git directory involved in these cases, so running git config --get remote.origin.url manually from the terminal (in the current directory) wouldn’t reflect the actual context. If I run it from a non-git directory, it simply returns nothing—which is expected.
Because of this, I believe the indexing failure and the indefinite “Generating…” issue are two separate problems, though I can’t be sure if they share a deeper root cause.
Here’s what I’ve observed:
- In version 0.50, regardless of whether indexing is enabled or disabled, I still hit the indefinite generating problem with both Cmd+L and Cmd+K.
- However, in version 0.45.15—where indefinite generating does not happen—I still get the indexing failure.
So this gives me strong confidence that indexing failure is not the root cause of the generation issue .
While fixing the indexing failure might be nice for Overleaf workflows, what really matters to us researchers is resolving the indefinite generating issue, which affects all versions from 0.46 onward, including the latest 0.50.
I’ve attached logs to help further (with no version label–running on 0.50), let me know if I can provide anything else.
indexing_logs.txt (16.3 KB)
indexing_logs_no_indexing.txt (6.3 KB)
indexing_logs_0.45.15.txt (5.8 KB)
indexing_logs_no_indexing_0.45.15.txt (1.8 KB)
More loggings if you needed:
extension_host_logs.txt (37.7 KB)
window_logs.txt (53.1 KB)
window_logs_no_indexing.txt (25.4 KB)
extension_host_logs_no_indexing.txt (27.0 KB)
window_logs_0.45.15.txt (8.7 KB)
extension_host_logs_0.45.15.txt (3.7 KB)
We changed some networking things between 0.46 and 0.50, can you try to disable HTTP2 and see if that helps:
Nope, no matter I disable the HTTP2 on user level or workspace level, still not working.
I am using 0.50.7 the issue persist
Version: 0.50.7 (Universal)
VSCode Version: 1.96.2
Commit: 02270c8441bdc4b2fdbc30e6f470a589ec78d600
Date: 2025-05-24T18:21:21.538Z
Electron: 34.3.4
Chromium: 132.0.6834.210
Node.js: 20.18.3
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.5.0
still not working too, and now we cannot use the old version, so hope to solve the issue
Yes, it is still impossible to link at present. This problem needs to be solved urgently
Hey, I’ve had a quick dig into this, but it’s not immediately clear how or why this extension is interfering with Cursor! I believe, by using a custom editor like this does, it will break the Agent as the normal text editor it expects is not available!
I’ve logged this for the team to look into, but it’s unfortunately not a top priority right now!
We are pretty sure Trae (another custom editor) has no issue on this and they also have the agent function.
As I said we all love cursor and we really want this to be fixed asap, especially the 0.45 version has been banned, making us have no choice.
Dear Cursor Team,
I am writing to express my significant frustration regarding a critical and long-standing bug with the Overleaf Workshop Plugin. For over four months, the AI features have been completely unusable, getting stuck indefinitely on the “Generating…” message.
This issue, previously reported under a title similar to “Bug Report: Overleaf Workshop Plugin Stuck on ‘Generating’”, remains unresolved despite the extended period. The seamless integration with Overleaf was a key reason for our adoption of Cursor, and its continued failure has severely disrupted our workflow.
While we have been patient, a four-month delay for a core feature is no longer acceptable. We are now at a point where we must seriously consider migrating our team to competing products, such as Tare and other alternatives, that can provide the stable functionality we require.
We need an immediate update on the status of this bug and a clear, committed timeline for its resolution. We hope to remain Cursor users, but we cannot continue with a tool that fails to maintain its essential features.
Sincerely
one of the pro users
Same issue in v 1.0.0
I have already logged this for the team to look into, but I’ve moved this to Feature Requests so that it’s easier to track the volume of users who want this fixed!
Please drop a vote for this if you want it, as that will help boost its priority internally!
Hi all, please vote for this one, and if you found friends around you also getting stuck in this issue, would be best to ask them to root for this request, thanks.