Frequently asked questions

It collects one or more sensitive values from a human and writes them into a .env file. You run pinchpass request API_KEY, it starts a one-time HTTP server on a random loopback port and prints a link, the human opens the link and types the value, and the CLI writes it to disk and exits. The value is encrypted in the browser, so the server and any tunnel relay only ever handle ciphertext.

No. PinchPass is a single Go binary that runs on your machine. There is no signup, no dashboard, no API key for the service itself, and no server to pay for. The optional public link uses the public bore.pub relay, which needs no account either.

A local request produces http://127.0.0.1:<port>/claim/<name>#k=<key>. With -tunnel it becomes http://bore.pub:<remote-port>/claim/<name>#k=<key>. The path segment is your secret name lowercased, and everything after the hash is the base64url encryption key.

Yes. Pass more than one name: pinchpass request DB_HOST DB_PORT DB_NAME -out .env. The form asks for each value and the browser sends them as a single encrypted JSON object. The CLI rejects the payload if it contains any key you did not request.

Use -tunnel. PinchPass dials bore.pub:7835 with a built-in standard-library client, gets a random public port, and prints a public URL, so you never open a port or configure NAT. Without -tunnel the server binds to 127.0.0.1 and is only reachable from the machine it runs on.

The link expires after the TTL, which defaults to 30 minutes and is set with -ttl. The server shuts itself down, the CLI exits non-zero, and nothing is written to your .env file. With -json the final object reports success as false.

No. The value is encrypted in the browser with XSalsa20-Poly1305 before it is sent, and the decryption key travels in the URL fragment, which browsers never transmit. The relay forwards ciphertext it cannot open. It can still observe metadata: that a request happened, its size, its timing, and the request path.

No. The path is derived from the secret name, so GEMINI_API_KEY becomes /claim/gemini_api_key, and anyone who knows the name can find the endpoint while the request is live. It does not need to be secret, because the path is not what protects the value: submitting requires producing ciphertext under the encryption key, which only the URL fragment carries. Treat the name as public and the value as protected. The security model has the full reasoning.

No. The payload is encrypted before it leaves the browser, so there is nothing on the wire to intercept, and no WebCrypto or TLS support is needed. HTTPS would still hide surrounding metadata such as the fact, size, and timing of the request from a network observer.

No. The first accepted submission claims the request, and every later request to that URL returns 404 with a link-expired page. If you need another value, run the command again to get a fresh link and a fresh key.

A leaked link is a limited risk. Anyone holding the full URL including the fragment can submit a value, but they cannot read what was submitted, and the first submission claims the request. A leaked link is therefore a denial of service rather than a disclosure: someone could occupy the slot and force you to issue a new link.

No. The key exists only in the fragment of that URL and is held in memory by the running process, so there is no escrow and no recovery path. If the link is lost or the fragment is stripped by a chat client or shortener, ask the human to submit again on a new link.

The request_secret tool takes a via parameter. modal opens a Pi dialog, link spawns the CLI and streams the one-time URL, and auto, the default, uses the dialog in the interactive TUI and a link everywhere else.

No. Modal mode collects the value straight from the keyboard into your .env file without starting a server or touching the network, so it works even when the pinchpass binary is not installed. In link mode the binary is resolved from PATH, ~/.local/bin, ~/.openclaw/bin, or ~/.pi/bin.

Not in modal mode: the value goes from the keyboard to disk and never enters the model's context or the session transcript. In link mode the value arrives as ciphertext, is decrypted by the CLI process locally, and is written to the file, so the tool result reports the saved path and key names rather than the value itself. See agent integration.

Each value is written as KEY="value" with backslashes, double quotes, dollar signs, and backticks escaped, so the file survives being sourced. An existing key is replaced in place and other lines are preserved. The file is written with 0600 permissions and parent directories are created with 0700.

-out config/secrets.env changes where the value is written, -ttl 5 sets the expiry in minutes, and -port 9999 pins the local port instead of picking a random one. The CLI reference lists every flag.

Releases cover Linux and macOS on amd64 and arm64, as raw binaries with no runtime dependencies. Building from source needs Go 1.26 or newer, and golang.org/x/crypto is the only dependency. Windows is not a published target. See install.

brew upgrade --cask pinchpass, npm update -g @pinchpass/cli, go install github.com/rubybear-lgtm/pinchpass@latest, or re-run the curl command for a prebuilt binary. Updating the npm package also replaces the downloaded binary, because the postinstall is version-aware.