Atlas fails the login with "No pending OAuth flow for MCP server: <name>" because Atlas stores the pending transport and the PKCE code verifier per server name at the moment auth is requested, and that state is gone if Atlas restarted or the callback arrives for a server that never entered needs_auth. Fix it by re-running `atlas mcp auth <name>` from the same Atlas process and completing the browser step without restarting Atlas.
Why Atlas says No pending OAuth flow for MCP server
Atlas says "No pending OAuth flow for MCP server: <name>" because it stores the pending transport and the PKCE code verifier per server name at the moment auth is requested, and that state lives inside 1 Atlas process. After a restart, or for a server that never entered needs_auth, the state is gone.
The pending OAuth state in Atlas is keyed by server name and lives for the duration of a single Atlas process. Nothing about it survives a restart. That is why the companion error, "No code verifier saved for MCP server: <name>", so often appears alongside it: the PKCE code verifier was held in the same place and vanished with the rest of the pending flow. A callback with no matching pending flow cannot be completed, because Atlas has neither a transport to attach the token to nor a verifier to prove the exchange belongs to it.
How to fix No pending OAuth flow in Atlas
Fix the Atlas "No pending OAuth flow" error in 4 steps: re-run `atlas mcp auth <name>` from the same Atlas process, complete the browser step without restarting Atlas, avoid opening any callback URL from a previous run, and verify the server name in the callback matches the config key exactly.
The whole fix comes down to keeping one Atlas process alive across the entire login. Run `atlas mcp auth <name>`, let the browser open, complete consent, and let the callback land, all without restarting Atlas or killing the terminal session. Atlas holds the pending transport keyed by server name until the callback arrives, and that key exists only inside the running process. If you closed Atlas at any point between starting the flow and finishing consent, the flow is gone and the callback will be rejected no matter how valid the authorization code is.
Why an old callback URL fails in Atlas
Opening a callback URL from a previous Atlas run always fails, because the PKCE code verifier from that run is no longer saved. Atlas keys the verifier by server name inside the 1 process that started the flow, so an old callback has no verifier to pair with and the exchange is refused.
Browser history makes this an easy mistake. The callback URL from yesterday's `atlas mcp auth` attempt still looks perfectly valid, and clicking it feels like resuming where you left off. It is not. The Atlas process that generated the code verifier for that flow is gone, and with it the only thing that could complete the exchange. Start over: run `atlas mcp auth <name>` again to create a fresh pending flow with a fresh verifier, and complete consent from the newly opened browser page rather than from anything in your history.
Check that the MCP server name matches your Atlas config
Verify the server name in the callback matches the key in your Atlas config exactly. Atlas stores the pending transport and PKCE code verifier per server name, so a name off by 1 character, by case, or by a stray hyphen finds no pending flow and produces "No pending OAuth flow for MCP server: <name>".
The name is a lookup key, not a label. Atlas uses the exact string from your config as the key for the pending transport and the code verifier, and the callback has to arrive under that same string to find them. Open your Atlas config, copy the mcp entry key character for character, and pass that to `atlas mcp auth <name>`. Comparing the name printed in the error message against the key in your config side by side settles it in seconds and rules out an entire cause before you go looking at browsers or processes.
How to start a clean MCP login in Atlas
If the Atlas OAuth flow still fails after a same-process retry, remove the stored auth entry for that MCP server and start a clean login, which is step 4 of the documented fix. A stale stored entry can leave the callback finding no pending flow, and clearing it forces the whole OAuth path to run from the beginning.
Starting clean is the last documented step for a reason: it discards whatever partial state accumulated across failed attempts. Remove the stored auth entry for that server, then run `atlas mcp auth <name>` in a running Atlas process and complete consent in one pass. Verify with `atlas mcp` afterwards. The status row for the server should reach connected. If it lands back at needs_auth, the flow started correctly but the callback still did not complete, and the next thing to check is whether the callback is reaching the Atlas process at all.
How to fix it
- 01Re-run `atlas mcp auth <name>` from the same Atlas process and complete the browser step without restarting Atlas.
- 02Do not open a callback URL from a previous run; the code verifier from that run is no longer saved.
- 03Verify the server name in the callback matches the key in your config exactly.
- 04If the flow still fails, remove the stored auth entry for that server and start a clean login.
Frequently asked questions
- What does "No pending OAuth flow for MCP server" mean in Atlas?
- Atlas stores the pending transport and PKCE code verifier per server name at the moment auth is requested. The error means that state is gone, because Atlas restarted or the callback arrived for a server that never entered needs_auth.
- How do I fix No code verifier saved for MCP server in Atlas?
- Re-run `atlas mcp auth <name>` from the same Atlas process and complete the browser step without restarting Atlas. The code verifier is held per server name inside the running process and is not restored after a restart.
- Can I finish an Atlas MCP login after restarting Atlas?
- No. Restarting Atlas discards the pending transport and the PKCE code verifier for that server name. Start over with `atlas mcp auth <name>` and complete the flow in one pass without restarting.
- Why does an old MCP callback URL not work in Atlas?
- Because the code verifier from that run is no longer saved. Atlas keyed it to the process that started the flow. Re-run `atlas mcp auth <name>` and use the fresh browser page instead of a URL from history.
- Does the MCP server name matter for atlas mcp auth?
- Yes, exactly. Atlas keys the pending transport and code verifier by server name, so the name in the callback must match the key in your config character for character or no pending flow will be found.
- How do I start a clean MCP OAuth login in Atlas?
- Remove the stored auth entry for that server, then run `atlas mcp auth <name>` in a running Atlas process and complete consent in one pass. Check the result with `atlas mcp`.
- How do I confirm the MCP OAuth flow finally worked in Atlas?
- Run `atlas mcp` and read the status row for that server. It should reach connected. A row still showing needs_auth means the callback did not complete the exchange.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas vs Codebuff: Terminal AI Coding Agents in 2026
Atlas and Codebuff are terminal AI coding agents for 2026. Compare Atlas's terminal-native TUI, permission-gated tools, and diff review with Codebuff's multi-agent system and flexible pricing.
Atlas for Astro: Islands, Content Collections, and Zero JS by Default in 2026
Atlas is a terminal-native AI coding agent for Astro in 2026. It reads astro.config.mjs, src/pages, and content collection schemas, drops needless client:load directives, and runs astro check.
Atlas with Mistral Medium 3.5: The EU-Hosted Frontier Model (2026)
Mistral Medium 3.5 drives Atlas at $1.50 / $7.50 per Mtok on a 262,144 token window with a matching 262,144 output limit. The EU-hosted option for data residency.
Atlas with Qwen2.5-Coder 14B (Ollama): a real local build agent in 2026
Qwen2.5-Coder 14B (Ollama) in Atlas: 9.0GB of Q4_K_M weights, roughly 11GB to serve, 32K tokens (32,768) of context, Free (self-hosted), steady on tool chains.
Atlas vs Ellipsis: Terminal AI Coding Agents in 2026
Compare Atlas, a terminal-native AI coding agent with free core and local embeddings, against Ellipsis, a cloud platform with usage-based pricing and live session tracing for 2026.
Atlas for React in 2026
Adopt Atlas, the terminal-native AI coding agent, for React development in 2026. Enhance your workflow with intelligent code search, refactoring, and testing for React components and hooks.
Atlas with Devstral Small 2: A Free Coding Agent Model in 2026
Devstral Small 2 in Atlas: listed at $0 / $0 per Mtok on Mistral's labs endpoint with a 256K window, or run 24B locally at roughly 14GB via ollama pull devstral.
Atlas with QwQ 32B (Ollama): a free local reasoning model for the plan agent in 2026
QwQ 32B (Ollama) in Atlas: Qwen's dedicated reasoning model at 20GB, 40K tokens (40,960) of context, Free (self-hosted). Let QwQ plan, then hand off to a coder.