Authentication and MCP: signing in is not a file key
Account session, device identity and MCP consent are three different things; here is how they fit together.
An account session authorizes online actions. The device identity binds signatures and file keys to one concrete installation. A confirmed sign-in alone therefore replaces neither the device trust nor the receive release of a server service. Native clients sign in through the browser and keep their credentials in the operating system's protected store; no secrets ship inside the app.
Remote MCP uses OAuth with deliberately granted device releases. Registering a client grants no file access by itself; access follows only from your consent and device releases. PKCE with S256 binds the code exchange; tokens are bound to the exact resource and audience. The sign-in takes place at the pipeit issuer, and the MCP endpoint provides the released tools. Consent, expiry and revocation stay part of the same central permission logic.
The baseline remote scope consists of list_targets, resolve_target, get_transfer_status and open_pipeit. A server configured with Cloud can additionally supply metadata tools and, separately authorized, content search and previews. Each Cloud-tool call requires explicitly selected Cloudspaces and the current scope, grants and Cloud authority, with expiry and revocation checked every time; metadata permissions alone give no contents. Cloud is server-readable and not end-to-end encrypted, and snippets or previews can reach the model provider. The hosted calls prepare_transfer, send_file and cancel_transfer never touch local files: sending from a local source requires the local client. open_pipeit opens the product interface; it does not mean that a cloud model may automatically read the local file system or upload chat files to arbitrary URLs. A local MCP file client, the remote MCP and a separately released cloud file bridge are different data paths.
Destination contexts are explicit too: a global default, a project context and a session default can resolve different destinations. A fully prepared job keeps its bound destination. Changes to defaults must not silently readdress transfers that are already running. To set it up, see Connect ChatGPT, Codex, Claude, Gemini and Grok.
Three terms, precisely
- Direct names the data path: no pipeit relay in between. Which link carries it, Wi-Fi Aware, the shared LAN or a routed internet path, is shown as the recorded method.
- Stream means bounded processing: a file is encrypted, sent and verified in chunks instead of being loaded whole; it does not mean zero local storage.
- A relay (server route) moves encrypted bytes it cannot read and still uses CPU, RAM and network bandwidth to do so.
Related guides
Connect ChatGPT, Codex, Claude, Gemini and Grok
Add pipeit as a remote connector, sign in with your pipeit account and choose which devices the assistant may use.
Build on pipeit: your own clients and the API
One shared contract for all clients, and a sensible order for building your own.
Encryption: file content, keys and signatures
Which standard algorithms protect a file sent from device to device, what each one does, and what the profile does not promise.