Error_bad_request

[davidktx]

Describe the Bug

ERROR_BAD_REQUEST when I submit a prompt.

Did all this and it did not solve the problem:

Understood—sorry to hear about the “ERROR_BAD_REQUEST” issue in your Cursor window for the Texas project. This looks like an internal error in Cursor’s AI/transport layer (likely related to its Grok integration or a similar feature, based on the stack trace referencing $endAiConnectTransportReportError). It’s not uncommon for Cursor/VS Code-based tools to hit this with bad network requests, corrupted cache, or invalid arguments in AI chats/queries. The good news is we can try targeted fixes without deleting your entire Cursor config file (which would reset extensions, settings, etc.). I’ll walk you through steps to troubleshoot and resolve it step by step— these are safe, non-destructive, and based on common fixes for similar Cursor/VS Code errors. If something doesn’t work, we can escalate.

Quick Diagnosis

• Likely Causes: Invalid or corrupted request in the AI chat/tooling (e.g., a malformed query, network hiccup, or state issue specific to that window). The [invalid_argument] points to something like a bad parameter in an API call Cursor is making behind the scenes. Since it’s project-specific (happens in Texas but not here), it could be tied to workspace state, extensions, or even a .cursor folder in the Texas repo.
• Why Not Full Config Delete?: That wipes global settings (in ~/.cursor or %APPDATA%/Cursor on Windows). We’ll target local/per-window fixes first.

Step-by-Step Fixes (Try in Order)

1. Restart the Affected Window (Quickest Fix):

   • Close the Cursor window/tab for the Texas project (File > Close Folder or just quit that instance).
   • Reopen it by going to File > Open Folder and selecting /home/david/Documents/GitHub/gmm.states.tx.
   • Test a request (e.g., AI chat or code gen). If it works, great— this clears temporary session state without touching configs.
   • Why? The error is in the “workbench” (UI) layer, and restarting flushes transient errors.

2. Clear Cursor’s Local Workspace Cache (Project-Specific):

   • In the Texas project window, open the Command Palette (Ctrl+Shift+P or Cmd+Shift+P on Mac).
   • Type and run “Developer: Reload Window” (this reloads without closing).
   • If that doesn’t help, run “Clear Editor History” and “Clear Recently Opened” from the palette to flush local state.
   • Alternatively, close Cursor, then delete the project-specific cache: Run this in your terminal (from any dir):

     rm -rf ~/Documents/GitHub/gmm.states.tx/.cursor/cache/*
     

     (This clears only the Texas project’s AI cache—safe, as it’s auto-regenerated.)
   • Reopen and test.

3. Check for Extension Conflicts or Updates:

   • In Cursor, go to Extensions view (Ctrl+Shift+X).
   • Search for any AI-related extensions (e.g., built-in Grok or others) and disable/re-enable them.
   • Check for Cursor updates: Help > Check for Updates. If available, update and restart.
   • If you have custom extensions, try disabling all non-essentials and test.

4. Network/Proxy Check (If It’s a Connection Issue):

   • Ensure your internet is stable—no VPN/proxy interfering? The stack trace mentions “onmessage” which could be WebSocket-related.
   • In Cursor settings (File > Preferences > Settings), search for “proxy” and clear any if not needed.
   • Test by running a simple AI query in a new, empty Cursor window (not tied to a project) to isolate if it’s truly project-specific.

5. Selective Config Clear (Last Resort Before Full Delete):

   • Close all Cursor instances.
   • Backup your config first: cp ~/.cursor/settings.json ~/.cursor/settings.json.bak
   • Delete only the AI/transport-related cache:
   • rm -rf ~/.cursor/User/globalStorage/* (this clears stored state without wiping settings).
   • Restart Cursor and test the Texas project.
   • If it persists, we might need to look at logs: Help > Toggle Developer Tools, reproduce the error, and check the Console tab for more details (share if comfortable).

If None of This Works

• It could be a bug in Cursor’s version—check their GitHub issues (search for “ConnectError invalid_argument”) or forums.
• As a workaround, open the Texas project in a plain VS Code instance (not Cursor) for now, or use Cursor’s web version if available.
• If it’s a file causing it (e.g., a corrupted .cursor or .vscode file in Texas), try: rm -rf /home/david/Documents/GitHub/gmm.states.tx/.cursor and rm -rf /home/david/Documents/GitHub/gmm.states.tx/.vscode—then reopen.

Test after each step, and let me know what happens (e.g., does the error change?). If it’s still stuck, we can dig deeper or I can suggest reporting it to Cursor support. In the meantime, since the shell is in gmm.mapserver, I can help with tasks here or switch to Texas if needed (just confirm the path, e.g., cd to gmm.states.tx).

Steps to Reproduce

Just submit prompts until it happens. About every 16 hours of use.

Expected Behavior

Can no longer submit prompts in this project

Screenshots / Screen Recordings

Operating System

Linux

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.2.4
VSCode Version: 1.99.3
Commit: a8e95743c5268be73767c46944a71f4465d05c90
Date: 2025-07-10T16:59:43.242Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Linux x64 6.11.0-29-generic

Additional Information

This is the only thing that fixes the problem:

rm -rfi ~/.cursor ~/.config/Cursor/

Does this stop you from using Cursor

Yes - Cursor is unusable