File transfer

Investigating a device often ends the same way: you need a file off it, or a fix onto it. Transit’s Files surface is a dual-pane file browser — your local machine on the left, the remote device on the right — that runs over SFTP against the devices already in your inventory. It reuses the SSH side’s credentials and host-key trust, so there’s nothing new to set up.

Like every other surface in Transit, the split is the same: you move files in either direction; the AI can’t touch any of it.

Available in Transit 5.0.0 and later.

SFTP today. Transit moves files over SFTP. SCP — for the rare gear with no SFTP subsystem — is planned.

Two actors, one surface

	You	The AI agent
Can do	Browse both sides, create / rename / delete, transfer	Nothing — no access at all
Gated?	No — it’s your files, your device	N/A — no tool reaches file transfer
Sees it?	Yes — it’s your surface	No — structurally invisible
Price	Free	—

The dual-pane browser

Files opens as a SecureFX-style two-pane browser: your local filesystem on the left, the remote device on the right. Each side has the usual moves — open folders and create, rename, and delete entries. Navigate the two independently; the panes don’t have to mirror each other.

Move a file — four ways

Transfers run in either direction (local → remote or remote → local). Start one however suits your hands:

Double-click a file to send it to the other pane’s current folder.
Toolbar — select rows and click the upload / download button.
Drag between panes — drag rows out of one pane and drop them in the other.
Drag in from your OS — drag files straight from Finder or Explorer onto the remote pane to upload them.

Directory transfers are recursive, and each file’s modification time is preserved on the far side.

The transfer queue

Every transfer joins a live queue with per-file progress, transfer speed, and a Cancel button. When a transfer would overwrite something that’s already there, Transit asks once with a batch policy — Overwrite all, Skip, or Cancel — rather than nagging per file. If the connection drops mid-transfer, Transit reconnects in place and you pick back up.

Same inventory, same credentials, same trust

The Files surface isn’t a second place to configure devices. It transfers over the same inventory you already use for SSH — the same stored credentials (by reference, from your OS keyring / 1Password / env) and the same host-key trust (the TOFU pin from your first SSH connect). Opening a device’s remote side is the same connect you already know; there is no separate credential to manage.

Turning it off (and DLP)

File transfer is on by default and free. It also doubles as a data-loss-prevention control: administrators who don’t want files leaving or landing on managed machines can remove the whole surface with a config switch:

[files]
enabled = false

in Transit’s config.toml, which lives next to the transit.toml inventory:

OS	Path
macOS	`~/Library/Application Support/Transit/config.toml`
Windows	`%APPDATA%\Transit\config.toml`
Linux	`~/.config/Transit/config.toml`

Create the file if it doesn’t exist yet, then restart Transit. With it set, the Files rail tab doesn’t appear and no transfer can start — the surface is gone, not merely hidden.

Why the AI can’t touch it

File transfer is human input, by construction — the same two-actor model as the rest of Transit. The agent’s tool surface is fixed at six abilities (list open sessions, read redacted scrollback, propose a command, propose a read-only API GET, query a packet capture, ask a question), and none of them reach the file browser. The AI can’t list what’s on either side, can’t read a file, and can’t move one — there is no tool that reaches this surface, and no new one was added for it. It’s structurally blind to file transfer, exactly as it is to your local terminal.

That’s architectural, not a preference you could loosen. See the security model for how the fixed six-ability menu and the agent firewall are enforced.