Auto approve immediately if only warning blocked it

[Daniel Imms (Tyriar)]

Fixes #275312

[Copilot]

Pull request overview

This PR implements a feature to auto-approve terminal commands immediately after the user accepts the auto-approve warning, if the command would have been auto-approved based on existing rules. Previously, users had to accept the warning and then still manually confirm or set up rules for the command.

Key Changes:

• Splits auto-approval logic to distinguish between commands that would be auto-approved by rules vs. commands that are actually auto-approved (accounting for warning acceptance state)
• Passes autoApproveInfo to confirmation widget even when warning hasn't been accepted yet, enabling immediate approval after warning acceptance
• Updates confirmation widget to check for autoApproveInfo presence to determine whether to auto-approve after warning acceptance

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/vs/workbench/contrib/terminalContrib/chatAgentTools/browser/tools/runInTerminalTool.ts	Refactors auto-approval logic to separate "would be auto-approved" from "is auto-approved", and sets autoApproveInfo for commands that would be auto-approved even if warning not yet accepted
src/vs/workbench/contrib/chat/browser/widget/chatContentParts/toolInvocationParts/chatTerminalToolConfirmationSubPart.ts	Changes confirmation widget logic to check autoApproveInfo instead of terminalCustomActions to determine whether to auto-approve after warning acceptance
src/vs/workbench/contrib/terminalContrib/chatAgentTools/test/electron-browser/runInTerminalTool.test.ts	Adds test case to verify autoApproveInfo is set for commands that would be auto-approved even when warning hasn't been accepted

Comments suppressed due to low confidence (1)

src/vs/workbench/contrib/chat/browser/widget/chatContentParts/toolInvocationParts/chatTerminalToolConfirmationSubPart.ts:250

• Missing fallback case when neither autoApproveInfo nor terminalCustomActions are present. If both conditions are false, doComplete remains true but toolConfirmKind stays as ToolConfirmKind.Denied (from line 219), causing the command to be denied. The original logic would auto-approve when there were no custom actions. Consider adding an else clause to handle the case where both autoApproveInfo is falsy and terminalCustomActions is falsy, to either set doComplete to false or set toolConfirmKind appropriately.

							if (terminalData.autoApproveInfo) {
								toolConfirmKind = ToolConfirmKind.UserAction;
							}
							// If this would not have been auto approved, enable the options and
							// do not complete
							else if (terminalCustomActions) {
								for (const action of terminalCustomActions) {
									if (!(action instanceof Separator)) {
										action.disabled = false;
									}
								}

								confirmWidget.updateButtons(this._createButtons(terminalCustomActions));
								doComplete = false;
							}