Summary

Add a --fail-on-prompt mode that causes azd to fail immediately with a clear, actionable error whenever any interactive prompt is encountered, regardless of whether a default value exists. This should be the automatic default behavior when azd detects it is being called by an LLM agent or serving MCP tool requests.

The Problem

The current --no-prompt flag silently uses default values when available. For LLM agents and automated pipelines, this masks decisions — the tool proceeds with a default that may not be what was intended, and the caller gets no signal that a choice was made on their behalf.

For example, when an LLM agent runs azd up --no-prompt:

• Subscription: azd silently picks the first subscription in the list — which might be a sandbox, not production
• Location: azd picks a default region that may be far from the user's target
• Resource group: Default naming may conflict with existing resources
• Destructive confirmations: --no-prompt auto-confirms deletions without the agent knowing

The agent never learns that these decisions were made. The user gets a deployment in the wrong subscription/region with no indication of why.

Why This Matters

azd already auto-detects LLM agents (Claude Code, Copilot CLI, Gemini, OpenCode) via agentdetect.IsRunningInAgent() and auto-enables --no-prompt. This means every LLM agent session today is silently using defaults. The agent can't distinguish between "the user provided this value" and "azd guessed this value."

With fail-on-prompt behavior, the error message tells the agent exactly what's needed:

Error: prompt required: "Select an Azure subscription" — provide via --subscription flag

The LLM catches the error, asks the user (or infers from context), and retries with the correct flag. That's a better interaction loop — the LLM is forced to be explicit, and the user gets the deployment they actually wanted.

For MCP tool integrations, this is even more important: MCP tool descriptions document required parameters, and the LLM provides them upfront. Fail-fast errors are the standard feedback mechanism.

Recommended Approach

Path 1: Auto-enable in MCP server (primary)

The MCP server (internal/grpcserver/) already knows it's serving an LLM. MCP tool invocations should default to fail-on-prompt behavior. The LLM never needs to know about a flag — the MCP tool descriptions document required parameters, and error responses tell the LLM what's missing. This is the most natural integration point since MCP is the structured API surface for LLM agents.

Path 2: Auto-enable via agent detection (secondary)

For direct CLI invocations by agents (not via MCP), change the agent auto-detection behavior in ParseGlobalFlags() from enabling --no-prompt (silent defaults) to enabling --fail-on-prompt (fail-fast with helpful errors). The LLM doesn't choose the flag — azd chooses it automatically. Error-driven discovery is already how LLM agents work with most CLI tools: the error message IS the documentation.

Path 3: Explicit flag for power users

Expose --fail-on-prompt as an explicit CLI flag for human power users in CI who want deterministic builds with no silent defaults. This is the escape hatch for users who want strict mode without agent detection.

Implementation Notes

• When active, askOneNoPrompt should always return an error listing the prompt question, even if a default exists
• Error messages should suggest the appropriate CLI flag/arg to provide the value non-interactively (e.g., use --subscription to specify)
• The MCP tool schemas should document which parameters are required vs optional
• Consider a transitional period where agent-detected mode logs warnings ("using default subscription X") before switching to fail-fast