Remote-SSH (Linux/zsh): Claude Opus 5.5 Agent Shell injects PowerShell [Console]::OutputEncoding and fails; Auto works

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When connected via Remote-SSH to a Linux host whose default shell is zsh, Agent mode with Claude Opus 5.5 cannot run even trivial shell commands like echo hello.

Both echo hello and /bin/echo hello fail with exit code 1 and:

(eval):1: no matches found: [Console]::OutputEncoding

The remote shell is zsh. [Console]::OutputEncoding is Windows PowerShell syntax, so it looks like the Agent Shell tool wrapper is injecting a Windows/PowerShell encoding preamble into commands that are then executed on the remote Linux/zsh environment. zsh treats [...] as a glob and fails with NOMATCH.

In the same Remote-SSH workspace, switching the model to Auto and running the same echo hello succeeds (exit 0, prints hello). So this appears model-path / Shell-wrapper related, not a broken remote zsh install.

Steps to Reproduce

  1. On Windows, open Cursor and connect to a Linux remote via Remote-SSH (remote default shell = zsh).
  2. Open any remote folder/workspace.
  3. Start Agent chat, select Claude Opus 5.5.
  4. Ask the agent to run echo hello.
  5. Observe Shell tool failures with (eval):1: no matches found: [Console]::OutputEncoding (exit code 1). Retrying with /bin/echo hello fails the same way.
  6. Switch the model to Auto in the same remote workspace and ask again to run echo hello.
  7. Observe success: output hello, exit code 0.

Expected Behavior

On Remote-SSH Linux/zsh, Agent Shell should execute the requested command on the remote host without injecting Windows PowerShell wrappers such as [Console]::OutputEncoding. echo hello should print hello and exit 0 for any Agent model, same as Auto.

Operating System

Windows 10/11

Version Information

Client: Cursor IDE on Windows 10
Remote-SSH extension: anysphere.remote-ssh 1.1.16
Remote OS: Ubuntu 18.04.3 LTS (Linux x64), default shell zsh
Remote Cursor Server commit (approx): 37076c6c3f9e253c0fa2305197e45befd13a2260

For AI issues: which model did you use?

Fails: Claude Opus 5.5 (Agent).
Works: Auto (Agent).
Same Remote-SSH workspace.

Additional Information

Error signature is consistent across retries (~1600ms each): (eval):1: no matches found: [Console]::OutputEncoding

This matches zsh NOMATCH behavior when a PowerShell snippet containing [Console]::... is eval’d on Linux.

Workaround: use Auto model for Agent shell work over Remote-SSH, or possibly change remote default shell away from zsh (not verified as a full fix).

Happy to provide screenshots of the Opus failure vs Auto success from the same session.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey @yang_liu2, thanks for the report and the clear repro.

We looked into this on our side. None of the Claude Opus 5.5 requests from those chats reached our servers, and the agent requests from your machine don’t match your signed-in account or your Cursor version. That usually means a third-party proxy, account switcher, or “model unlock” tool is sitting between Cursor and our servers and rewriting the traffic. The [Console]::OutputEncoding commands come from whatever service that tool sends Opus requests to, not from Cursor. That’s also why Auto works: those requests do reach us.

Could you try this:

  1. Quit Cursor completely.
  2. Disable or uninstall any proxy, VPN rule, account-switching tool, or plugin that changes Cursor’s requests or models.
  3. In Cursor Settings → Models, make sure there is no custom API key or base URL override turned on.
  4. Start Cursor, sign in with your own account, and connect to the same Remote-SSH host.
  5. Open a new Agent chat and ask it to run echo hello.

If it still fails, reply with the exact error, your Cursor version (Help → About), and the Request ID from that chat (the “…” menu at the top of the chat → Copy Request ID).