- Changed `run_id` to `request_id` in `CursorParent` struct for clarity.
- Enhanced the `prepare` function to handle parent requests asynchronously, ensuring proper error handling for active runs.
- Updated database interactions to include `cursor_request_id` for better tracking of requests.
- Added tests to verify the behavior of reused cursor request IDs and their mapping to distinct executions.
The Shell tool schema lacked a `required_permissions` parameter,
preventing models from requesting elevated sandbox permissions
(e.g. unrestricted network access). This adds:
- `required_permissions` parameter to the Shell tool schema in tools.json
- Sandboxing instructions in the Shell tool description so models know
when and how to request permissions
- `shell_sandbox_policy()` in request.rs to map the parameter to the
protobuf `SandboxPolicy.requested_sandbox_policy` field
Co-authored-by: Cursor <cursoragent@cursor.com>
trimDanglingAssistantToolCalls in the provider router held the same
consecutive-tool-message assumption as the replay projector: when a
model emits function_call items before explanation text within one
response (e.g. gpt-5.3-codex-spark), the sanitized sequence becomes
assistant[tool_call] -> assistant[text] -> tool[result] and responded
calls were stripped at the provider boundary even though the projector
already replayed them correctly. The orphan tool result then forced the
Responses adapter to synthesize a placeholder function_call with empty
arguments, degrading the arguments the model sees on in-loop requests.
Widen the response collection window to skip interleaved plain
assistant text messages and drop orphan tool results, mirroring the
projector fix.
trimReplayDanglingAssistantToolCalls only collected tool results that
immediately followed the assistant tool-call message. Models such as
gpt-5.3-codex-spark may emit the function_call item before the
explanation text within one response, so history replay order becomes
assistant[tool_call] -> assistant[text] -> tool[result]. The call was
misjudged as dangling and stripped while the tool result survived,
producing a function_call_output without a matching function_call that
the Responses API rejects with 400.
- widen the response collection window to skip interleaved plain
assistant text messages, and drop orphan tool results in the same pass
- synthesize a placeholder function_call (or drop the output when the
tool name is unknown) in normalizeOpenAIResponsesInput so conversations
already persisted with corrupted history can resume
leookun