Atlas fails startup with the server returned a login page instead of JSON because the remote config endpoint sits behind an SSO or identity-aware proxy that answered with an HTML login page at HTTP 200. The fix is to run `atlas auth login <url>` with the login origin printed in the message, refresh the SSO session in a browser, and restart Atlas. Config.remote inspects the content-type and body of the fetched config, so it raises ConfigRemoteAuthError instead of a confusing decode failure.
Why does Atlas say the server returned a login page instead of JSON?
Atlas says the server returned a login page instead of JSON because Config.remote checks the content-type and body of the fetched config. An SSO or identity-aware proxy can answer with an HTML login page at HTTP 200, which passes filterStatusOk, so Atlas raises ConfigRemoteAuthError rather than a decode failure.
The subtlety is the HTTP 200. A proxy that intercepts an unauthenticated request usually does not return 401. It returns the login page with a success status, which is exactly why a naive status check is not enough. Config.remote in Atlas looks past the status at the content-type and the body, recognizes HTML where JSON was expected, and raises ConfigRemoteAuthError with a message that names the URL and tells you to run `atlas auth login <url>`. Authentication is missing or has expired, and Atlas says so plainly instead of surfacing a JSON parse error that would send you hunting the wrong problem.
How to fix ConfigRemoteAuthError in Atlas
Fix ConfigRemoteAuthError in Atlas by running `atlas auth login <url>` with the login origin printed in the message, which is step 1 of the 5 documented steps. Then refresh the SSO session in a browser, restart Atlas, and confirm the remote config URL serves JSON directly rather than redirecting to an identity provider.
Start with `atlas auth login <url>`, using the exact login origin Atlas printed in the failure message rather than a URL you guess at. If the session is simply stale, refreshing the SSO session in a browser and restarting Atlas is enough. If neither clears the error, the endpoint itself may be the problem: confirm the remote config URL serves JSON directly and is not behind a redirect to an identity provider. The stopgap, inlining the config locally, is honest and effective, because it removes the startup dependency on the proxied endpoint while you sort out the proxy.
Why does an HTTP 200 still fail in Atlas remote config?
An HTTP 200 still fails Atlas remote config because filterStatusOk passes it. Identity-aware proxies return the login page with a 200 status, so Config.remote inspects the content-type and body as well, and raises ConfigRemoteAuthError when it finds an HTML login page where the config JSON should be.
Treating 200 as success is what makes this class of failure so confusing elsewhere. A tool that trusts the status code hands the HTML body to a JSON parser and reports a syntax error at character 1, which tells the operator nothing useful. Atlas takes the extra step. Because Config.remote examines what actually came back, the error names the real condition: authentication is missing or has expired, and the endpoint is likely behind an SSO or identity-aware proxy. That is a debuggable statement, and the remedy, `atlas auth login <url>`, is printed with it.
Does the remote config URL need to serve JSON directly?
Yes. Atlas requires the remote config URL to serve JSON directly and not sit behind a redirect to an identity provider. Confirming that is a documented fix step, because an identity-aware proxy answering with an HTML login page at HTTP 200 is exactly the condition Config.remote reports as ConfigRemoteAuthError.
A remote config endpoint that redirects unauthenticated requests to an identity provider will work for a human in a browser and fail for Atlas at startup, because the browser follows the login flow and Atlas does not. Verify the URL by requesting it the way Atlas does and checking that the response is JSON, not HTML. If the endpoint must sit behind the proxy, keep the session fresh with `atlas auth login <url>`. If that is impractical, inline the config locally so startup does not depend on the proxied endpoint at all.
How to unblock Atlas startup without fixing the proxy
To unblock Atlas startup without touching the SSO proxy, inline the config locally so startup does not depend on the proxied endpoint. Inlining is the 4th documented step for ConfigRemoteAuthError, and it lets Atlas start immediately while the identity-aware proxy or the expired session is sorted out separately.
Inlining is a stopgap, and it deserves to be described as one. Copying the config into a local file removes the network dependency and gets Atlas running, but it also means the local copy will drift from whatever the remote endpoint serves next. Use it to keep working, not as a permanent arrangement. Once the SSO session is refreshed and `atlas auth login <url>` succeeds, point Atlas back at the remote config and confirm startup completes with no ConfigRemoteAuthError. Atlas connects to Model Context Protocol servers and exposes their tools to the agent, and those definitions often live in that same config, which is why getting the remote endpoint healthy again is worth the effort.
How to verify the remote config fix worked
Verify the Atlas remote config fix by restarting Atlas after running `atlas auth login <url>` and refreshing the SSO session in a browser. Startup succeeds with no ConfigRemoteAuthError, which means Config.remote received JSON rather than an HTML login page served at HTTP 200.
Restarting Atlas is the verification, because Config.remote fetches and inspects the endpoint at startup. A clean start means the content-type and body checks passed and real config JSON came back. If the error returns after a short period, the SSO session is expiring faster than your working sessions last, and the endpoint being behind an identity-aware proxy is the root condition to address. Re-running `atlas auth login <url>` each time is viable but tedious, so confirming the remote config URL serves JSON directly, without a redirect to an identity provider, is the durable fix.
How to fix it
- 01Run `atlas auth login <url>` with the login origin printed in the message.
- 02Refresh the SSO session in a browser, then restart Atlas.
- 03Confirm the remote config URL serves JSON directly and is not behind a redirect to an identity provider.
- 04As a stopgap, inline the config locally so startup does not depend on the proxied endpoint.
- 05Restart Atlas and confirm startup completes with no ConfigRemoteAuthError.
Frequently asked questions
- How do I fix the server returned a login page instead of JSON in Atlas?
- Run `atlas auth login <url>` with the login origin printed in the message, refresh the SSO session in a browser, and restart Atlas. Atlas raises ConfigRemoteAuthError when the remote config endpoint answers with an HTML login page instead of JSON.
- What is ConfigRemoteAuthError in Atlas?
- ConfigRemoteAuthError is the error Config.remote raises when the content-type and body of the fetched config indicate an HTML login page rather than JSON. Atlas raises it instead of a confusing decode failure, and the message tells you to run `atlas auth login <url>`.
- Why does Atlas remote config fail even though the request returns 200?
- An auth proxy can answer with an HTML login page at HTTP 200, which passes filterStatusOk. Config.remote in Atlas therefore checks the content-type and body too, and raises ConfigRemoteAuthError when the response is a login page rather than config JSON.
- Can Atlas load a remote config behind SSO?
- Yes, as long as the session is valid. Run `atlas auth login <url>` with the login origin printed in the message and refresh the SSO session in a browser. If the endpoint redirects to an identity provider instead of serving JSON directly, Atlas will keep failing at startup.
- How do I start Atlas when the remote config endpoint is unreachable?
- Inline the config locally so startup does not depend on the proxied endpoint. Inlining is the documented stopgap for the Atlas remote config auth failure, and it lets Atlas start while the SSO or identity-aware proxy problem is resolved separately.
- Does Atlas follow an SSO redirect for remote config?
- No. Atlas expects the remote config URL to serve JSON directly and not be behind a redirect to an identity provider. When a login page comes back instead, Config.remote raises ConfigRemoteAuthError and points you to `atlas auth login <url>`.
- How do I verify the Atlas remote config loads again?
- Restart Atlas. A startup with no Failed to load remote config message and no ConfigRemoteAuthError means Config.remote received JSON, so the SSO session and the `atlas auth login <url>` step both took effect.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with Poolside Laguna XS 2.1 in 2026
Poolside Laguna XS 2.1 in Atlas, 2026: the fast tier of Poolside's coding-native line at $0.06/$0.12 per Mtok on OpenRouter, holding 262,144 tokens of context.
Atlas with Qwen3.6 Plus: The Stable Million-Token Tier in 2026
Qwen3.6 Plus gives Atlas 1M tokens (1,000,000) of context at $0.50 per Mtok input and $3.00 per Mtok output, matching Qwen3.7 Plus while keeping 3.6 generation behavior.
Atlas with Qwen3-Coder Next (local via Ollama): the Top-Ranked Local Coder in 2026
Qwen3-Coder Next is the top-ranked local coding model of mid-2026: 262,144 token context, free self-hosted, or $0.22 / $1.80 per Mtok on Bedrock. Atlas setup and tradeoffs.
Atlas for Haskell in 2026
Atlas is a terminal-native AI coding agent for Haskell in 2026. Run it in a project with a .cabal file or a stack.yaml, let cabal build drive it, and review the diff.
Atlas with DeepSeek V3.2 (open weights): Sparse Attention at $0.38 Output, 2026
Run Atlas on DeepSeek V3.2 (open weights) in 2026. DeepSeek Sparse Attention gives 160K tokens (DeepInfra) at $0.26 per Mtok in and $0.38 per Mtok out.
Atlas with Gemma 3 27B Instruct on Amazon Bedrock: Flat Pricing, 202,752 Tokens (2026)
Gemma 3 27B Instruct in Atlas via Amazon Bedrock: $0.12 per Mtok input, $0.2 per Mtok output, a 202,752 token context, open weights, and an 8,192 token output cap.
Atlas with Gemma 3 12B Instruct: The Mid-Size Bedrock Gemma for 2026
Gemma 3 12B Instruct in Atlas via Amazon Bedrock: $0.05 per Mtok input, $0.10 per Mtok output, a 131,072 token context, and 12B dense weights you can self-host.
Atlas with OpenAI o4-mini (2026): Cheap Reasoning for Parallel Subagents
OpenAI o4-mini drives Atlas at $1.10 per Mtok input and $4.40 per Mtok output on a 200K context. A strict upgrade over o3-mini at identical price, with real tradeoffs.