feat(ai): input editing during tool approval

[Arron-Stothart]

Background

Allow users to review and modify tool inputs before execution to support Human-in-the-loop flows.

Summary

• Adds override.input field to ToolApprovalResponse
• Adds allowsInputEditing option to tool definitions (opt-in)
• Adds allowsInputEditing to ToolApprovalRequest so UI can show/hide edit controls
• Adds allowsInputEditing to ToolApprovalRequest
• Creates validateAndApplyToolInputOverrides()
• Updates generateText and streamText to validate and apply modified inputs
• Updates UIToolInvocation, DynamicToolUIPart to include override in approval
• Updates ChatAddToolApproveResponseFunction to accept override parameter

Example

Discussion

In this PR, the LLM sees the original tool call but the result of the modified execution. This causes confusion and poor traceability. We shouldn't overwrite message history (database integrity) and need immediate execution (user's intent shouldn't require LLM retry), some ideas:

1. Return execution-denied for original, create new tool-call with modified input and approve/execute.
2. Stop filtering out tool-approval-response, and update providers to access override directly from it.
3. Add a tool-input-override part to tool messages for clearer traceability, separating the override info from tool-approval-response

When an input override is provided for a denied error, should this be shown to the LLM?

This functionality is possible currently by creating a ‘request-input’ tool, using addToolOutput, then having the LLM relay this output into the input of the tool we intended to execute.

Overridden inputs are not validated against the tool schema before execution (neither are tool call inputs from messages), but since overrides are more likely to be end-user input, should we reconsider?

allowsInputEditing is currently checked against the approval request in messages (matching how needsApproval is handled). Should we also check the current tool definition, allowing developers to withdraw editing capability for pending approvals?

Changes required since introduction of strict mode?

Manual Verification

• run examples/ai-core/src/generate-text/openai-tool-approval.ts
• run UI test next-openai http://localhost:3000/test-tool-approval

Checklist

• Tests have been added / updated (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)
• A patch changeset for relevant packages has been added (for bug fixes / features - run pnpm changeset in the project root)
• I have reviewed this pull request (self-review)

Future Work

• Expose tool input schema for client-side validation

Related Issues

• Tool Execution Approval Custom Input #10702
• Handling `part.input` for `addToolResult` in HITL Scenario with Enum Options #8326