Agents not responding and indexing not working

[tsufleta (Tomsufle)]

When I run any agent request, I keep on getting messages like “Taking longer than expected” or “Planning next move” even for the most basic prompts like “confirm you can you read xyz.md”.

Things I have tried (mainly by googling) and none have helped (but some have seemed better behavior):

• restarting cursor and entire MacOS… obvi

• Checking Cursor Account dashboard (that takes to browser). Nothing out of the ordinary indicated.

• blowing away .cursor directory

• Checking Index, but ~/Library/Application\ Support/Cursor/Index doesn’t exist

• In Cursor Setting → Network

  • Switching to HTTP/1.0 or HTTP/1.1 and restarting cursor

  • Run Diagnostic - screenshots below for 2.0 and 1.1

  • I have a suspicion that one of the IT network protection apps is responsible, but I can’t verify

• Checking Cursor Setting → Indexing & Docs

  • With HTTP/1.0 I have had times were it finished indexing, but often times it gets stuck on “Initializing…” or “initializing 2/4”

• Checking Cursor logs. There are some errors in the Cursor Indexing & Retrieval , but I’m not sure what they indicate. I can’t seem to upload the exported .log files to this thread (probably for corporate security reason) so please let me know how to best get help around this.

• Whenever I open Cursor, the GitHub login modal dialog pops up many times (see screenshot) and it doesn’t want to authenticate using any of the methods (BitBucket token or browser signin). I confess I did play around with installing a BitBucket MCP and other tools at some point, but I can’t remember exactly what. I have tried removing the GitHub from Cursor Setting → Tools and checking Extensions & Plugins but nothing exists (and after blowing away .cursor there’s no extensions installed). I have also tried most of the various suggestions from google (link). Some of the Cursor logs do indicate issues with git, so maybe this is related, but i’m not sure and it may be a red herring.

[mohitjain (Mohit)]

Hi @tsufleta

Your Network Diagnostics screenshots clearly identify the issue. Your corporate network is running Netskope as an SSL-inspecting proxy (ca.publicisgroupe.de.goskope.com), which is intercepting and re-signing all encrypted traffic to Cursor’s servers.

This causes two problems:

1. HTTP/2 fails entirely because the proxy doesn’t support HTTP/2 ALPN negotiation

2. In HTTP/1.0 mode, streaming is buffered by the proxy, which is why agents appear stuck at “Planning next moves” / “Taking longer than expected” before eventually returning a response all at once

Indexing failures are a downstream effect of the same connectivity issue.

The fix is on your IT/network side. The most effective solution is to have your IT team exclude Cursor’s domains from Netskope SSL inspection. These are the domains to allowlist/bypass:

*.cursor.sh
*.cursor-cdn.com
*.cursorapi.com
authenticate.cursor.sh
authenticator.cursor.sh

Our Enterprise Network Configuration docs cover this in detail, including curl commands your IT team can use to verify the fix.

If SSL inspection can’t be disabled for those domains, a secondary option is to have IT install the Netskope CA certificate into your macOS system Keychain (as a trusted root), then in Cursor press Cmd+Shift+P and open “Preferences: Open User Settings (JSON)” and add:

"http.systemCertificates": true,
"http.experimental.systemCertificatesV2": true

Keep HTTP/1.0 selected in Cursor Settings > Network for now, as HTTP/2 won’t work through Netskope.

Regarding the GitHub login popups: this is a separate issue. Try pressing Cmd+Shift+P and running “GitHub: Sign Out” to clear cached auth state. If that doesn’t stop the popups, you can also disable the built-in GitHub Authentication extension: go to the Extensions view, type @builtin github in the search bar, and disable GitHub Authentication.

A similar thread with the same class of proxy issue was resolved here: Unable to verify first certificate

[tsufleta (Tomsufle)]

@mohitjain

Your Network Diagnostics screenshots clearly identify the issue. Your corporate network is running Netskope as an SSL-inspecting proxy (ca.publicisgroupe.de.goskope.com), which is intercepting and re-signing all encrypted traffic to Cursor’s servers.

This causes two problems:

1. HTTP/2 fails entirely because the proxy doesn’t support HTTP/2 ALPN negotiation
2. In HTTP/1.0 mode, streaming is buffered by the proxy, which is why agents appear stuck at “Planning next moves” / “Taking longer than expected” before eventually returning a response all at once

Indexing failures are a downstream effect of the same connectivity issue.

The fix is on your IT/network side. The most effective solution is to have your IT team exclude Cursor’s domains from Netskope SSL inspection. These are the domains to allowlist/bypass:

*.cursor.sh
*.cursor-cdn.com
*.cursorapi.com
authenticate.cursor.sh
authenticator.cursor.sh

Our Enterprise Network Configuration docs cover this in detail, including curl commands your IT team can use to verify the fix.

If SSL inspection can’t be disabled for those domains, a secondary option is to have IT install the Netskope CA certificate into your macOS system Keychain (as a trusted root), then in Cursor press Cmd+Shift+P and open “Preferences: Open User Settings (JSON)” and add:

"http.systemCertificates": true,
"http.experimental.systemCertificatesV2": true

Keep HTTP/1.0 selected in Cursor Settings > Network for now, as HTTP/2 won’t work through Netskope.

Thank you Mohit for the timely and informative response. I REALLY appreciate it. I have forwarded this to my company’s network security team.

I am curious if you have a POV on why the symptoms I have mentioned appeared suddenly a couple days ago. I believe I had HTTP/2 set and it has been working for several weeks. I’m just trying to ascertain if there’s other underlying issue to address.

[tsufleta (Tomsufle)]

@mohitjain : Also re GitHub: I tried both your suggestions (“GitHub: Sign Out” and “disable GitHub Authentication”), and restarting Cursor afterwards. The dialog keeps popping up. Any other ideas?

Thank you!

Tom

[mohitjain (Mohit)]

Hey @tsufleta

Glad the guidance was helpful!

Why it appeared suddenly: This most commonly happens when your IT team deploys an updated Netskope policy or proxy configuration. These changes can roll out without end-user notification. Worth asking your security team if any network policy changes were pushed around when the symptoms started. A Netskope or macOS update could also subtly change how SSL inspection behaves.

GitHub login popup still appearing: Since “GitHub: Sign Out” and disabling the built-in GitHub Authentication extension didn’t help, the credentials are likely persisted at the macOS system level. Try these steps:

1. Open Keychain Access (Spotlight > search “Keychain Access”), search for github and vscode, and delete any matching entries

2. In Terminal, run git config --global credential.helper to check if macOS is managing git credentials. If it returns osxkeychain, that helper may be re-triggering the auth flow. You can clear stored GitHub credentials by running:

   printf "``host=github.com``\nprotocol=https\n" | git credential-osxkeychain erase

3. Restart Cursor after clearing both

If the popup still persists after that, you can also temporarily disable Cursor’s built-in git integration by adding "git.enabled": false to your settings JSON (Cmd+Shift+P > “Preferences: Open User Settings (JSON)”). If the popup stops, it confirms git is the source, and we can narrow down from there.

[tsufleta (Tomsufle)]

Hi Mohit,

I have done 1,2,3 and set “git.enabled”: false. I have restarted Cursor. The Github dialog continues to popup. Any other thoughts?

Thank you so much for all your support!

Tom

[mohitjain (Mohit)]

Since it persists after all of that, the popup is likely coming from a source outside of git. A few more things to try:

1. Disable Cursor’s GitHub login for retrieval: Open your settings JSON (Cmd+Shift+P > “Preferences: Open User Settings (JSON)”) and add:

   "cursor-retrieval.canAttemptGithubLogin": false
   

   This prevents Cursor’s retrieval system from prompting for GitHub access, which is a separate trigger from the git integration.

2. Disable all built-in GitHub extensions: In the Extensions view, search @builtin github. You’ll see multiple results, including “GitHub” (separate from “GitHub Authentication”). Make sure all of them are disabled, not just “GitHub Authentication”.

3. Clear stored auth sessions: In Terminal, run:

   rm -rf ~/Library/Application\ Support/Cursor/User/globalStorage/vscode.github-authentication

   Then restart Cursor. This removes persisted GitHub auth state that survives the other steps.

4. Check if Settings Sync is using GitHub: Cmd+Shift+P > “Settings Sync: Show Synced Data”. If it’s syncing via GitHub, turn it off (Cmd+Shift+P > “Settings Sync: Turn Off”).

If the popup still appears after all four steps, could you share the exact text of the dialog? That will help pinpoint which component is triggering it.

[tsufleta (Tomsufle)]

Hi Mohit, an update:

The IT team turned off Netskope for my machine, but the problem persists. The network tab no longer shows buffering and SSL issues (see screenshots). The issue seems to be with referencing files via ‘@’. When I ask to do some action without specifying files, it is responsive and engages in the normal processing including reading/writing to the local files (and accessing online and terminal commands). If I include a ‘@filefile’ on any command (in any project), it does not respond and just indicates ‘Taking longer than expected’. See screenshots and exported cursor logs. Thoughts?

I have not tried your latest GitHub recommendations, but will do that today. Just wanted to give you the above update.

cursor-output.txt (182.4 KB)

[tsufleta (Tomsufle)]

Also, I tried all 4 GitHub steps and the dialog continues to popup (see screenshots that includes the exact dialog). As mentioned before, entering a valid token and/or ‘Sign in with your browser’ where the browser indicated “Authentication Succeeded. You may now close this tab and return to the application” does not make the dialog stop from incessantly popping up again.

For step 4: Cmd+Shift+P > “Settings Sync: Show Synced Data” or any variations (e.g. “settings sync” or “show synced data”) are not appearing as options (see screenshot).

I’m not sure if the ‘@file’ handle non-responsiveness is related to the GtiHub dialog issues (I have always suspected not), but maybe there’s something there.

Thougths?

[tsufleta (Tomsufle)]

BTW, just to confirm Netskope being disabled

, see screenshot.

[mohitjain (Mohit)]

Hey @tsufleta – I reviewed your cursor-output.txt logs and found the cause of both issues.

@file references hanging

This is caused by "git.enabled": false in your settings – which I suggested as a diagnostic step earlier. Your logs show the Grep Service failing with “cannot index repository without Git” and repeated “Failed to execute git” errors. The @file feature depends on this service.

Fix: Remove "git.enabled": false from your settings JSON (Cmd+Shift+P > “Preferences: Open User Settings (JSON)”), restart Cursor, and test @file again.

GitHub login dialog

Your logs show GitHub Copilot extensions are active: github.copilot-chat, ms-azuretools.vscode-azure-github-copilot, and ms-vscode.vscode-copilot-data-analysis. These are separate from the @builtin github extensions you already disabled – and they require GitHub authentication, which is almost certainly what’s been triggering the popup.

Fix: Go to Extensions, search for “copilot”, and disable or uninstall all three Copilot extensions. Then also remove "cursor-retrieval.canAttemptGithubLogin": false from your settings, restart Cursor, and the dialog should stop.

Since you’re using Cursor’s built-in AI, the Copilot extensions aren’t needed and will conflict.

[tsufleta (Tomsufle)]

THank you Mohit for the continued support. I cannot find any of those extensions in the UI. See screenshots attached, and I have looked through the lists carefully and there’s no installed extensions for any of those. I have also tried looking for just ‘copilot’, but same situation. Is there any other way uninstall them?

[mohitjain (Mohit)]

They may not appear in a typical marketplace search, even if they’re installed. Here’s how to check definitively, and a more thorough fix for the popup.

For the Copilot extensions:

Press Cmd+Shift+P and run “Developer: Show Running Extensions”. This shows every extension currently loaded in your session. Look for anything with “copilot” in the name. You can also check on disk in Terminal:

ls ~/.cursor/extensions/ | grep -i copilot

If nothing appears in either place, the Copilot extensions aren’t the source of the popup.

For the GitHub popup — more thorough fix:

When you searched @builtin github earlier, there are actually multiple built-in GitHub extensions — “GitHub”, “GitHub Authentication”, and “GitHub Pull Requests and Issues”. All of them need to be disabled. Go back to Extensions, search @builtin github, and make sure every result is disabled.

Then clear all remaining GitHub auth state. In Terminal, run these commands:

rm -rf ~/Library/Application\ Support/Cursor/User/globalStorage/github.*
rm -rf ~/Library/Application\ Support/Cursor/User/globalStorage/vscode.github*

Restart Cursor after that.

If the popup still persists even after all built-in GitHub extensions are disabled and auth state is cleared, try launching Cursor once from Terminal with all extensions disabled to confirm it’s extension-related:

cursor --disable-extensions

If the popup stops, it confirms an extension is the source and we can narrow down which one.

For the @file issue: Please remove "git.enabled": false from your settings JSON (Cmd+Shift+P > “Preferences: Open User Settings (JSON)”) and restart Cursor. That setting was a diagnostic step that we can now rule out — it’s what’s blocking @file references from working.

[tsufleta (Tomsufle)]

Also after removing “git.enabled”: false and “cursor-retrieval.canAttemptGithubLogin”: false from the settings, prompts with file handles (to even very small basic files) do not respond. That said, simple prompts to edit files (but without ‘@file’ handles) do respond but are slow (~1m). The Network Diagnostic doesn’t show any issues. Attaching logs. Any other thoughts on troubleshooting?

cursor-output-20260423.txt (49.7 KB)

[tsufleta (Tomsufle)]

@mohitjain

They may not appear in a typical marketplace search, even if they’re installed. Here’s how to check definitively, and a more thorough fix for the popup.

For the Copilot extensions:

Press Cmd+Shift+P and run “Developer: Show Running Extensions”. This shows every extension currently loaded in your session. Look for anything with “copilot” in the name. You can also check on disk in Terminal:

ls ~/.cursor/extensions/ | grep -i copilot

If nothing appears in either place, the Copilot extensions aren’t the source of the popup.

For the GitHub popup — more thorough fix:

When you searched @builtin github earlier, there are actually multiple built-in GitHub extensions — “GitHub”, “GitHub Authentication”, and “GitHub Pull Requests and Issues”. All of them need to be disabled. Go back to Extensions, search @builtin github, and make sure every result is disabled.

Then clear all remaining GitHub auth state. In Terminal, run these commands:

rm -rf ~/Library/Application\ Support/Cursor/User/globalStorage/github.*
rm -rf ~/Library/Application\ Support/Cursor/User/globalStorage/vscode.github*

Restart Cursor after that.

If the popup still persists even after all built-in GitHub extensions are disabled and auth state is cleared, try launching Cursor once from Terminal with all extensions disabled to confirm it’s extension-related:

cursor --disable-extensions

If the popup stops, it confirms an extension is the source and we can narrow down which one.

For the @filefile issue: Please remove "git.enabled": false from your settings JSON (Cmd+Shift+P > “Preferences: Open User Settings (JSON)”) and restart Cursor. That setting was a diagnostic step that we can now rule out — it’s what’s block@fileng @file references from working.

I tried all the above. None of the previously mentioned copilot extension appear, and see screenshots for full list of running extensions. Also see screenshots that “GitHub”, “GitHub Authentication” are disabled and “GitHub Pull Requests and Issues” does not exist. I have cleared all remaining GitHub auth state. Even with starting with “cursor --disable-extensions” the dialog still appears.

I have removed “git.enabled”: false and the settings.json file is empty. Same symptoms as described in previous post.

[mohitjain (Mohit)]

Your workspace (Cursor/Epsilon/Basic) is not a git repository. The file search service needs one to resolve @file references – your logs confirm repeated “cannot index repository without Git” and “fatal: not a git repository” errors.

Fix: open Terminal and run:

cd ~/Cursor/Epsilon/Basic
git init

Then restart Cursor normally (without --disable-extensions) and test @file again. With extensions disabled, the retrieval system itself was off, so @file was expected not to work in that mode.

GitHub login dialog

Two things are contributing to this:

1. When you removed "cursor-retrieval.canAttemptGithubLogin": false from your settings (alongside "git.enabled": false), the retrieval system started attempting GitHub authentication again on startup. Add that setting back – only "git.enabled": false needed to be removed. Your settings.json should look like:

   {
   "cursor-retrieval.canAttemptGithubLogin": false
   }
   

2. Your team potentially has custom marketplace plugins configured from a private GitHub repository. Your logs show the plugin system trying to clone this repo on every launch – SSH fails, HTTPS fallback requires authentication, and that triggers the sign-in prompt. This happens outside the extension system, which is why --disable-extensions didn’t stop it.

For this part, you’ll need to check with your team admin who configured the custom marketplace. Either the repo needs to be made accessible to your GitHub account, or you’ll need a GitHub token configured for that organization.

[tsufleta (Tomsufle)]

Even after running ‘git init’, the prompt with ‘@file’ is not responding (see screenshot).

Even after adding “cursor-retrieval.canAttemptGithubLogin”: false, restarting cursor (without --disable-extensions), and supplying a token from the bitbucket repo multiple times in the dialog, the dialog still keeps appearing.

cursor-output-20260423-withCanAttempGithubLoginFalse.txt (52.1 KB)

[mohitjain (Mohit)]

Your logs show two distinct root causes.

@file hanging

The local search index is corrupted. To fix:

1. Quit Cursor completely

2. Back up first, then delete: ~/.cursor/User/workspaceStorage/0fc3aea1a23768293defdcd76c3fd9bd

3. Relaunch, open the same workspace, wait for indexing to finish, try @file again

GitHub popup

Your team’s custom marketplace plugins (starter-advanced, pep-workflow, product-docs) are trying to fetch from a private GitHub repo on every startup. The canAttemptGithubLogin setting doesn’t control this.

Fix — cache GitHub credentials so the fetch succeeds silently:

git config --global credential.helper osxkeychain
git clone 
 /tmp/test-clone

Enter your GitHub username + a Personal Access Token as the password. Once cached, the popup should stop. Delete /tmp/test-clone after.

Alternatively, ask your Cursor team admin whether those marketplace plugins are still needed.

[tsufleta (Tomsufle)]

@mohitjain : I just wanted to thank you for all the support. Quick update: after a cursor update, both problems were resolved. I suspect it was a combination of some of your suggestions, and probably clearing some sort of weird state (as I had already tried blowing up various .cursor dirs to start as clean as possible, but the update must have done something). I just wanted to acknowledge your dedication. THank you again.