Add SFTP Session with CLI-style file transfer (like SecureCRT)

[moliyadi]

Problem / motivation

I frequently need to upload/download files during SSH sessions using SFTP commands (put, get, mput, etc.). Currently, Oryxis only offers a GUI-based file browser, which is slow for batch transfers and breaks my CLI-centric workflow. Users coming from SecureCRT expect an interactive SFTP command prompt integrated into the terminal session.

Proposed solution

• A new "SFTP Session" tab or mode alongside the existing SSH shell.
• An interactive SFTP prompt supporting standard commands: get, put, ls, cd, lcd, progress, etc.
• Transfer progress and errors displayed inline in the session output.
• Allow opening an SFTP session directly from an active SSH connection (auto-reusing credentials).

Alternatives / current workaround

No response

Prior art

No response

[wilsonglasser]

Implemented and on main, not in a release yet.

It is a real terminal tab whose far side is an SFTP REPL instead of a shell, so scrollback, selection, copy, search, themes and session recording all behave as they do in any other tab.

Three ways in: the host card menu ("SFTP Console"), the tab context menu on a live SSH tab, and Ctrl+Shift+S (Cmd+Shift+S on macOS). Opened beside a live tab it starts in that shell's working directory; opened from a card it starts at the session home. Either way it reuses an existing connection to that host when there is one, so it usually costs no extra handshake, and it opens in its own tab so a long get does not end when you close the shell you started it from.

v1 command set: cd, lcd, pwd, lpwd, ls, lls, get, put, mget, mput, reget, reput, rm, mkdir, lmkdir, rmdir, rename, chmod, progress, version, help, bye/quit/exit. Globs work on get/put/rm/ls, Tab completes remote paths, the arrows walk history, and Ctrl+C cancels a transfer while it is running rather than after it finishes.

One decision worth stating plainly: the behaviour follows OpenSSH sftp(1) rather than matching SecureCRT command for command. VanDyke does not publish that list, and the vocabulary in your report (mput, progress) is OpenSSH's anyway, so sftp(1) is the target. What we took from SecureCRT is the shape: a dedicated tab opened from a live session, with completion and a shortcut.

Two limitations, both deliberate and both visible rather than silent:

• ls -l shows numeric uid/gid. SFTP v3 sends a preformatted listing line with names already resolved, and the Rust SFTP crate we build on drops it before we ever see it. The fix belongs upstream, not in a fork.
• -r, -p and -f on get/put are parsed but not implemented, so the console names them as unsupported instead of accepting them and doing nothing. Recursive transfers are the obvious next step.

df, chown, symlink and the ! local-shell escape are not in yet. The ! one is on hold for a reason rather than by omission: text a remote host prints can reach a pane through triggers and snippets, and spawning a local process from that path is a different risk class from anything else the console does.