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 SeaShell in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install SeaShellRelated guides
Atlas with AI21 Jamba Large 1.7 in 2026
Explore AI21 Jamba Large 1.7 with Atlas, the terminal-native AI coding agent. Leverage its 256,000 token context window for code search, but note its 4,096 token output limit and $2.00/$8.00 per Mtok pricing.
Atlas with GPT-5.4 nano in 2026
Explore Atlas with OpenAI's GPT-5.4 nano in 2026. This model offers a 400K token context window and $0.20/Mtok input pricing, ideal for high-volume, low-stakes coding agent tasks.
Atlas with GPT-OSS 20B (local via Ollama) in 2026
Evaluate Atlas with GPT-OSS 20B (local via Ollama) for your coding agent in 2026. This 20B open-weight model offers genuine reasoning and a 131,072 token context window, running on a 16GB GPU.
Atlas with Code Llama 34B (Ollama) in 2026
Drive Atlas with Code Llama 34B (Ollama) in 2026. This self-hosted, free model offers a 16K token context window and strong whole-function generation for developers.
Atlas with GPT-5.1 in 2026
Explore GPT-5.1's 400K context and $1.25/Mtok input pricing with Atlas in 2026. A powerful reasoning model, it integrates deeply with Atlas's agent workflow for developers.
Atlas with Llama 4 Maverick in 2026
Explore Llama 4 Maverick's 1M token context and open weights for Atlas in 2026. Understand its cost-effectiveness and tradeoffs for terminal-native AI coding.
Atlas with GPT-5.6 in 2026
Explore Atlas with OpenAI's GPT-5.6, featuring a 1.05M token context window and persistent reasoning. Understand its $5/$30 per Mtok pricing and how it excels in complex coding tasks for developers in 2026.
Atlas with Llama 3.2 1B (local via Ollama) in 2026
In 2026, drive Atlas's background tasks with Llama 3.2 1B (local via Ollama). This 1.3GB model offers a 128,000 token window and free self-hosted operation for offline housekeeping.