Security and data storage

macSCP is built so that nothing about your connections leaves the machine unless you send it there yourself.

Secrets live in the macOS Keychain

Passwords and passphrases live only in the macOS Keychain. JSON stores on disk — sessions, tunnels, settings — never contain them. Duplicating a session carries a reference to the keychain entry, not a copied secret. The CLI reads the very same keychain items; see the keychain prompt for how macOS handles a second program reading them.

Credentials in a server address

A user name and password typed into an S3 endpoint or a WebDAV address (https://user:secret@host) are kept out of everything macSCP shows or writes: the session overview, the sidebar, error messages, the transfer queue, the connection log, the import preview, the macscp-cli sessions list, and S3 share links. The address field in the session editor still shows what you typed.

For S3, such a user name and password are never sent either — the access key and secret key have fields of their own. An S3 endpoint with an @ after the server name, for example in its path, is refused with “Enter the endpoint as a server address, such as https://s3.example.com…”, also for a session saved before this rule.

Key files

Converting a PEM key — with Convert key… or on import in the key manager — never writes to your original file. macSCP converts a copy, stores it in its own key folder readable by you alone, and removes the copy if the conversion fails. See PEM private keys.

Host-key pinning

Host keys follow a strict trust-on-first-use rule, and the rules are security-critical — there is no accept-anything path:

• The first connect to an SSH server shows the fingerprint and asks you to confirm it.
• An unknown key requires explicit consent.
• A changed key is a hard stop: macSCP refuses the connection, the user decider is never consulted, and no setting or CLI flag can wave it through. Verify the change out of band (for example on the server console), then update the pinned key in Sessions → Known Hosts (⌘⇧K).

The CLI applies the same rules — see Host keys.

The fingerprints of a changed host key are shown in the warning itself, but not written anywhere else: the diagnostic log, the diagnostics report and a forwarding’s failure reason name only the host.

Jump hosts in diagnostics

When the connection diagnostics go through a jump host, the jump host’s saved login is sent only to the jump host and the target’s only to the target.

Audit logs

macSCP writes a per-session audit log: one file per saved connection under

~/Library/Application Support/macSCP/audit/

Deleting a saved connection deletes its log. The log records what the session did — listings, connects, transfers — as a record, and it is where you look after the fact rather than while it happens.

Diagnostic log

The diagnostic log (level chosen in Settings → General) is a bug-report tool you turn on and send with an issue. It is flushed when the app terminates, so a quit does not lose its tail.

Update checks

The automatic update check asks api.github.com at most once a day and sends nothing but the app name and version; nothing is downloaded or installed automatically. See Updating.

Notifications

A notification names only the session or the forwarding — no host, path or error text.

What is never sent

No telemetry, no crash reporting service, no account anywhere: saved sessions, known host keys and settings stay on your machine, and the only network request macSCP makes on its own behalf is the update check.