Atlas throws "AZURE_RESOURCE_NAME is missing, set it using env var or reconnecting the azure provider and setting it" because the azure provider loader found neither a resource name nor an explicit baseURL, and the fix is to export AZURE_RESOURCE_NAME in the shell that launches Atlas. You can also re-run atlas auth login for azure and supply the resource name when prompted, or set an explicit baseURL on the azure provider entry in atlas.json, which bypasses the check entirely.
Why does Atlas say AZURE_RESOURCE_NAME is missing
Atlas says "AZURE_RESOURCE_NAME is missing" because the azure provider loader checks for 2 things, a resource name or an explicit baseURL, and found neither. With both absent, the loader returns a provider whose getModel throws that exact message the moment you select an Azure model.
Atlas needs one of two things to address an Azure deployment: the resource name, or a baseURL that already encodes where to send the request. The azure provider loader accepts either. When you have configured neither, the loader does not fail loudly at that moment. It hands back a provider object that is fine to exist but cannot produce a model, and the error surfaces at getModel. That design is worth knowing because it explains the timing of the failure, which is the thing most people find confusing about this error.
Why the error appears when I select the model, not at startup
The AZURE_RESOURCE_NAME error appears when you first select an Azure model rather than at Atlas startup because the azure provider loader defers the failure. In 2026 the loader returns a provider whose getModel throws, so Atlas starts cleanly and the missing resource name only bites at first use.
Atlas loads providers without demanding that every one of them be fully configured, which is what lets you run Atlas with a dozen providers registered and credentials for two of them. The azure loader participates in that contract: no resource name and no baseURL means the provider still loads, but its getModel throws. So a session can look completely healthy until the moment you switch to Azure. If you were expecting a startup warning and did not get one, nothing is wrong with your installation. That is the intended behavior of the azure provider loader in Atlas.
How to fix AZURE_RESOURCE_NAME is missing in Atlas
Fix "AZURE_RESOURCE_NAME is missing" in Atlas by exporting AZURE_RESOURCE_NAME in the shell that launches Atlas. 2 alternatives work equally well: re-run atlas auth login for azure and supply the resource name when prompted, or set an explicit baseURL on the azure provider entry in atlas.json.
Pick the path that matches how you manage configuration. Exporting AZURE_RESOURCE_NAME is the fastest and is right for a local shell or a dotfile. Running `atlas auth login` for azure and entering the resource name when prompted stores it with the rest of the azure provider connection, which is the better fit if you already manage credentials through Atlas auth. Setting an explicit `baseURL` on the azure provider entry in atlas.json is the option for teams that already point at a specific endpoint, and it bypasses the resource-name check outright rather than satisfying it. All three clear the error. Only pick one, so the source of truth stays obvious.
How to verify the AZURE_RESOURCE_NAME fix worked
Verify the AZURE_RESOURCE_NAME fix in Atlas by restarting Atlas and re-selecting the Azure model. The azure provider loader reads its 2 sources, the environment and atlas.json, only at startup, so a shell export made after Atlas launched will not be visible until you restart.
Restart matters here more than in most fixes. If you exported AZURE_RESOURCE_NAME into a shell that Atlas is not running in, or exported it after Atlas started, the loader never sees it and the error repeats identically, which looks like the fix failed when it simply was not applied. After restarting, select the Azure model and send a message. A completion, with no "AZURE_RESOURCE_NAME is missing" thrown at getModel, confirms the azure provider now resolves a resource name or a baseURL. Atlas lets you switch the active model and provider on the fly with favorites and recents, so the confirmation takes one switch.
How to fix it
- 01Export AZURE_RESOURCE_NAME in the shell that launches Atlas, so the azure provider loader can read it from the environment.
- 02Or re-run `atlas auth login` for azure and supply the resource name when prompted.
- 03Or set an explicit `baseURL` on the azure provider entry in atlas.json, which bypasses the resource-name check.
- 04Restart Atlas and re-select the Azure model, so the provider loader re-reads the environment and the config.
Frequently asked questions
- How do I set AZURE_RESOURCE_NAME for Atlas
- Export AZURE_RESOURCE_NAME in the shell that launches Atlas, then restart Atlas so the azure provider loader re-reads the environment. Re-select the Azure model afterwards.
- Why does Atlas only throw AZURE_RESOURCE_NAME is missing when I pick an Azure model
- The azure provider loader returns a provider whose getModel throws when it finds neither a resource name nor an explicit baseURL. The failure therefore appears at first use rather than at Atlas startup.
- Can I use a baseURL instead of AZURE_RESOURCE_NAME in Atlas
- Yes. Set an explicit baseURL on the azure provider entry in atlas.json. The azure provider loader accepts a resource name or an explicit baseURL, so a baseURL bypasses the resource-name check.
- Does atlas auth login fix AZURE_RESOURCE_NAME is missing
- Yes. Re-run `atlas auth login` for azure and supply the resource name when prompted. That reconnects the azure provider with the resource name it needs.
- I exported AZURE_RESOURCE_NAME and Atlas still throws the error
- Restart Atlas and re-select the Azure model. The azure provider loader reads the environment at load time, so an export made after Atlas started, or in a different shell, is invisible to it.
- Is AZURE_RESOURCE_NAME an Atlas setting or an Azure one
- AZURE_RESOURCE_NAME is the environment variable the Atlas azure provider loader reads to address your Azure deployment. Atlas accepts it from the env, from atlas auth, or bypasses it with an explicit baseURL.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with AI21 Jamba Large 1.7 in 2026
AI21 Jamba Large 1.7 in Atlas, 2026: a hybrid SSM-Transformer with 256,000 tokens of context at $2.00/$8.00 per Mtok, capped at 4,096 tokens of output.
Atlas with GPT-5.4 nano: The $0.20 Background Model in 2026
GPT-5.4 nano is OpenAI's cheapest reasoning-capable model at $0.20 / $1.25 per Mtok with a 400K window. Built for the titles, summaries, and classification Atlas runs constantly.
Atlas with GPT-OSS 20B (local via Ollama): Local Reasoning on a 16GB Card in 2026
GPT-OSS 20B is OpenAI's open-weight reasoning model: 131,072 token context, runs on a single 16GB GPU, free self-hosted, or $0.075 / $0.30 per Mtok via Groq.
Atlas with Code Llama 34B (Ollama): The Practical Top of the Line in 2026
Code Llama 34B (Ollama) is 19GB, roughly 21GB to serve, with a 16K context and Free (self-hosted) pricing. Atlas setup, why 34B is the last sane size, for 2026.
Atlas with GPT-5.1: The Cheapest Full Size GPT-5 Input Price in 2026
GPT-5.1 in Atlas: 400K context, $1.25 per Mtok input and $10 per Mtok output, cheaper on input than every GPT-5 release that followed it in 2026.
Atlas with Llama 4 Maverick: 1M Context on Open Weights in 2026
Llama 4 Maverick gives Atlas a 1M token context on open weights at $0.24 / $0.97 per Mtok on Bedrock or $0.20 / $0.80 on DeepInfra. Setup, tradeoffs, and fit.
Atlas with GPT-5.6: OpenAI's 2026 Flagship in the Terminal
GPT-5.6 gives Atlas a 1,050,000 token context at $5 / $30 per Mtok. Atlas routes OpenAI through the Responses API so reasoning persists across tool calls in 2026.
Atlas with Llama 3.2 1B (local via Ollama): the 2026 offline small_model slot
Llama 3.2 1B (local via Ollama) in Atlas: a 1.3GB CPU-friendly pull with a 128,000 token window, Free (self-hosted), best wired to small_model, not model.