# Atlas: No pending OAuth flow for MCP server > Re-run `atlas mcp auth ` from the same Atlas process and finish the browser step without restarting, so the pending transport and code verifier still exist. Atlas fails the login with "No pending OAuth flow for MCP server: " 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 ` from the same Atlas process and completing the browser step without restarting Atlas. ## Symptom Finishing an MCP login fails with: No pending OAuth flow for MCP server: . Sometimes paired with: No code verifier saved for MCP server: . ## Cause Atlas stores the pending transport and PKCE code verifier per server name at the moment auth is requested. If Atlas restarted, or the callback arrives for a server that never entered needs_auth, that state is gone. ## Fix 1. Re-run `atlas mcp auth ` from the same Atlas process and complete the browser step without restarting Atlas. 2. Do not open a callback URL from a previous run; the code verifier from that run is no longer saved. 3. Verify the server name in the callback matches the key in your config exactly. 4. If the flow still fails, remove the stored auth entry for that server and start a clean login. ## Why Atlas says No pending OAuth flow for MCP server Atlas says "No pending OAuth flow for MCP server: " 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: ", 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 ` 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 `, 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 ` 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: ". 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 `. 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 ` 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. ## FAQ ### 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 ` 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 ` 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 ` 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 ` 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. --- Canonical HTML: https://runatlas.sh/resources/troubleshooting/mcp-no-pending-oauth-flow Source of truth: aeo_pages row `/resources/troubleshooting/mcp-no-pending-oauth-flow` (segment: Troubleshooting) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.