Keep secrets out of command history
A terminal workflow can help when a script or operator needs to hand off a generated credential. The CLI reads the message from standard input, which avoids exposing it in the command itself. Standard input can still be recorded by the process or environment that supplies it, so use a trusted terminal and shell.
Choose and verify the download
Download the KeySlip CLI for your operating system and CPU from the developer guide. Extract the archive and verify its SHA-256 checksum against the published checksums before running it. The same executable supports the CLI and local MCP server.
Pipe fictional content for a safe example
The following uses a fictional message. For a real credential, source it from a trusted secret manager or prompt; do not paste it into a shell command, script file, or terminal recording. The client encrypts locally before sending ciphertext to KeySlip.
printf '%s' 'Fictional staging token: DEMO-ONLY-42' | \
./keyslip send --expire 1h
# Read explicitly, once; keep the full link private
./keyslip read "$link"Pass the complete link to the recipient
The `send` command prints a share link. Deliver it privately to the intended recipient and send an optional `--password-stdin` password separately. The full link includes the decryption key in its fragment. Anyone with the full link can attempt to read the message.
Treat reading as a destructive action
Use `read` only when you intend to consume the message and are ready to handle its plaintext securely. The first read can consume the message even when the connection fails, times out, or the optional password is wrong. Do not automatically retry. The agent or process receiving the plaintext can retain it; deleting a link does not revoke the credential.
Explore the integration details
The developer guide documents CLI downloads, HTTP API and local MCP. Read Security explained for the encryption design and boundaries.