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 SeaShell in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install SeaShellRelated guides
Atlas with CodeGemma 7B (Ollama) in 2026
Explore Atlas with CodeGemma 7B (Ollama), a free, self-hosted model ideal for precise code edits and fill-in-the-middle tasks. Leverage its 8K context window for local development.
Atlas with AllenAI Olmo 3 32B Think in 2026
Explore AllenAI Olmo 3 32B Think with Atlas, the terminal-native AI coding agent. Discover its fully open architecture, competitive $0.15/$0.50 per Mtok pricing, and 65,536 token context window for deep reasoning tasks.
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) in 2026
Explore Atlas with Qwen2.5-Coder 7B (local via Ollama) in 2026. This 7B model offers free, self-hosted AI coding on laptops with a 32K token context window, ideal for local development.
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) in 2026
Explore Atlas with Qwen3 14B (Ollama), a powerful, self-hosted model for architectural planning and mixed reasoning. Leverage its 40K context window for free.
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) in 2026
Explore Atlas with Qwen3 32B (Ollama), a powerful 32B dense model for complex coding tasks. Self-hosted and free, it offers 40K tokens for deep reasoning.