Hey Cursor team!
As always thanks for amazing Cursor!
Today I’ve found strange issue, for me it looks like on the bound of LLM and cursor-agent.
What did I see - I’ve made command in chat, during the answer gpt 5.5 decided to call sub-agent for additional research in project. But could not take the answer of sub-agent - the error occurs he said, in spite of that I saw a huge correct sub-agent answer by my own eyes!
I can provide additional screenshots (sorry its Russian lang there but I will explain everything if needed. Also I have transcripts and Langfuse traces for more deep investigation.
Version: 3.2.16
VSCode Version: 1.105.1
Commit: 3e548838cf824b70851dd3ef27d0c6aae371b3f0
Date: 2026-04-28T21:07:47.682Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.0-23-generic
Model: gpt 5.5
I’ve asked Cursor what happens, we together tried to investigate the problem. U can see our reasons here:
# Bug: Misleading error from `updateCurrentStep` causes subagent to drop substantive output
## Facts
- Subagent (type=`explore`) invoked the internal tool `updateCurrentStep` with empty input `{}` twice during its lifecycle: at the start and again in the final turn that also contained the substantive report text.
- The tool returned an error which the model paraphrased as "JSON parse error".
- After receiving that error in the final turn, the model emitted a follow-up assistant message with no tool_use, containing only a meta-note: "could not send via updateCurrentStep, the substantive part is above".
- Because that follow-up message had no tool_use, the subagent loop terminated and that message was returned to the parent as the subagent's result. The substantive report (in the previous assistant turn) never reached the parent.
## Root cause
The error returned by `updateCurrentStep` is non-actionable. Empty `{}` is valid JSON, so "JSON parse error" mislabels the actual problem (schema validation: required parameter missing). With no actionable signal, the LLM did not retry with corrected arguments and instead degraded into a "report failure to user" path, producing a final message that does not include the work product.
## Effect
- Substantive subagent output is silently lost across the subagent → parent boundary.
- Parent receives only the meta-failure note. From the user's point of view, the subagent appears to have failed despite having actually completed the work.
## Requested fix
Return a proper schema-validation error from `updateCurrentStep` (and any similarly-validated internal tools), e.g.:
Invalid input for updateCurrentStep: missing required parameter `step` (string).
A descriptive, schema-aware error gives the LLM a direct path to recover (retry with the correct field) instead of falling back to a meta-message that destroys the substantive output.
## Notes
- The empty `{}` itself is an LLM mistake (it populated other tools' inputs correctly in the same turn). That is not in scope here. The actionable, programmatic part is the misleading error text, which is what turns a recoverable LLM mistake into a lost result.
- Repro artifact available: subagent transcript with two `updateCurrentStep` calls (`input: {}`) and the resulting final meta-message.
