Summary

When I create an SSH workspace from a macOS client to a Linux remote, the Files explorer roots itself at ssh://<host>/Users/<user> — the macOS home path — instead of the remote's actual $HOME (/home/<user>). Since /Users/<user> does not exist on a Linux host, every file operation fails and the panel shows a bare "SSH command failed".

The terminal in the same workspace works fine (it resolves the correct remote ~), so the remote working directory is clearly available — the Files explorer just isn't using it.

Environment

• cmux (macOS client): 0.64.13 (build 93)
• cmuxd-remote: 0.64.13 (linux-amd64)
• Client OS: macOS 26.4.1 (25E253)
• Remote OS: Linux (Amazon dev desk), $HOME=/home/<user>
• Transport: ssh, connecting via an ~/.ssh/config host alias (ProxyCommand to reach the host)

Steps to reproduce

1. On macOS, where the local $HOME is /Users/<user>.
2. Create an SSH workspace to a Linux remote whose $HOME is /home/<user>.
3. Open the Files panel for that workspace.

Expected behavior

The Files explorer roots at the remote working directory — the remote $HOME (/home/<user>) or the remote pwd — which the daemon/terminal already knows.

Actual behavior

• The Files panel is rooted at ssh://<host>/Users/<user> (the local macOS home path).
• /Users/<user> does not exist on the Linux remote, so the listing command fails:

  $ ssh <host> 'ls -la /Users/<user>'
  ls: cannot access '/Users/<user>': No such file or directory   # rc=2
  $ ssh <host> 'ls -la /home/<user>'                              # rc=0 — the real home
  

• The panel surfaces this only as "SSH command failed" (no path or errno shown).

Root cause (from inspecting session state)

The workspace's persisted currentDirectory is seeded from the local cwd/home and then reused as the remote file-explorer root:

~/Library/Application Support/cmux/session-com.cmuxterm.app.json

windows[0].tabManager.workspaces[N] = {
  "workspaceId": "…",
  "currentDirectory": "/Users/<user>",            // <-- local macOS home, used as remote root
  "remote": { "destination": "<host>", "transport": "ssh", … }
}

The remote terminal resolves ~ correctly (prompt/title update to the real remote path on cd), so the remote working directory is known to cmux — the file transport just doesn't consult it.

Two smaller observations while debugging

1. No path validation / poor error. When the root stat/ls returns rc=2, the panel shows only "SSH command failed". Falling back to the remote $HOME (or at least surfacing the path + errno) would make this self-explanatory.
2. Editing the persisted currentDirectory doesn't help. Quitting cmux, editing currentDirectory → /home/<user> in both session-com.cmuxterm.app.json and session-com.cmuxterm.app-previous.json, then relaunching: cmux regenerates /Users/<user> on launch. So there is no user-side workaround via session state — the value is derived in-memory, not read back from the edited file.

Suggested fix

On SSH-workspace connect, resolve the file-explorer root from the remote (remote $HOME or pwd via the daemon) rather than inheriting the local currentDirectory. Optionally, validate the configured root and fall back to remote $HOME (with a clearer error) when it doesn't exist