# Atlas error: Not logged in. Run: atlas login (and Session expired) > Run `atlas login` and complete the browser flow, then confirm the stored auth entry is of type oauth, not api, because the session check rejects api keys. 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. ## Symptom An Atlas account operation fails with: Not logged in. Run: atlas login. If a token is already present but stale, the message instead reads: Session expired. Run: atlas login. ## Cause installation/syntora.ts requires an oauth-type auth entry before calling the Atlas release and account API. With no oauth entry, Atlas reports Not logged in. Run: atlas login. When an entry exists but the session check comes back non-ok, Atlas treats the session as expired and reports Session expired. Run: atlas login. ## Fix 1. Run `atlas login` and complete the browser flow. 2. If login itself fails, read the thrown message: it is the server's error_description, so read it before retrying. 3. Confirm the stored auth entry is of type oauth, not api, because the session check rejects api keys here. 4. Run `atlas login` again if the entry was an api key, so an oauth entry is stored in its place. 5. Retry the original command once the session is refreshed. ## 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. ## FAQ ### 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. --- Canonical HTML: https://runatlas.sh/resources/troubleshooting/atlas-not-logged-in Source of truth: aeo_pages row `/resources/troubleshooting/atlas-not-logged-in` (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.