Remove approval prompt from dotnet tool exec - running dnx is implicit approval

[Copilot]

Remove approval prompt from dotnet tool exec - running dnx is implicit approval

dotnet tool exec (dnx) previously prompted users to confirm tool downloads, blocking LLMs, scripts, and automation. This PR removes the approval prompt entirely - running dnx is now treated as implicit approval.

Changes

Removed approval check

• Deleted UserAgreedToRunFromSource() method that prompted for confirmation
• Removed the interactive prompt logic that asked users to confirm tool download
• Removed unused ERROR_CANCELLED constant and _interactive field
• Removed unused resource strings: ToolDownloadConfirmationPrompt, ToolDownloadCanceled, ToolDownloadNeedsConfirmation
• Updated all xlf translation files to remove these unused strings
• Tools are now downloaded immediately if not already cached, without any prompts

// Before: prompted for approval
if (!UserAgreedToRunFromSource(packageId, bestVersion, packageSource))
{
    // Show error and exit
}

// After: no prompt, just download
// Tool is downloaded directly if not cached
toolPackage = _toolPackageDownloader.InstallPackage(...)

Rationale

When a user runs dotnet tool exec <package>, they are explicitly requesting to execute that package - this is the approval. The previous confirmation prompt:

• Blocked non-interactive scenarios (LLMs, scripts, CI)
• Provided no security benefit (user already made the decision by running the command)
• Created unnecessary friction

This aligns with the philosophy of tools like npx where running the command implies consent to download and execute the requested package.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Enable first-class non-interactive mode for the CLI</issue_title>
<issue_description>I'm a fan of dnx but have found that there are some usability issues with LLMs. The basic problem is that it requires an interative response, which causes a non-interactive user to just hang. I have noticed this a couple times recently. However, I was writing a skill that uses a tool and wanted to use dnx. However, using dnx is challenging. We need good guidance for this and to consider product changes. For now I'm saying, always use dnx -y dotnet-inspect -- [args].

There are two cases where an LLM might hit an interactive prompt:

• First install
• New version available

The second point is the most challenging. A session could be moving forward using a tool and then a new version is published to nuget.org, dnx notices this, and then blocks the LLM (or other tool) with an interactive prompt. This also means that dnx isn't a great choice for scripts, as-is.

Here's what I see.

DNX:

NPM:

This is from npm exec help:

  If any requested packages are not present in the local project
  dependencies, then a prompt is printed, which can be suppressed by
  providing either --yes or --no. When standard input is not a TTY or a CI
  environment is detected, --yes is assumed. The requested packages are
  installed to a folder in the npm cache, which is added to the PATH
  environment variable in the executed process.

I asked Copilot to thoroughly test this:

I don't think that stdin is excellent solution. It's a pattern to enable. I'd like to see the dnx offer the same model as npx and also offer an ENV variable to make a whole session safe. That would mean install the package if not available and DON'T install a new package if one is available unless asked to.

Side note: We should make it easy to clear the dnx cache. This made testing a bit awkward.

I sometimes see the first-run experience in CP-CLI/CC. This is harmful, in the sense that it is wasted tokens and the person we wanted to see the first-run experience doesn't. Assuming we a DOTNET_INTERACTIVE=false, then I'd skip the first-run message as well. There may be other experiences we need to consider. That's why the title is about the scenario not dnx in particular.</issue_description>

<agent_instructions>Can you remove the requirement in dotnet tool exec that we request permission when we are running in non-interactive mode only? That would automatically approve in those situations.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@baronfel > dnx interactive prompts

We actually are free to remove the interactive yes/no prompt - we just haven't kicked off that agent run yet. We should just do that.

dnx cache clear

This is just the nuget cache - users are free to clear it at their whim via dotnet nuget locals global-packages --clear.

first-run experience showing

Agreed, we have all the puzzle pieces in place to prevent this too. The LLM heuristic we have is currently only being applied to telemetry reporting, but it makes perfect sense to make it one more input into the "should we be emitting first-use data" calculations.

@richlander Sounds great.

The more we can elevate high value commands to high-value CLI commands, the better. Clearly, the nuget cache commands are an advanced scenario as they are currently exposed.

It would be great if there was a way to get more information about dnx tools, just like the dotnet tool commands. Dnx to me means high convenience not mysterious.</comment_new>

• Fixes Enable first-class non-interactive mode for the CLI #52759

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[baronfel]

@copilot the entire "check for approval" concept is unnecessary. The fix here should be to remove the entire "prompt" check - the usage of dnx is the approval.

[Copilot]

@copilot the entire "check for approval" concept is unnecessary. The fix here should be to remove the entire "prompt" check - the usage of dnx is the approval.

Agreed - I've removed the entire approval check. Running dnx is now implicit approval to download and execute the tool. Changes in commit 0624225.

[dsplaisted]

I'm OK with this, but AFAIK npm does prompt you when in interactive mode. I'm not sure everyone was fully agreed to remove the prompt entirely.

[dsplaisted]

@copilot Also remove the CliCommandStrings that have been removed from the resources. You'll probably need to do a build to update the xlf files too.

[Copilot]

Removed the unused resource strings (ToolDownloadConfirmationPrompt, ToolDownloadCanceled, ToolDownloadNeedsConfirmation) and updated all xlf files using /t:UpdateXlf. Changes in commit 4744ace.

[Copilot]

I'm OK with this, but AFAIK npm does prompt you when in interactive mode. I'm not sure everyone was fully agreed to remove the prompt entirely.

You're right that npm does prompt in interactive mode. However, @baronfel's guidance was that for dnx, the act of running the command itself is the approval - similar to how dotnet tool run works for manifest-based tools. The rationale is that dotnet tool exec <package> is an explicit request to execute that specific package, so an additional confirmation adds friction without security benefit.

If the team prefers npm's behavior (prompt in interactive, auto-accept in non-interactive), I can restore the prompt logic but fix it to properly detect non-interactive scenarios. Let me know which approach you'd prefer.

[dsplaisted]

@copilot My comments about the design were for @baronfel, not for you :-)