Proton Drive CLI: Using Proton Drive from Scripts and Servers

On June 9, 2026, Proton released the Proton Drive CLI, an official command-line tool for Windows, macOS, and Linux. It is based on the same SDK as the official Drive apps, provides end-to-end encryption, and is available as a single executable file proton-drive. The source code is available in the public SDK repository at cli/.

The CLI is intended for individual, time-bound tasks: uploading files after a build, backing up a folder on a schedule, checking or revoking shares. It does not synchronize in the background or mount a file system. The current version is 0.8.0 from August 13, 2026; the version number indicates that commands and options may still change (version 0.8.0 renamed the conflict strategies in an incompatible change).

For how it fits among the other Linux options (Rclone, the announced desktop client), see the status article Proton Drive on Linux.

Command overview

The commands are organized into groups: proton-drive <gruppe> <befehl> [optionen] [argumente]. Group names can be abbreviated as long as they remain unambiguous; filesystem also has the alias fs. Without arguments, it starts an interactive shell. Full help is available through proton-drive help and proton-drive <gruppe> <befehl> --help.

Paths in Proton Drive are always POSIX paths, including on Windows. The root / contains virtual areas: /my-files (your own files), /devices (backed-up computers), /shared-by-me, /shared-with-me, /trash, plus the Photos areas /photos, /albums, /photos-shared-by-me, /photos-shared-with-me, and /photos-trash.

Installation on Linux

Proton provides builds on a dedicated download page, each with an SHA-512 checksum. There are five variants for Linux:

If the standard build exits at startup with Illegal instruction, the CPU lacks the AVX2 extension; in that case, the x64-baseline build is the right choice. The file includes the Bun runtime and requires no additional dependencies:

chmod +x proton-drive
sudo install -m 0755 proton-drive /usr/local/bin/proton-drive
proton-drive version

Without administrator privileges, it is enough to copy the file to ~/.local/bin if that directory is in PATH.

Signing in, including on servers without a desktop

auth login does not request a password on the command line. The CLI attempts to open a browser and also displays the sign-in URL. This URL can be opened on another device; the terminal waits until sign-in has been completed there. Two-factor authentication proceeds normally in the browser. This also allows signing in over SSH on a server without a graphical interface.

proton-drive auth login

After a successful sign-in, the CLI stores the session, not the password. Its location is determined by the PROTON_DRIVE_CREDENTIALS_STORE environment variable:

A server without a desktop session generally lacks an unlocked libsecret keyring. Since version 0.6.0, pass has been available for this case. The user running the scripts needs an initialized password store and a GPG key that gpg-agent can unlock without interactive input. The session must be found through the same variable on every invocation, so it must also be set in Cron jobs and systemd units:

export PROTON_DRIVE_CREDENTIALS_STORE=pass
proton-drive auth login

This is an improvement over Rclone: the password and TOTP key are not stored on the server, and auth logout terminates access. However, the session still has the account’s full scope. There is no restriction to individual folders or read-only access. For automated workflows, a separate Proton account therefore remains the safer option.

On Linux, cache, application data, and logs are stored in the XDG directories (~/.cache/proton-drive-cli, ~/.local/share/proton-drive-cli, ~/.local/state/proton-drive-cli). PROTON_DRIVE_CACHE_DIR can place all three in a single directory, for example for a container with a mounted volume. By default, the CLI writes logs at level DEBUG; PROTON_DRIVE_LOG_LEVEL=WARNING reduces their volume.

Uploading and downloading in scripts

Interactively, the CLI asks what to do for every naming conflict. That is not possible in scripts: --json disables the interactive prompt. Therefore, always explicitly set the conflict strategy for files and folders.

proton-drive filesystem upload --json \
  --file-conflict-strategy create-new-revision \
  --folder-conflict-strategy merge \
  --skip-thumbnails \
  /srv/export/berichte /my-files/backup

create-new-revision is the right choice for backups: Proton Drive retains earlier versions of a file, and since version 0.7.0, the CLI automatically skips files with unchanged contents. However, the CLI does not synchronize: locally deleted files remain in Proton Drive. Anyone needing a mirror that includes deletions still needs rclone sync.

Downloading works in reverse. The strategies differ because the local side is overwritten here:

proton-drive filesystem download --json \
  --file-conflict-strategy remove \
  --folder-conflict-strategy merge \
  /my-files/backup/berichte /srv/restore

The CLI skips Proton Docs and Proton Sheets when downloading; they currently cannot be exported as files.

A regular upload can be scheduled with a systemd timer or Cron. The JSON output can then be evaluated with jq, for example to send a notification to monitoring.

Managing shares

For offboarding or audits, share management is often more useful than file transfer. sharing status shows all members, pending invitations, and public-link settings for an item:

proton-drive sharing status --json /my-files/projekte/kunde-a

An invitation with viewer access:

proton-drive sharing invite \
  --user person@example.com \
  --role viewer \
  /my-files/projekte/kunde-a

A public link with a password and expiration date:

proton-drive sharing set-url \
  --role viewer \
  --password 'Linkpasswort' \
  --expiration 2026-12-31 \
  /my-files/projekte/kunde-a/bericht.pdf

A password passed on the command line appears in shell history and is visible in the process list while execution is in progress. In scripts, it should therefore come from a variable or secret store. sharing remove-url removes the link without affecting direct members; sharing remove --user … revokes access for individual people.

In progress: Takeout

Since September 10, 2026, the SDK repository has included another command, takeout run. It exports an offline copy of the account to a local folder, optionally with --include my-files, devices, photos, and revisions (all earlier file versions). For each folder, it writes a manifest.json describing the export; it does not modify the account. The command is not yet included in the released version 0.8.0. Once available, it will be the obvious route for a complete local backup of Proton Drive contents.

Limitations compared with Rclone

For backups, build artifacts, and share management, the CLI is the better choice because it is officially supported and does not require a stored password. For a mount, such as one needed by a Paperless document archive, and for mirrors with deletions, Rclone remains necessary for now. The largest gap is the same in both cases: Proton does not offer machine access that can be restricted to individual folders or read-only access.