Workspace agents fail with missing authorization header on macOS 3.14.7

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor IDE workspace agents have failed for more than 24 hours on macOS ARM64. The desktop UI shows my Ultra account as logged in.

What works:

  • Cursor CLI login and an actual agent request from a workspace
  • Cursor desktop Agents Window with No Repo (returned CLEAN_DESKTOP_OK)

What fails:

  • Cursor desktop Agents Window as soon as any folder is opened as a workspace
  • Reproduces with both my normal Google Drive workspace and a completely empty local folder

Workspace-agent logs show:

  • No authorization header found
  • ERROR_UNAUTHORIZED
  • ERROR_NOT_LOGGED_IN
  • Authentication error
  • Connect/gRPC code 16 (Unauthenticated)

Steps to Reproduce

  1. Launch Cursor 3.14.7 on macOS ARM64 and sign in.
  2. Open the Agents Window with No Repo.
  3. Send a minimal prompt. It succeeds.
  4. Open any folder as a workspace. I tested both my normal workspace and a new empty local folder under /private/tmp.
  5. Send the same minimal prompt.
  6. The request fails with “An unexpected error occurred” and a Request ID.
  7. Open the Cursor logs. The workspace-agent process reports “No authorization header found” and Unauthenticated/code 16.

The failure persists after:

  • Restarting Cursor and the Mac
  • Switching between tethering and home internet
  • Trying different models
  • Reinstalling the official Cursor 3.14.7 ARM64 build
  • Moving ~/Library/Application Support/Cursor to a reversible backup for a clean app-data reset
  • Logging out of the desktop app and signing in again through the browser
  • Testing both HTTP/2 and HTTP/1.1 with a full restart

Expected Behavior

A workspace-backed desktop agent should receive the same signed-in authorization as No Repo and Cursor CLI, and should complete the prompt instead of failing as unauthenticated.

Operating System

MacOS

Version Information

Cursor IDE
Version: 3.14.7
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Architecture: arm64
Build: official ARM64, code-signed and notarized
macOS: 26.5.2

For AI issues: which model did you use?

Multiple models tested; the same failure occurs regardless of model. The No Repo control request succeeds.

For AI issues: add Request ID with privacy disabled

8b46223d-a0e4-4020-8a04-e0b4fb0c0b82 — reinstall with existing app data
43c762dc-05fe-44fc-9fc1-871e0627ef4b — clean app data, normal workspace
dabe3b76-3304-4611-8297-75c8e079e6a6 — clean app data, empty local workspace
50ae92f8-d4e6-4af2-9ed6-2595763900c6 — after full restart
0612ebd1-539f-4654-96da-7e983de4acdc — after desktop reauthentication
a672ee9c-2648-4d1b-9449-440a5fdb7721 — after HTTP/1.1 and restart

Additional Information

This is isolated to the desktop workspace-agent path:

  • The same account and folders work through Cursor CLI.
  • No Repo works in the desktop Agents Window.
  • An empty local folder fails exactly like the normal workspace, so this is not specific to Google Drive, repository size, or workspace files.
  • Claude Code and Codex work normally on the same Mac and networks.
  • After the clean reset, the newly generated app-data directory quickly grew to about 13 GB, almost entirely under snapshots. The original roughly 10 GB app-data directory remains separately backed up and can be restored.
  • Cursor status showed systems operational during testing.

Cursor IDE workspace agents are unusable. Cursor CLI is only a temporary workaround.

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Hey there,

What you’re seeing isn’t caused by anything in your setup. On the current stable build, a workspace window can start agent requests before the auth token is attached, so they go out without an Authorization header and fail. Opening from the Agents Window / No Repo path uses a different route, which is why that still works.

Workaround that usually unblocks without a full restart: with the broken workspace window focused, run Developer: Reload Window from the Command Palette (Cmd+Shift+P). A full quit/reopen can hit the same race again.

We’ve let the team know - this is an issue we’re tracking, and a fix is already in newer builds that haven’t reached your stable channel yet. I’ll post here when there’s an update you can install.

If Reload Window doesn’t stick, reply with whether it helped even briefly, and your exact Cursor version from Cursor → About Cursor.

7

Thanks, Mohit. I tested Developer: Reload Window with the broken empty
local workspace focused.

The window UI reloaded successfully, but the workspace agent still
failed immediately on the very first minimal request, so it did not
help even briefly.

Exact environment:

  • Cursor version: 3.14.7
  • Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
  • Architecture: arm64
  • macOS: 26.5.2

New Request ID after Developer: Reload Window:

  • 8d194915-6f4c-4d8b-83ac-92cc0ea40c94

The request used Auto in the empty local workspace
cursor-local-workspace-20260803 and failed immediately. The No Repo
path remains the working control path from my earlier test.

Since the workaround does not unblock this installation, should I wait
for the fixed stable build, or is there a newer signed build/channel
you recommend testing now?

8

Thanks for testing that so carefully - really helpful that Reload Window didn’t help even briefly, and that you’re still on 3.14.7.

That workaround only helps when the window re-attaches the auth token on reload. On some installs it hits the same race again immediately, so the workspace path stays stuck. Your No Repo and CLI controls still match what we’d expect.

Best path for now: keep using Cursor CLI (and Agents Window / No Repo when that works) until a fixed build reaches the normal stable update channel. Updating within the current 3.14 line won’t include this fix, and I wouldn’t chase a separate pre-release build for this. I’ll post here as soon as there’s a stable update you can install that addresses it.