Cursor data-policy action required is lost: ErrorDetails discarded and only failed_precondition: Error reaches clients

Client or integration

Originally observed in Codex App; independently reproduced with a minimal direct HTTP request and the installed Cursor transport. Native Cursor CLI provides the control.

Provider / version / endpoint

• OpenCodex 2.52.0, verified both by ocx --version and the running proxy's /healthz.
• macOS arm64; Codex CLI 0.154.0; native Cursor CLI 2026.09.02-c22c1a3.
• POST /v1/responses → Cursor agent.v1.AgentService/Run at https://api2.cursor.sh.
• Requested cursor/claude-fable-5-1, reasoning medium; observed wire model claude-fable-5-1-thinking-medium.
• Reproduced September 13, 2026. Native Cursor and OpenCodex credentials have the same JWT subject, compared locally without disclosing either credential or subject.

Current behaviour

An account that has not acknowledged the Fable data-retention policy receives only:

stream disconnected before completion: Cursor invalid request: Cursor Connect error failed_precondition: Error

This conceals the action the user needs to take. The same exact wire model through native Cursor CLI reports:

ActionRequiredError: Review Data Policy You must acknowledge Claude Fable 5's data retention policy to use the model.

This is not merely an inference from the native CLI. A separate, isolated invocation of the installed OpenCodex transport captured the Connect end-stream error before its parser discarded the detail. The upstream error has code="failed_precondition", message="Error", and a detail of type aiserver.v1.ErrorDetails with both value (base64 protobuf) and debug representations. Relevant redacted debug fields:

{
  "error": "ERROR_MODEL_BLOCKED",
  "details": {
    "title": "Review Data Policy",
    "detail": "You must acknowledge Claude Fable 5's data retention policy to use the model.",
    "isRetryable": false,
    "showRequestId": false,
    "analyticsMetadata": { "actionRequired": "config" }
  },
  "isExpected": true
}

The server also supplies policy-view and consent-action buttons; they are omitted here. No consent was accepted and no policy or account setting was changed during diagnosis.

Minimal reproduction

Prerequisite: an authenticated Cursor account for which the Fable data-policy acknowledgement remains outstanding.

curl -N http://127.0.0.1:10100/v1/responses \
  -H 'Content-Type: application/json' \
  --data-binary '{"model":"cursor/claude-fable-5-1","input":"Reply with exactly CURSOR_PROBE_OK. Do not use tools.","reasoning":{"effort":"medium"},"stream":true}'

Native control, from an empty trusted scratch directory:

cursor-agent --print --mode ask --trust \
  --model claude-fable-5-1-thinking-medium \
  --output-format json \
  'Reply with exactly CURSOR_PROBE_OK. Do not use tools.'

Paired results using the same account and synthetic prompt:

The minimal failing proxy request had one raw message, zero tools, one root blob, 58 root bytes, and no checkpoint. It received 13 frames, including interactionUpdate:stepCompleted, and failed with zero output tokens. This rules out a large tool catalog or accumulated conversation history as necessary triggers for this reproduction. stepCompleted preceding the error does not establish schema drift.

HTTP status is 200 because this is streaming; the terminal SSE event is response.failed, with error.type and error.code both invalid_request_error. OpenCodex's usage record classifies the failure as 400. The minimal request made one upstream attempt and did not retry.

Expected behaviour

Preserve a bounded, sanitized actionable explanation from the structured Cursor error: the model is blocked pending the user's review of its data-retention policy. Keep the failure non-retryable and direct the user to Cursor's own policy-review flow. Do not silently consent, change plans, or substitute a model.

Implementation evidence / suggested scope

parseConnectEndStreamError reads only error.code and error.message; error.details is ignored. The installed 2.52.0 source has the same implementation.

classifyCursorError already maps failed_precondition to a non-retryable invalid request. This report is not requesting a blanket status/retry change. Its plan-gating comment should not be treated as an exhaustive diagnosis: the captured rejection is a policy-consent gate.

The fix should decode the recognized aiserver.v1.ErrorDetails protobuf value, whitelist and sanitize user-facing fields, and preserve actionable details through the adapter and SSE error path. Unknown or malformed details should retain the current safe fallback. The Connect specification says clients must not depend on the optional debug representation, so copying debug into errors alone would not be a robust fix. Regression coverage should include the policy gate, unknown/malformed details, redaction, and unchanged non-retryable behaviour.

Related evidence and limits

• Connect error detail specification.
• OpenCodex Cursor adapter documentation.
• pi-cursor #29 reports the same Fable error signature but suspects protocol drift. This report provides direct policy-gate evidence for this account, not proof that every occurrence has the same cause.
• OpenCodex #2769 addressed classified error status propagation; this is the separate loss of structured upstream action-required details.
• Historical local usage records show one Fable conversation with 13 successful requests followed by six failures with this signature. The triggering policy-state transition and the runtime version at that earlier moment were not established; the current 2.52.0 minimal reproduction above is the submission's primary evidence.
• Post-consent success was intentionally not tested. The evidence proves the current gate and lost explanation, not when it first appeared.

Checks

• Searched existing provider issues and PRs for failed_precondition, ActionRequired, Review Data Policy, and Cursor consent handling.
• Requests, responses, and diagnostic excerpts are redacted; no credentials, JWT subjects, account identifiers, original prompts, or original tool results are included.
• Expected behaviour is based on a captured upstream structured error, a native-client control, and the Connect specification.