FileFling started as a tiny annoyance that kept showing up in my remote development workflow: I would be talking to a CLI coding agent inside SSH or tmux, then need to show it a screenshot from my local Mac.

The agent could read files on the remote machine. The screenshot lived on my laptop. The gap was small, but it broke flow every time.

So I built FileFling, a macOS menubar app that uploads screenshots and files over SSH/SFTP and copies the remote path to the clipboard.

The workflow

The main flow is intentionally boring:

1. Take a screenshot on the Mac.
2. Press Command Shift F.
3. FileFling finds the latest screenshot.
4. It uploads the file to the active SSH destination.
5. It copies the rendered clipboard output.
6. Paste that path into the remote shell or agent chat.

The default copied value is just a path like this:

/home/brad/shared/2026-06-25_143015.png

A clipboard template can turn that into Markdown or a prompt:

Please inspect this uploaded screenshot: {{remotePath}}

Why it is a menubar app

I did not want another full desktop app. FileFling should feel closer to a system affordance than a destination. It lives in the menubar, stays out of the Dock, and exposes only the things needed in the moment: latest screenshot preview, drag and drop upload, destination picker, settings, and recent sends.

That shape also matches the task. Sending a screenshot is an interruption. The app should make the interruption as short as possible.

SSH first, service never

FileFling does not require a hosted upload service. It uses the same kind of SSH access that already powers the remote dev workflow. Under the hood, the app uses the Node ssh2 library for SFTP uploads, expands remote ~/ paths, creates the remote directory when needed, and sanitizes uploaded filenames.

SSH config import was an important fit. If a user already has devbox in ~/.ssh/config, FileFling can pull in the concrete host, username, port, and identity file instead of making the user type them again.

Setup is part of the product

The first-run setup flow is doing more than collecting form fields. It can run a real connection test that resolves the remote home directory, creates the remote directory, verifies write access, uploads a tiny hidden test file, then removes it.

This matters because SSH tools often fail in ways that are technically accurate and practically useless. FileFling maps common failures into messages about missing keys, open key permissions, DNS problems, auth failures, host key mismatches, unwritable remote paths, oversized files, and missing screenshots.

Trust boundaries

Electron apps deserve suspicion by default, especially when they touch files and SSH keys. FileFling keeps the renderer locked down with context isolation, no Node integration, sandboxing, a Content Security Policy, blocked navigation, and a small validated preload API.

Host keys use trust on first use. The app stores host, port, algorithm, fingerprint, and trust timestamp, then verifies future connections against that record. If a server is rebuilt and the key changes, Settings has a host key review screen where stale trust records can be forgotten intentionally.

What I like about it

The satisfying part is that FileFling is not trying to become a file manager. It is a small bridge between two contexts that are already in my workflow: local screenshots and remote agent sessions.

The best tools in this category do not make you think about them. You press the hotkey, paste the path, and keep moving.

Read the project page for the feature list, stack, and product notes.