Agent credential issues
Fix agent auth failures.
Use this page when Claude Code, Codex, Cursor, OpenCode, or another agent can't authenticate, won't launch, or shows as needing setup.
Each agent reads credentials from one of two sources: your own login or API key, or the Proliferate gateway (managed credits, billed to your plan). You pick the source per agent in Settings → Agents → [agent] → Authentication.
Settings > Agents > Claude > Authentication
The per-agent authentication section: a Proliferate Gateway toggle, one or more API key rows with an env var name and a saved-key picker, an Add variable button, and (for local, login-capable agents) a Run login button that opens an inline terminal.
Check:
- The agent works outside Proliferate first. If
claude,codex, or the CLI you're using can't log in on its own, Proliferate can't fix that for you. - Local vs. cloud uses different material. A local workspace can read
your machine's native login state (
.claude/.credentials.json,.codex/auth.json, and similar). A cloud workspace only has what you synced or what the gateway provides. If an agent works locally but fails in the cloud, that's almost always the gap. - The gateway toggle matches what you intend. Turning on Proliferate Gateway for an agent routes its calls through Proliferate's managed credits instead of your own key. Turning it off without adding a working API key or synced login leaves the agent with nothing to authenticate with.
- The credential is scoped correctly. Personal credentials are yours alone. A teammate who shares a credential with your organization has to do that explicitly; you can't use someone else's login just because you're in the same org.
- The agent shows as ready, not "needs setup." Settings surfaces agents that still need attention in one place, with the specific missing piece (login, API key, or gateway access) called out per agent.
Settings > Agents, needs-configuration list
A list of agents that still need setup before they can launch chats, each row showing the agent name, a status badge (for example 'Login required' or 'Credentials required'), the expected credential or env var, and a Review setup button.
Cursor authenticates through its own native login only; there's no Proliferate Gateway or API key option for it.
If everything above checks out but the failure only happens in a cloud workspace, move on to cloud workspace issues. If it's specifically GitHub access (cloning, PRs, pushing) that's failing, that's covered separately in Git and PR issues.
For the full model behind gateway routing, BYOK, and OAuth, see gateway, BYOK & OAuth.