The Atlas GitHub integration fails on missing or malformed inputs because cli/cmd/github.handler.ts validates its environment and inputs up front, before it runs anything. Set MODEL in the workflow env using the provider/model form, for example anthropic/<model-id>, make sure GITHUB_RUN_ID is present, provide a PROMPT input for the event types that require one, and grant the triggering user write access on the repository. Each of those five checks maps to one of the error messages Atlas prints, so the message tells you exactly which check failed.
Why does Atlas report Environment variable "MODEL" is not set
Atlas reports Environment variable "MODEL" is not set because cli/cmd/github.handler.ts validates the environment before it does any work. The handler requires MODEL to exist and to be in the format "provider/model", so an unset variable stops the GitHub run on its very first check in 2026.
The MODEL check is one of five up-front validations in cli/cmd/github.handler.ts. Atlas does not fall back to a default model when MODEL is absent, because a GitHub run that silently picks a model is worse than one that fails loudly. Declare MODEL in the workflow env block for the job or the step that invokes Atlas, and use the provider/model form, for example anthropic/<model-id>. If you set the variable at the repository level rather than in the workflow, confirm it is actually exported into the step environment and not just defined somewhere the job never reads.
How to fix Invalid model. Model must be in the format "provider/model"
Invalid model <value>. Model must be in the format "provider/model" means the Atlas GitHub handler received a MODEL value it could not parse. Atlas requires both halves, provider and model, separated by 1 slash. Write anthropic/<model-id> rather than a bare model id, and the check in cli/cmd/github.handler.ts passes.
Atlas's model identifiers always carry the provider. That is the same convention the TUI uses when you switch the active model and provider on the fly with favorites and recents, so the workflow value looks exactly like the value you would pick interactively. The most common mistakes are a bare model id with no provider prefix, a trailing space picked up from a YAML block scalar, or a value quoted in a way that leaves the quotes inside the variable. Print the value in a debug step before the Atlas step if the string looks correct but the check still rejects it.
Why Atlas says Environment variable "GITHUB_RUN_ID" is not set
Atlas prints Environment variable "GITHUB_RUN_ID" is not set when its GitHub handler cannot find GITHUB_RUN_ID in the environment. GitHub Actions sets GITHUB_RUN_ID automatically for every run, so in 2026 the error means the handler was invoked in a context that is not a real Actions run.
Because GITHUB_RUN_ID is supplied by GitHub Actions itself, you rarely need to set it by hand. Ensure the workflow runs in a context where GITHUB_RUN_ID is present. If you are invoking the same handler locally, in a container, or through a wrapper that scrubs the environment, the variable is simply gone and the check in cli/cmd/github.handler.ts trips. Confirm the step is a normal Actions step, not a nested process that starts with a cleaned environment, and confirm no custom env block is overwriting the run environment wholesale.
How to fix PROMPT input is required for <event> events
PROMPT input is required for <event> events means the Atlas GitHub handler was triggered by an event type that requires an explicit prompt, and none was given. Provide a PROMPT input for those event types, then re-run the workflow, and the validation in cli/cmd/github.handler.ts passes. In 2026 that stays an input problem, not a permissions problem.
Atlas does not guess what you want it to do. For the event types that require a prompt, the handler requires the PROMPT input to be supplied rather than inferring intent from the event payload. Add the PROMPT input to the Atlas step for those events. If a single workflow handles several event types and only some of them require a prompt, either supply a PROMPT for all of them or split the workflow so the events that need a prompt get one. The caveat is honest: the error names the event, so read the message rather than guessing which trigger is at fault.
How to fix User <actor> does not have write permissions
User <actor> does not have write permissions is a deliberate refusal, not a bug. The Atlas GitHub handler checks the collaborator permission explicitly and accepts exactly 2 levels, admin and write, on the repository before it will act, so an outside contributor triggering the workflow is stopped.
Grant the triggering user write access, or restrict the workflow to trusted actors. Atlas checks the collaborator permission explicitly because a GitHub-triggered agent that anyone can invoke is a supply chain problem, not a convenience. The same posture shows up throughout Atlas: every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs. If you want a broader group to be able to trigger runs, raise their repository permission through GitHub rather than trying to bypass the check, and keep the workflow scoped to actors you trust.
How to verify the fix worked
Verify the Atlas GitHub fix by re-running the workflow and watching the first seconds of the job. All 5 validations in cli/cmd/github.handler.ts run up front, so a job that gets past startup without printing any of the messages has satisfied MODEL, GITHUB_RUN_ID, PROMPT, and the permission check.
A successful run shows the Atlas step proceeding into actual work rather than exiting on a validation message. If a second message appears after you fix the first, that is expected: the handler surfaces the checks it reaches, so fixing MODEL can reveal a missing PROMPT behind it. Work through them in the order they appear. Once the job runs, Atlas behaves the way it does locally, reading git branches, status, and diffs, and staging and creating commits on your behalf inside the workflow.
How to fix it
- 01Set MODEL in the workflow env using the provider/model form, for example anthropic/<model-id>. A bare model id with no provider prefix produces Invalid model <value>. Model must be in the format "provider/model".
- 02Ensure the workflow runs in a context where GITHUB_RUN_ID is present. GitHub Actions sets GITHUB_RUN_ID automatically, so Environment variable "GITHUB_RUN_ID" is not set usually means the handler was invoked outside an Actions run.
- 03Provide a PROMPT input for the event types that require one. Atlas raises PROMPT input is required for <event> events when the event you triggered on needs an explicit prompt.
- 04Grant the triggering user write access to the repository, or restrict the workflow to trusted actors. Atlas checks the collaborator permission explicitly and requires admin or write.
- 05Re-run the workflow and confirm the job gets past the input validation in cli/cmd/github.handler.ts instead of exiting on the first check.
Frequently asked questions
- Why does my Atlas GitHub Action say Environment variable "MODEL" is not set?
- Atlas's GitHub handler in cli/cmd/github.handler.ts validates MODEL before doing any work, and it does not fall back to a default. Set MODEL in the workflow env using the provider/model form, for example anthropic/<model-id>.
- What format does the Atlas MODEL env var need?
- MODEL must be in the format "provider/model". A bare model id with no provider prefix raises Invalid model <value>. Model must be in the format "provider/model". Use the form anthropic/<model-id>.
- Do I need to set GITHUB_RUN_ID myself in the workflow?
- No. GitHub Actions sets GITHUB_RUN_ID automatically. If Atlas prints Environment variable "GITHUB_RUN_ID" is not set, the handler is running outside a real Actions run or in a wrapper that scrubbed the environment.
- How do I fix PROMPT input is required for <event> events in Atlas?
- Provide a PROMPT input for the event types that require one. Atlas does not infer a prompt from the event payload, so the Atlas step needs an explicit PROMPT for those events.
- Why does Atlas say User <actor> does not have write permissions?
- The Atlas GitHub handler checks the collaborator permission explicitly and requires admin or write on the repository. Grant the triggering user write access, or restrict the workflow to trusted actors.
- Can an outside contributor trigger the Atlas GitHub workflow?
- Not unless they have admin or write permission. Atlas checks the collaborator permission explicitly and refuses with User <actor> does not have write permissions otherwise, which is the intended behavior.
- Why does Atlas fail immediately instead of partway through the job?
- cli/cmd/github.handler.ts validates its environment and inputs up front. MODEL, GITHUB_RUN_ID, PROMPT, and the actor permission are all checked before Atlas starts work, so a misconfiguration exits at startup rather than mid-run.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with Claude Opus 4.1: The Pre Price Cut Opus in 2026
Claude Opus 4.1 runs Atlas on a 200K context at $15 per Mtok input, $75 per Mtok output, with a 32K output ceiling. Setup, cost warnings, and better alternatives.
Atlas for C++ in 2026
In 2026, C++ developers adopt Atlas, the terminal-native AI coding agent, to enhance productivity. Atlas offers secure, context-aware assistance for modern C++ projects, integrating with CMake and ensuring code quality
Atlas with Llama 3.2 3B (Ollama): The CPU-Only Floor for a Local Agent in 2026
Run Atlas on Llama 3.2 3B (Ollama): a 2.0GB model with a 128K context, free self-hosted. The realistic floor for an Atlas setup with no GPU at all.
Atlas vs OpenAI Codex CLI: Terminal AI Coding Agents in 2026
Comparing Atlas and OpenAI Codex CLI for terminal AI coding in 2026. Atlas offers a TUI, permission-gated tools, and BYO models, while OpenAI Codex CLI provides sandboxed execution and OpenAI model integration.
Atlas for Actix Web in 2026
Atlas is a terminal-native AI coding agent for Actix Web in 2026. It reads extractors and app_data, then runs cargo test and cargo clippy behind a prompt.
Atlas with MiniMax-M2.5-highspeed in 2026: Paying 2x for Latency
MiniMax-M2.5-highspeed runs Atlas at $0.60 per Mtok input and $2.40 per Mtok output, exactly double base M2.5, for identical weights and a 204,800 token context.
Atlas with Mistral Medium 3.5: The EU-Hosted Frontier Model (2026)
Mistral Medium 3.5 drives Atlas at $1.50 / $7.50 per Mtok on a 262,144 token window with a matching 262,144 output limit. The EU-hosted option for data residency.
Atlas for Flutter in 2026
Discover Atlas for Flutter in 2026. This terminal-native AI coding agent helps Flutter developers build apps faster and safer, integrating with widgets, state, and the Dart toolchain.