# ACP: Error responses not being passed through correct error channels **URL:** \ **Category:** Bug Reports\ **Tags:** cli, acp\ **Created:** [June 13, 2026, 9:30pm UTC](https://forum.cursor.com/t/acp-error-responses-not-being-passed-through-correct-error-channels/163218 "2026-06-13T21:30:42Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![gavinc](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/gavinc/32/15364_2.png) [@gavinc](https://forum.cursor.com/u/gavinc)\ **Post date:** [June 13, 2026, 9:30pm UTC](https://forum.cursor.com/t/acp-error-responses-not-being-passed-through-correct-error-channels/163218/1 "2026-06-13T21:30:42Z")
### 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 ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [June 15, 2026, 10:28am UTC](https://forum.cursor.com/t/acp-error-responses-not-being-passed-through-correct-error-channels/163218/5 "2026-06-15T10:28:24Z")
Hey @gavinc! I think you’re right, and this is pretty clunky. The protocol has the primitives to do this properly. Shared with the team! Thanks for the detailed report.