Problem
Resource commands declared with WithHttpCommand and WithProcessCommand typically gather user input through IInteractionService.PromptInputAsync inside their PrepareRequest / argument-building callbacks. That service is only wired up to the dashboard UI, so the commands cannot be invoked from the Aspire CLI:
$ aspire resource weather-hosted-agent weather-hosted-agent-http-http-post-/responses
❌ Failed to execute command 'weather-hosted-agent-http-http-post-/responses' on resource 'weather-hosted-agent':
InteractionService is not available because the dashboard is not enabled or because this command is running in
non-interactive CLI mode.
Compare with the prompt agent's send-message command, which declares argumentInputs on the command itself. The CLI surfaces those as flags and the command runs fine non-interactively:
$ aspire resource joker-agent send-message --message "Tell me a joke"
✅ Command 'send-message' executed successfully on resource 'joker-agent'.
Why did the distributed system break up with its database? Because it couldn't handle the commitment!
Concrete example
The Foundry hosted-agent Send Message command (added in HostedAgentBuilderExtension.cs) uses WithHttpCommand with an interactive PromptInputAsync to collect the message body. It works great in the dashboard but is unusable from the CLI / scripts / agents.
Proposal
Allow WithHttpCommand and WithProcessCommand to declare typed argumentInputs (the same shape that resource commands already use), so the CLI can collect values via flags and pass them to the PrepareRequest (HTTP) or argument-builder (process) callback. The dashboard would continue to render those argument inputs as a form, and the CLI would surface them as --<name> <value> flags. Implementations using IInteractionService would still work, but the CLI path would no longer require it.
This would give CLI/automation parity for the auto-generated hosted-agent Send Message command and any other WithHttpCommand / WithProcessCommand usage.
Problem
Resource commands declared with
WithHttpCommandandWithProcessCommandtypically gather user input throughIInteractionService.PromptInputAsyncinside theirPrepareRequest/ argument-building callbacks. That service is only wired up to the dashboard UI, so the commands cannot be invoked from the Aspire CLI:Compare with the prompt agent's
send-messagecommand, which declaresargumentInputson the command itself. The CLI surfaces those as flags and the command runs fine non-interactively:Concrete example
The Foundry hosted-agent
Send Messagecommand (added inHostedAgentBuilderExtension.cs) usesWithHttpCommandwith an interactivePromptInputAsyncto collect the message body. It works great in the dashboard but is unusable from the CLI / scripts / agents.Proposal
Allow
WithHttpCommandandWithProcessCommandto declare typedargumentInputs(the same shape that resource commands already use), so the CLI can collect values via flags and pass them to thePrepareRequest(HTTP) or argument-builder (process) callback. The dashboard would continue to render those argument inputs as a form, and the CLI would surface them as--<name> <value>flags. Implementations usingIInteractionServicewould still work, but the CLI path would no longer require it.This would give CLI/automation parity for the auto-generated hosted-agent
Send Messagecommand and any otherWithHttpCommand/WithProcessCommandusage.