Can't change Cloud Agents team settings — backend rejects own stored no-ZDR consent ("noZdrModelConsents cannot be set via updateTeamAdminSettings")

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Where does the bug appear: Dashboard — Cloud Agents page (path: dashboard/cloud-agents)

Any toggle in the Cloud Agents team settings (e.g. “Enable self-hosted pool”, “Require Self-Hosted Pool”) instantly reverts. The underlying POST /api/dashboard/update-team-background-agent-settings returns 400:

{“error”:{“message”:“Error”,“details”:[{“error”:“ERROR_BAD_REQUEST”,“details”:{“title”:“Bad Request”,“detail”:“noZdrModelConsents cannot be set via updateTeamAdminSettings; use the no-ZDR consent endpoint”,“isRetryable”:false}}]}}

The request body does not contain noZdrModelConsents (verified by replaying a minimal body of {“teamId”:…,“settings”:{“allowPrivateWorkers”:true}} — same 400). The server appears to merge the team’s stored admin settings (which contain a noZdrModelConsents entry from a previously accepted Fable data-retention consent) into its internal updateTeamAdminSettings call, then rejects its own merge. Result: any team that has ever accepted the Fable no-ZDR consent can no longer modify Cloud Agents team settings via the dashboard.

Operating System: macOS (dashboard bug — browser-independent, reproduced via curl)

Does this stop you from using Cursor: No, but it blocks enabling self-hosted/private workers entirely without the API workaround.

Workaround found: Atomically: (1) set-team-no-zdr-model-consent with enabled:false (deletes the stored consent record), (2) the settings update now returns 200, (3) re-grant consent with enabled:true. This confirms the stored consent record itself is what trips the guard — including a freshly written one, so the bug recurs on every subsequent settings change.

Steps to Reproduce

  1. As a team admin, accept the Fable no-ZDR consent (use Fable 5 once; modelId: claude-fable-5, consentVersion: fable-data-retention-v1)
  2. Go to the dashboard Cloud Agents page (path: dashboard/cloud-agents) → flip “Enable self-hosted pool”
  3. Toggle reverts; Network tab shows the 400 above on update-team-background-agent-settings
  4. Note the rejection persists even after re-asserting consent via POST /api/dashboard/set-team-no-zdr-model-consent (200, {“consented”:true})

Operating System

MacOS

Version Information

N/A — this is a server-side dashboard/backend bug (Cloud Agents page, path dashboard/cloud-agents), not specific to a Cursor IDE/CLI build. It is browser-independent and reproduced via curl against the dashboard API.

Does this stop you from using Cursor

No - Cursor works, but with this issue

good report, just have to wait until the team handles that, thanks for flagging

Thanks for the detailed report - your analysis is spot on. I’ve dug into this and can confirm it’s a regression on our side: once a team has accepted the Fable no-ZDR consent, the Cloud Agents settings save carries that stored consent back into the admin-settings update, which then gets rejected. So the save fails even though your own request never included it.

Two notes:

  • This isn’t limited to the Cloud Agents page. The same pattern affects the Shared Conversations and Shared Canvas team settings for any team in this state, so you may run into it there too.
  • Your workaround (temporarily revoking the no-ZDR consent, saving the setting, then re-granting) is exactly right and safe to use for now. As you noted, you’ll need to repeat it per change until the fix lands.

We’ve identified the root cause and are getting it fixed. I’ll follow up here once it ships so you can drop the workaround.