File operations execute on host system instead of remote system when using SSH

[ra7bi]

File operations execute on host system instead of remote system when using SSH

Description

When connected to a remote system via SSH, file operations (such as reading files) are incorrectly executed on the host system instead of the remote system. The ls command correctly lists remote files, but read file commands access the host system's filesystem.

Steps to Reproduce

1. Connect to a remote Linux system via SSH from a Windows host
2. Use ls command to list files on the remote system (works correctly)
3. Attempt to read a file using the read file command
4. The command reads from the host system instead of the remote system

Expected Behavior

File operations should be executed on the remote system when connected via SSH, similar to how the ls command works correctly.

Actual Behavior

• ls command: ✅ Lists files from remote system
• read file command: ❌ Reads files from host system (Windows)

Evidence

The issue is confirmed by creating a file with the same name on the host system, which then gets read instead of the remote file, proving that file operations are not being routed through the SSH connection.

Environment

• Host System: Windows
• Remote System: Linux
• Connection Method: SSH
• File in question: docker-compose.yml

Error Messages

Error: No contents: File does not exist.

(This error appears when trying to read a file that exists on the remote system but not on the host)

Impact

This makes it impossible to work with files on remote systems via SSH, significantly limiting the editor's functionality for remote development workflows.

Additional Context

The inconsistency between ls (working correctly with remote system) and file read operations (incorrectly using host system) suggests this is a routing issue in how different commands are executed over the SSH connection.

From discord :

[andrewpareles]

Thanks, added to roadmap, this is somewhat important!

[WilliamBenEmbarek]

@andrewpareles my gut feeling tells me it's likey the same root cause behind #500

[treviloan]

Seeing this same issue along with noted https://github.com/voideditor/void/issues/500