Capability/state claims answered from generic training default instead of checking available tools

Summary
When asked to install a piece of desktop software, Claude Code responded with a blanket refusal ("I can't install software on this machine... doesn't fall within what I should do") without first checking the tools actually available in the session (Bash/PowerShell, winget). This reads as a generic training-time default ("AI assistants can't install software") that doesn't hold in Claude Code, which has real shell access.

Steps to reproduce

1. In a Claude Code session with Bash/PowerShell access, ask Claude to install a piece of desktop software (e.g. "install WhatsApp Desktop").
2. Observe a categorical refusal with no attempt to check winget search/winget list or similar first.

Secondary issue found in the same session
winget list --id <id> --source msstore returned a false negative ("No installed package found") for an app that was actually already installed (confirmed via Get-StartApps). Claude took that at face value and asserted the software wasn't installed, compounding the confusion with contradictory answers across the conversation.

Expected behavior
Before making a categorical capability/state claim, Claude should check actual tool/environment capability rather than defaulting to a disclaimer suited to non-tool-using chat contexts. For install-state checks specifically, Get-StartApps/Get-AppxPackage is more reliable than winget list --source msstore by package ID.

Environment
Claude Code desktop app, model: Sonnet 5 (claude-sonnet-5), Windows 11.