Enable the terminal command for all remote names

[etherandrius]

Description

Enabling the terminal command for all remotes; I'm pretty sure this is no longer needed?

The fallback says it's not enabled because it does not work for SSH but at the same time the feature is explicitly enabled for ssh-remote

See definition of vscode.env.remoteName

        /**
         * The name of a remote. Defined by extensions, popular samples are `wsl` for the Windows
         * Subsystem for Linux or `ssh-remote` for remotes using a secure shell.
         *
         * *Note* that the value is `undefined` when there is no remote extension host but that the
         * value is defined in all extension hosts (local and remote) in case a remote extension host
         * exists. Use {@link Extension.extensionKind} to know if
         * a specific extension runs remote or not.
         */
        export const remoteName: string | undefined;

---

Summary by cubic

Enables terminal command execution across all environments by removing remoteName gating and using a single spawn-based path. SSH, WSL, Dev Containers, Codespaces, and local now get live output, background support, and clear status messages.

• New Features

  • Works across all remote names (SSH, WSL, Dev Containers, Codespaces, etc.).
  • Streaming output, background mode, and waitForCompletion supported everywhere.
  • Color-capable environment applied to all runs.

• Refactors

  • Removed ENABLED_FOR_REMOTES and ide.runCommand fallback; unified on child_process.spawn.
  • Dropped util.promisify/exec and unused imports.
  • Safer cwd resolution (workspace → home → process.cwd → os.tmpdir) and better process cleanup.

[etherandrius]

not used

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

agrabauskas seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[etherandrius]

not used

[etherandrius]

Actual change is removing this if.

All lines below are just indentation changes

[etherandrius]

Removing fall-back

[RomneyDa]

@etherandrius I think the original reason for this logic was to enable running commands in the remote environment, i.e. less as a fallback for environments that don't support it and more of a way to enable running commands in remotes at all (through IDE interface). It seems like this has slowly been watered down so not all commands are run locally, partly because the support for local commands is so much better now (partial output, backgrounding, etc.)

@chezsmithy you've done a lot of work here, noticed your reaction, do you have any thoughts on running commands remote vs locally when in a remote filesystem?

[chezsmithy]

@RomneyDa there are explicit ways to use local vscode with remote terminals. I've had a few ideas I've tinkered with but it gets odd when vscode makes file creates/edits locally but runs terminal commands remotely. See a dev container use case for example.

This is also quite different from what jetbrains expects using their remote ssh support.

This PR might work fine in both tools but I'm not sure without testing.

My take so far has been to install the entire extension in the remote host for vscode. IM not a huge jetbrains user (tho we have many in our organization).

[RomneyDa]

@chezsmithy thanks!

@etherandrius what was the original intent for this PR, does it fix a specific problem with commands being run remotely when they shouldn't for a given remote?