Skip to content

The desktop app

The desktop app is the same vault as the command line, in a window: the same file, the same core, the same rules about what leaves it. It opens a vault, lists what is in it, shows one item at a time, and copies a field to the clipboard. Adding and editing items stays on the command line for now.

The one-line installers from Getting Started put the desktop app beside the command line:

  • Windows - the release’s own installer, run silently for your account: sefy appears in the Start menu, and the program lands in %LOCALAPPDATA%\sefy\sefy-gui.exe. No administrator is asked for.
  • macOS - sefy.app in ~/Applications.
  • Linux - an AppImage in ~/.local/share/sefy/, a menu entry, and sefy-gui on your PATH. The AppImage needs FUSE 2 (libfuse2).

The program is sefy-gui, so it never takes the command line’s sefy on PATH. Run the installer again to update; a window that is open is left alone, and the installer says to close it first.

sefy’s installers are not code signed, and a security program may stop one that few machines have seen yet. The one-line installer then says so, without treating it as the end: the command line is already in place by that point and works without the window. Nothing about the vault format depends on the desktop app.

Do not turn your protection off for it. The installer is built in the open by this repository’s release workflow from the tagged source, and the release page lists the digest of every file. You can also run the window from source.

There is one window. Starting the program again brings it forward, and starting it on a file hands the file over: another file locks the vault that is open and offers the new one, since you asked for another vault and the first should not stay unlocked behind it.

There is no list of recent vaults, by design: a list of the files sefy opened, in a predictable place under your profile, would name exactly the files the format works to make unremarkable. The window takes the file from:

  1. the file it was started on - “Open with”, or sefy-gui notes.bak;
  2. otherwise SEFY_VAULT, the variable the command line reads;
  3. otherwise the file you drop on the window or pick with Browse….

On Windows the file dialog is told not to add the vault to the system’s recent documents either.

The rail on the left lists every item and each kind with how many there are, then the tags. The search box (Ctrl K) looks where sefy find looks - titles, notes and the fields that are not secret, never a password - and puts the items whose title matches ahead of those that match only inside. ↓ steps from the box into the list, Enter opens the first match, and the arrows walk the list.

This vault, at the foot of the rail, is what sefy status says: how many items of each kind, where the file is, how it is sealed, when it last travelled. Never a title.

The card shows what sefy show prints: the public fields as they are, a note’s text, a file’s name and size - and every secret field named and hidden. The page in the window does not receive a secret at all until you press Show beside it, and it forgets it when you press Hide, open another item, or lock.

A one-time password key is shown as the code it makes, with a ring for the seconds the code has left; the key itself never leaves the vault.

Files stay in the vault: take one out with sefy extract.

Copy beside a field puts it on the clipboard without it passing through the window’s page. The button counts down in amber while the secret is out, and after 45 seconds sefy takes it back off - the same hold as sefy get, and the same rule: only if it is still what is on the clipboard, so whatever you copied since is left alone.

Every copy is marked as one the clipboard history (Win V) and the cloud clipboard must not keep, and that clipboard managers should pass by - see the clipboard.

Ctrl Alt Space (Cmd Shift Space on macOS) brings up a search line over whatever is on the screen. Type a few letters, and Enter copies the item’s secret - what sefy get would take: a login’s password, a card’s number, a note’s text - and the line goes away. Esc or a click elsewhere puts it away without copying.

  • It shows nothing until you type, so bringing it up does not put a list of your items on the screen.
  • With the vault locked, the shortcut brings the main window forward to unlock it instead: the master password is typed in one place only.
  • It works while the window is running, minimized or not. Closing the window closes sefy, and the shortcut with it.
  • If another program already holds the keys, the status line at the foot of the window says so, and the window works without quick search.

Lock closes the vault in the window’s process, takes back whatever sefy put on the clipboard, and closes quick search - which has titles in it, so it is destroyed rather than hidden. Closing the window does the same.

The window also does this by itself after 15 minutes of nobody using it, and after 12 hours however busy it has been. Pressing, typing and scrolling count as using it; a one-time code running on a card does not. The file stays offered on the Unlock screen.

sefy lock in a terminal locks the window too.

While a vault is unlocked here, sefy commands on the same vault do not ask for the password: the window is an agent for as long as it holds it. Using the vault from the command line counts as using it.

Terminal window
$ sefy status
vault /home/you/backups/notes.bak
size 84.1 KB
lock unlocked by the window, locks in 14m

The window does not notice a change the command line made until it is unlocked again.

The threat model is the command line’s, with two additions: an open window shows titles to whoever is looking at the screen, and a secret you Show is a string in the window’s page from then until the page is gone - something no program can wipe from a webview’s memory. That is why a secret is shown only when you ask, and copied without being shown at all.