Your auth tokens don't touch us
5dive runs AI agents on a server you control. Your login to those agents goes straight to the model vendor. Anthropic, Google, OpenAI — whoever you’re paying. The token lands in a file on your machine. It doesn’t pass through us first. It doesn’t get a copy. It doesn’t get re-broadcast somewhere helpful.
That’s not a slogan. It’s how the CLI is built. And it’s how we want you to think about every agent platform you consider — not just ours.
what “no auth proxying” actually means
When you set up an agent with 5dive, the flow is the boring one.
5dive agent auth login claudeThat hands off to Anthropic’s official Claude Code CLI — specifically, the claude setup-token command. You get a URL. You open it in your browser. You complete the OAuth handshake on Anthropic’s auth server. Anthropic shows you a code. You paste it back into the terminal. The token lands in a file inside the agent user’s home directory, owned by that user, readable only by that user.
5dive is not in the middle of that handshake. There’s no shim that catches the token, no service that “manages” it, no analytics endpoint that gets pinged when it lands. The credential gets written to the agent user’s home directory — agent-yourname — and that’s where it stays.
The shape is similar for the other types, each using whatever login command its own vendor blessed: codex login --device-auth, gemini auth login, and so on. Each writes credentials into its own state directory inside its own Linux user. Each user is sandboxed from the others. None of them export anything back to us.
The CLI itself doesn’t phone home either. There’s no telemetry endpoint. No error reporter. No “improving our product” analytics ping. The only network traffic 5dive originates is the traffic you can see in the agent type’s own logs — the calls that agent makes to its model provider.
If we wanted to know anything about what’s happening on your server, we’d have to ask you.
why the design is this restrictive
It would be easier, in a lot of ways, to manage credentials centrally. We could let you log in once on our site, do the OAuth dance on our infrastructure, and pipe the resulting session to whichever agent you spawn. Most “AI agent platforms” do exactly that.
We don’t, for three reasons.
One — vendor terms. Anthropic, Google, and OpenAI are all clear that consumer subscription auth is meant for the person who logged in. The moment that token starts flowing through a third party’s infrastructure, you’ve moved from “using your subscription” to “letting someone else broker your subscription.” Vendors notice. They write policies. They eventually enforce. We don’t want our customers’ accounts inside that blast radius — even if today’s policy is permissive.
We wrote about how this played out for one specific case in we ditched openclaw for claude. The lesson there generalizes: consumer auth is not a stable foundation for somebody else’s platform.
Two — blast radius. If we held your credentials, we’d be one breach away from leaking them. We don’t want that exposure, and you don’t want to depend on us not having it. The boring answer — the credential lives where the credential is used — is also the answer with the smallest attack surface.
Three — control. The token is yours. Revoking it should not require our help. Rotating it should not require our help. Migrating off 5dive should not require us to “release” anything back to you. You log in directly; you log out directly. We are not a step in either flow.
There’s a softer fourth reason, too. We built 5dive because we wanted infrastructure that respected the user the way good Unix used to. Auth that lives on your machine, under your user, in your home directory, is just what that looks like in 2026.
what this means for the choice of agent
We ship six agent types: claude, codex, gemini, hermes, openclaw, opencode. They don’t all have the same auth shape, and they don’t all have the same long-term stability profile.
Here’s the honest cut:
| Type | Auth | Vendor stance | Best for |
|---|---|---|---|
claude | OAuth (Pro/Max) or API key | Official product from Anthropic | Production work, long ops sessions, anything you need to stay running |
codex | OAuth (device flow) or API key | Official product from OpenAI | Code-heavy work for OpenAI subscribers |
gemini | OAuth or API key | Official product from Google | Multi-modal, Google ecosystem |
hermes | OAuth (OpenAI /codex/device flow) or API key (BYO provider) | Independent third-party harness | Multi-provider fan-out, self-hosted models |
openclaw | OAuth (OpenAI /codex/device flow) or API key (BYO provider) | Independent third-party harness | Experimentation, multi-model fan-out |
opencode | API key | Independent | Self-hosted models, custom stacks |
Two things to read out of that table.
First — API-key paths (opencode, claude/codex/gemini in their key modes, and hermes/openclaw in BYO-provider mode) are the most stable long-term. API keys are explicitly meant to be used by software. There’s no policy question.
Second — the OAuth paths that go through third-party harnesses are where vendor policy has been most active. In April 2026 Anthropic restricted Claude Pro/Max OAuth to first-party tools, and both hermes and openclaw moved off Claude consumer subscriptions and onto OpenAI’s /codex/device flow. That keeps them shipping but inherits the same shape of exposure to a future OpenAI policy change. Anthropic’s legal and compliance page is the canonical reference for how vendors think about the pattern. We respect those positions. We still ship the agent types in question — because some of you want to experiment, and we’d rather you do it on infrastructure you control than on someone else’s.
Our recommendation for serious work is claude (in OAuth mode if you have a Pro/Max plan you’re already paying for, in API-key mode if you’re going to bill it as a business expense). Everything else is fine to experiment with. The platform doesn’t push you either way — it gives you the same agent lifecycle for all six.
what’s not on the table
Some things we want to be explicit about, because they come up in support threads on other tools and we don’t want anyone wondering:
- We don’t see your prompts. Whatever you send to your agent goes from your Telegram (or web UI, or
5dive sendcommand) directly into the agent’s tmux session on your VM. We don’t proxy that traffic. We don’t log it. We can’t read it. - We don’t see your agent’s outputs. Same reason.
- We don’t broker model calls. The agent talks to its model vendor directly using your token. Our infrastructure isn’t in the request path.
- We don’t keep a copy of your auth state. If you
5dive agent rm myname, the user is deleted and the credentials go with it. We don’t have a “recovery” backdoor because there’s nothing to recover from.
If you want to verify any of this, the CLI is open source. cmd_agent.sh is the file that owns agent creation. It’s about a thousand lines, well-commented, and you can read exactly what gets written where.
the bottom line
Auth is one of those things that, once you’ve built it wrong, is hard to back out of. We built ours the boring way on purpose: official CLIs, user-owned credentials, no proxying, no telemetry.
Your tokens belong to you. We didn’t want them. We don’t have them.
That’s the whole post.
Sources: 5dive CLI on GitHub, Anthropic Claude Code legal and compliance, we ditched openclaw for claude.