SFTP Without Leaving Your Terminal: Browsing Remote Files in the Same Session

The workflow is familiar enough that it stops registering as friction. You are in a shell on a remote host, you find a log file worth keeping, and now you need it locally. So you open a second application, re-enter the same connection details, authenticate again, navigate to the same directory you were already standing in, and drag the file across. Or you type an scp command and reconstruct the remote path from memory, usually getting it wrong once.

Either way you have solved a problem you should not have had: you were already connected and already in the right directory.

SFTP is already part of SSH

The relevant detail is that this does not require a separate connection at all. SFTP is not a distinct protocol with its own port and credentials — it is a subsystem of SSH, running as a channel inside an SSH connection. When a dedicated SFTP client asks for a host and password, it is establishing a second SSH session to do something your existing session could already carry.

Kubexer Terminal uses that directly. SFTP opens as a channel on the connection you already have, so there is no second authentication, no second host key prompt, and no second entry in the server's auth log.

A tab, not a separate window

Remote files appear as a tab in the same window as your shells, sharing the tab strip and the vault's credentials. Switching between a shell and the filesystem is the same gesture as switching between two shells.

Two things follow from being in the same session:

• It knows where you are. The session tracks the working directory of the attached shell on a best-effort basis, so opening the file browser tends to land you in the directory you were already working in rather than at the home directory.
• Remote paths complete. Because there is a live SFTP channel, the terminal can resolve remote directories for completion. Typing cd and a partial path completes against the actual remote filesystem instead of failing silently, which is one of the small persistent annoyances of working over SSH.

What it does today

Being direct about the current scope, because a file browser that quietly cannot do half of what you expect is worse than one with stated limits:

• Browse — navigate the remote filesystem, with the usual metadata: sizes, permissions, modification times.
• Download — pull files to your local machine over the existing session.
• Upload is not implemented yet. The current release is read-and-retrieve. For pushing files, use scp or your existing tooling.

That is a deliberate first cut rather than an oversight: retrieval covers the overwhelming majority of ad-hoc file work — pulling a log, grabbing a config to diff, retrieving a heap dump or a backup — and it is the direction where getting it wrong is least destructive. Upload is on the roadmap.

Where it fits

This is not trying to replace a full file-transfer client for a bulk migration, and it is not a sync tool. It is aimed at the specific and very common case where you are already in a shell, you have found something you need locally, and the cost of getting it should be one click rather than a context switch through a second application.

Combined with the vault model — credentials stored once, encrypted on device, shared by every host that uses them — the practical effect is that remote files stop being a separate errand. The connection is already open; the files are simply on it.

See also command snippets for the other half of reducing repetitive work in a session. Kubexer Terminal is available for macOS, Windows, and Linux.