Where does the bug appear (feature/product)?
Somewhere else…
Describe the Bug
I am consuming cursor-agent through ACP in HAPI, and I am seeing a failure mode where an internal model-side error appears to be surfaced only as normal agent/message text.
In one observed session, cursor-agent hit what looks like a model/resource exhaustion error, but the session/prompt JSON-RPC call returned success, no stderr error was emitted, the transport stayed open, and the session immediately returned to ready.
The only indication of failure was that the following string was appended to the end of an otherwise normal assistant text message:
Error: T: [resource_exhausted] Error
So from the ACP consumer side, the failure is indistinguishable from the assistant merely talking about an error string in normal prose.
I am not sure whether the flattening happens in cursor-agent itself, the Cursor SDK layer behind it, or an internal model adapter. From the ACP consumer side, the observable problem is that the structured failure has already been lost by the time it reaches us.
Steps to Reproduce
I do not have a minimal standalone reproducer yet, but the observed case was:
Start a cursor-agent ACP session from an ACP consumer.
Send a session/prompt request that causes the underlying model call to hit a model-side failure, in this case apparently resource_exhausted.
Observe the events returned over ACP.
In the observed session e7d9b44b on 2026-06-13, cursor-agent emitted a single agent/message text event with a body shaped like this:
"Three of the four hit Codex’s usage limit (#151, #153, #155) - no code review
delivered. Only #157 actually got reviewed. Let me pull the inline comments to
see Codex’s specific suggestions:
Error: T: [resource_exhausted] Error"
The important part is that the message contains normal assistant narrative output, followed by a blank line, followed by what looks like a stringified internal error.
The surrounding ACP behavior was:
session/prompt returned success
no JSON-RPC error response was received
no stderr error was emitted
the transport did not close
the process did not exit
a ready event followed immediately
We have also seen a similar shape in another session, b52b9117, where the appended text was:
Error: T: WritableIterable is closed
So this may not be limited to resource_exhausted.
Expected Behavior
When cursor-agent hits a non-recoverable internal model-side error during a turn, I would expect that failure to be surfaced structurally rather than appended to assistant prose.
Any of these would work from a consumer perspective:
Reject the session/prompt JSON-RPC call with an error response.
Emit a typed ACP event, for example agent/error or similar.
Write a parseable error to stderr.
At minimum, avoid appending internal runtime/model error serialization to agent/message text.
The key expectation is that an ACP consumer should not need to regex-match free-form assistant text to detect whether a model call actually failed.
A structured signal would let consumers distinguish:
completed assistant output
partial assistant output followed by model failure
assistant text that merely quotes or discusses an error
Without that structural distinction, the consumer cannot reliably tell whether the agent completed the requested work or fell over mid-turn. In HAPI’s case, the downstream UX problem is that the session can appear green/ready even though the final assistant message ended in what looks like a runtime failure.
Operating System
Windows 10/11
MacOS
Linux
Version Information
CLI Version 2026.06.11-03-15-00-241fc09
Model Auto
Subscription Tier Ultra
OS linux (x64)
Terminal tmux
Shell bash
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor