Atlas fails an account operation with Not logged in. Run: atlas login because installation/syntora.ts requires an oauth-type auth entry before it will call the Atlas release and account API, and it reports Session expired. Run: atlas login when a token is present but the session check returns a non-ok response. The fix is to run `atlas login`, complete the browser flow, confirm the stored auth entry is of type oauth rather than api, and retry the original command.
Why does Atlas say Not logged in. Run: atlas login?
Atlas says Not logged in. Run: atlas login because installation/syntora.ts enforces 1 precondition: an oauth-type auth entry must exist before Atlas calls the release and account API. With no oauth entry stored, Atlas refuses the account operation up front, and `atlas login` is what stores one.
The check in installation/syntora.ts is a precondition, not a network call. Atlas looks for an auth entry of type oauth before it will talk to the release and account API at all, which is why the error appears instantly rather than after a timeout. A fresh machine, a cleared auth store, or a login that never completed all produce the same message. The remedy is the one printed in the error itself: run `atlas login` and finish the browser flow. Once the oauth entry exists, retry the command that failed and Atlas will proceed.
Why does Atlas report Session expired. Run: atlas login?
Atlas reports Session expired. Run: atlas login when a token is present but the session check returns a non-ok response. installation/syntora.ts treats any non-ok response as an expired session, the 2nd of 2 distinct states, the other being Not logged in when no oauth entry exists at all.
Session expired is the second of two distinct states, and the distinction is useful. Not logged in means no oauth entry exists. Session expired means an entry exists, Atlas used it, and the session check came back non-ok. Atlas does not attempt to silently refresh in that path, and it does not guess at why the server said no. Run `atlas login` again and complete the browser flow to replace the stale session. Then retry the original command. If the same message returns immediately after a successful login, read the login error text before retrying again.
How to fix Not logged in in Atlas
Fix Not logged in in Atlas by running `atlas login` and completing the browser flow, which is step 1 of the 5 documented steps. Then confirm the stored auth entry is of type oauth rather than api, because the check rejects api keys here, and retry the original command once the session is refreshed.
Order matters here. `atlas login` is the first move and clears the common case. If the login command itself throws, the message you see is the server's error_description passed through, so read it literally instead of retrying blindly. The third step catches a subtler misconfiguration: an auth entry of type api will not satisfy the check in installation/syntora.ts, which specifically requires an oauth-type entry. An api key stored where Atlas expects oauth produces Not logged in even though credentials appear to be present. Re-running `atlas login` replaces it with the oauth entry the check wants.
Does an api key work instead of atlas login?
An api-type auth entry does not satisfy Atlas account operations. installation/syntora.ts requires an oauth-type auth entry before calling the Atlas release and account API, and it accepts exactly 1 entry type, oauth, so an api entry still yields Not logged in. Run: atlas login.
Confusion arises because api keys are perfectly normal elsewhere in Atlas. For the release and account API specifically, installation/syntora.ts wants an oauth-type entry and nothing else. If you have configured an api key and still see Not logged in, the key is not the problem to debug: the entry type is. Run `atlas login`, complete the browser flow, and let Atlas store the oauth entry. Be honest about the caveat: swapping the entry type is the only path here, and there is no flag that makes the account API accept an api key instead.
What if atlas login itself fails?
When `atlas login` itself fails in Atlas, the thrown message is the server's error_description. Read that text before retrying, because Atlas passes it through verbatim rather than replacing it with a generic failure. That is step 2 of the 5 documented steps, and it names the actual refusal reason.
Retrying a failed `atlas login` without reading the message wastes time. Atlas surfaces the server's error_description directly, so the string in front of you is the authoritative reason the login was rejected, not an Atlas-side guess. Read it, act on what it says, and only then run `atlas login` again. Once the browser flow completes and an oauth-type auth entry is stored, retry the original command. Atlas is a terminal-native TUI rendered with SolidJS through the OpenTUI renderer, so the login prompt and the retry both happen without leaving the terminal, apart from the browser step itself.
How to verify the atlas login fix worked
Verify the Atlas login fix by retrying the original command once the session is refreshed. A successful run shows neither of the 2 messages, Not logged in. Run: atlas login and Session expired. Run: atlas login, which means installation/syntora.ts found an oauth entry and the session check returned ok.
Verification is the fourth documented step and it is worth doing deliberately. Rerun the exact account operation that failed, not a different one, because the check in installation/syntora.ts runs per call. If the command completes without either message, the oauth entry is present and the session check passed. If Session expired returns quickly after a login that appeared to succeed, the stored session is being rejected by the server, and the login error_description from the next `atlas login` attempt is the text that will tell you why.
How to fix it
- 01Run `atlas login` and complete the browser flow.
- 02If login itself fails, read the thrown message: it is the server's error_description, so read it before retrying.
- 03Confirm the stored auth entry is of type oauth, not api, because the session check rejects api keys here.
- 04Run `atlas login` again if the entry was an api key, so an oauth entry is stored in its place.
- 05Retry the original command once the session is refreshed.
Frequently asked questions
- How do I fix Not logged in. Run: atlas login?
- Run `atlas login` and complete the browser flow, then retry the original command. Atlas raises Not logged in because installation/syntora.ts requires an oauth-type auth entry before calling the Atlas release and account API, and completing the login stores that entry.
- What does Session expired. Run: atlas login mean in Atlas?
- Session expired means a token is present but the session check returned a non-ok response, which installation/syntora.ts treats as an expired session. Run `atlas login` again, complete the browser flow, and retry the original command.
- Why does Atlas say Not logged in when I already set an API key?
- An api-type auth entry does not satisfy this check. installation/syntora.ts requires an oauth-type auth entry before calling the Atlas release and account API, and the check rejects api keys here. Run `atlas login` so Atlas stores an oauth entry instead.
- What should I do if atlas login fails with an error?
- Read the thrown message before retrying. When `atlas login` fails, the message is the server's error_description passed through by Atlas, so it names the real reason the login was refused. Act on that text, then run `atlas login` again.
- Do I need to run atlas login on every machine?
- Yes, on any machine where no oauth-type auth entry is stored. installation/syntora.ts checks for that entry before it calls the Atlas release and account API, so a machine without one reports Not logged in. Run: atlas login until you complete the browser flow there.
- How do I confirm my Atlas session is valid again?
- Retry the original command once the session is refreshed. If it runs without printing Not logged in. Run: atlas login or Session expired. Run: atlas login, the oauth entry is present and the session check returned ok.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with CodeGemma 7B (Ollama): Fill-in-the-Middle on 8GB in 2026
CodeGemma 7B (Ollama) is Google's 5.0GB code model with fill-in-the-middle training and an 8K context, Free (self-hosted). Atlas setup and honest tradeoffs for 2026.
Atlas with AllenAI Olmo 3 32B Think: the fully open reasoning model in 2026
Run Atlas on AllenAI Olmo 3 32B Think in 2026: 65,536 token context, OpenRouter $0.15/$0.50 per Mtok, and the only weights, data, and training code you can audit.
Atlas for Angular in 2026
Adopt Atlas, the terminal-native AI coding agent, for your Angular projects in 2026. Enhance development with intelligent code search, secure local embeddings, and granular control over AI actions.
Atlas with Qwen2.5-Coder 7B (local via Ollama): the Laptop Setup in 2026
Qwen2.5-Coder 7B runs Atlas on a laptop with no discrete GPU: about 5GB at 4-bit, a 32,768 token context, and free self-hosted. Setup, limits, and when to upgrade.
Atlas for Fortran: fpm.toml, Explicit Interfaces, and fprettify in 2026
Atlas is a terminal-native AI coding agent for Fortran in 2026. It reads modules, explicit interfaces, and intent declarations, runs fpm test behind a prompt, and runs fprettify.
Atlas with Qwen3 14B (Ollama): the local planning model for 2026
Qwen3 14B (Ollama) in Atlas: dense 9.3GB weights, roughly 11GB to serve, 40K tokens (40,960) of context, Free (self-hosted), better at architecture than raw diffs.
Migrate a Deprecated API Across Every Callsite with Atlas (2026 Workflow)
How to migrate a deprecated API across every callsite with Atlas in 2026: the lsp tool's findReferences enumerates callers, todowrite tracks them, apply_patch migrates each one.
Atlas with Qwen3 32B (Ollama): dense reasoning over raw speed in 2026
Qwen3 32B (Ollama) in Atlas: dense 20GB weights on a 24GB card, 40K tokens (40,960) of context, Free (self-hosted). Slower than the MoE, steadier on hard problems.