It should just run "$SHELL" -c 'composer …' or %ComSpec% /S /C "composer …" without checking for any "availability", if nothing more specific is defined by the user.

Anyone interested in picking this feature for development?

Turned out, the option "run in terminal" is quite misleading.
I would suggest changing it to support modern VS code profiles and clearly label as that.
My default profile is Cygwin bash, running TCC script in it just does not work.
Not to mention it is impossible to pass unescaped backslashes through POSIX shell.

@AnrDaemon Thank you for your feedback. Do you think you can have a look at it on your windows machine, an help identify/fix further issues.

I'm by no means an expert in VS code extension development, but if you provide instructions, I could take a look.

Here's my thought on the issue:

1. Extension should provide a user with choice of configured terminal profiles to run the "composer executable" with. Rationale: while under *NIX, it's quite easy to pretend everything is an executable, in Windows there's "issues". To work around most of them, I use wrapper scripts. Particularly, I'm using Cygwin dash/bash to wrap Cygwin tools and TakeCommand/console to wrap native console tools, but missing that, it could have been PowerShell. But there's a regression in Windows 10 where it is running all scripts through cmd first and resolves symlinks before passing the script to configured interpreter. Have to run the script directly by interpreter to avoid the issue.
2. The current "run in terminal" boolean flag could remain, but with modern tabbed terminals I see little use for it.
3. The "--working-dir" option should be supplied only if explicitly defined in extension configuration. And exactly as defined. (Part of the issue could have been avoided if not for this).
4. Inheriting from the above, the call should always happen with CWD set to the workspace root.