Atlas denied the tool call because Permission.evaluate matched the tool against your merged ruleset and the last matching rule had the action deny, so the fix is to read the ruleset JSON that Atlas serialized into the error message, find the rule that matched, and change it from deny to ask or allow in the permission block of your config. Atlas never shows an approval prompt for a denied call, because every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs. If you hit the denial while the plan agent is active, do not loosen the rules; switch to the build agent instead.
Why does Atlas say a rule prevents this specific tool call
Atlas raises PermissionDeniedError when Permission.evaluate finds that the last rule matching your tool call carries the action deny. Every Atlas tool call is gated against 3 kinds of rule, allow, ask, and deny, so a deny short-circuits the call and 0 approval prompts are ever shown to you.
The message you see is not a bug report, it is a policy decision. Atlas evaluates the tool name and its pattern against the merged ruleset, and when the winning rule says deny, Atlas stops the call and tells the model: The user has specified a rule which prevents you from using this specific tool call. Here are some of the relevant rules <json>. The model then reports the denial back to you. Because the check happens before execution, nothing was run, nothing was written, and no file was touched. The ruleset JSON attached to the message is the useful part: Atlas serializes the relevant rules so you do not have to guess which of your config entries fired. Start there rather than editing config blindly.
How Atlas resolves permission rules and why the last match wins
Atlas resolves permissions by taking the last matching rule, not the most specific one. Permission.evaluate runs Wildcard.match across the merged ruleset in order, so 1 broad allow placed before a narrow deny will never override that deny. Rule order inside your config decides the outcome of every tool call.
Last-match-wins is the single most common source of confusion here. Developers frequently add an allow rule at the top of the permission block, re-run the tool, and get PermissionDeniedError again, because a later deny still matches and still wins. The merged ruleset is what Atlas evaluates, so rules from every layer of your configuration participate in that ordering. If you want a narrow allow to take effect, it has to come after the deny that is currently matching, or the deny has to go. Reading the serialized ruleset in the error message tells you exactly which entry is winning, which is faster than reasoning about the merge by hand. Match patterns are wildcard patterns, so a rule you intended to be narrow may be matching far more broadly than you expected.
How to fix a deny rule in your Atlas permission config
To fix a denied Atlas tool call in 2026, open the ruleset JSON that Atlas serialized into the error message, locate the rule that matched, then edit the `permission` block in your config to change that rule's action from deny to ask or allow. Two edits, no restarts, no flags.
Choosing between ask and allow is a real decision, not a formality. Setting the rule to ask means Atlas pauses and prompts you every time the tool call comes up, which keeps a human in the loop on anything sensitive. Setting the rule to allow means Atlas runs the tool without prompting, which is the right call for genuinely routine operations you have already decided to trust. Be honest about the tradeoff: a deny rule usually exists because someone, possibly you, decided the tool should never run in this context. Before you relax it, confirm the rule is actually wrong rather than merely inconvenient. If the rule is correct and the tool call is the problem, change what the agent is asking to do instead of changing the policy that stopped it.
Why plan mode denies edits and what to do instead of editing rules
Plan mode in Atlas denies every edit by design, so loosening permission rules is the wrong fix when the denial arrives during planning. Atlas drafts a plan in a read-only plan agent and asks before switching to a build agent, and 1 switch to that build agent is the intended route.
If the PermissionDeniedError shows up while the plan agent is active, the ruleset is doing its job. The plan agent exists to produce a plan without touching your working tree, and the edit denies are the mechanism that makes the read-only promise real. Adding a global edit allow to get past the message defeats the mode entirely and gives you a plan agent that silently writes files. The supported path is to finish the plan and switch to the build agent, which merges the default permissions rather than the plan agent's denies. Once you are on the build agent, the same edit that was denied a moment ago will proceed through the normal approval flow, where Atlas computes a unified diff for every file edit and surfaces it for approval before writing.
How to verify the permission fix worked in Atlas
Verify an Atlas permission fix by re-running the exact tool call that failed. A correct fix produces 1 of 2 outcomes: the call executes when the last matching rule is allow, or Atlas prompts you when that rule is ask. Seeing PermissionDeniedError again means a deny still matches last.
A repeat denial after an edit almost always means one of two things. Either the rule you changed was not the rule that was actually matching, in which case go back to the serialized ruleset JSON in the new error message and read it again, or you added an allow before the deny and last-match-wins ignored it. Confirm by comparing the JSON in the fresh error against the config you just edited. If the two disagree, your edit landed in a layer that is being overridden by a later one. When the fix is correct, the difference is immediate and unambiguous: an ask rule produces a visible approval prompt, and an allow rule produces tool output. There is no third, ambiguous state to interpret.
How to fix it
- 01Read the ruleset JSON in the denial message. Atlas serializes the relevant rules into the message, so the JSON shows exactly which rule matched.
- 02Open the `permission` block in your Atlas config and locate the rule you just identified in that JSON.
- 03Change that rule's action from deny to ask, so Atlas prompts you, or to allow, so Atlas runs the tool without prompting.
- 04Remember that the last matching rule wins. A broad allow placed before a narrow deny will not override the deny, so move or delete the deny rather than stacking an allow in front of it.
- 05If the denial happens while you are in plan mode, edit is denied by design. Switch to the build agent instead of loosening the ruleset.
- 06Re-run the exact tool call that failed and confirm Atlas either executes it or prompts you, rather than raising PermissionDeniedError again.
Frequently asked questions
- what does the user has specified a rule which prevents you from using this specific tool call mean
- That message means Atlas evaluated your tool call against the merged permission ruleset and the last matching rule had the action deny. Atlas raised PermissionDeniedError before running the tool and serialized the relevant rules into the message so you can see which one matched.
- how do I allow a tool that Atlas keeps denying
- Read the ruleset JSON in the denial message to find the rule that matched, then edit the `permission` block in your Atlas config and change that rule's action from deny to allow. If you want a prompt instead of silent execution, set it to ask.
- why does my allow rule not override the deny in Atlas
- Atlas takes the last matching rule, not the most specific one. Permission.evaluate runs Wildcard.match over the merged ruleset in order, so a broad allow placed before a narrow deny does not override it. Move the allow after the deny, or remove the deny.
- why is Atlas denying edits in plan mode
- Plan mode denies edit deliberately. Atlas drafts a plan in a read-only plan agent and asks before switching to a build agent, and the deny rules are what keep the plan agent read-only. Switch to the build agent rather than loosening the ruleset.
- does Atlas prompt me before a denied tool call runs
- No. A deny rule means no prompt at all. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and only ask produces a prompt. A deny raises PermissionDeniedError and the tool never executes.
- where is the permission block in the Atlas config
- Permission rules live in the `permission` block of your Atlas config. Atlas merges the rules from your configuration layers into a single ruleset, and Permission.evaluate matches tool calls against that merged set with Wildcard.match.
- how do I know which Atlas permission rule denied my tool call
- Atlas serializes the relevant ruleset into the PermissionDeniedError message. Read that JSON and it shows exactly which rule matched. Do not guess from your config, because the merged ruleset and last-match-wins ordering can produce a different winner than you expect.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with Qwen Flash: A Cheap Tier That Still Writes Real Diffs in 2026
Run Atlas on Qwen Flash in 2026. Alibaba's fast tier pairs 1M tokens (1,000,000) of context with a 32,768 token output at $0.05 per Mtok in, $0.40 per Mtok out.
Atlas with Devstral 2: Mistral's Agent-First Coding Model in 2026
Devstral 2 in Atlas: Mistral's agent-trained coding model with a 262,144 token window at $0.40 / $2 per Mtok, loaded through @ai-sdk/mistral. Setup and tradeoffs.
Atlas with Qwen3 235B-A22B: Flagship Sparse Reasoning in 2026
Qwen3 235B-A22B in Atlas: 235B total parameters, 22B active per token, $0.70 per Mtok input and $2.80 per Mtok output, 128K tokens (131,072) of context.
Atlas vs Greptile: Terminal AI Coding Agents in 2026
Comparing Atlas and Greptile in 2026. Atlas offers terminal-native AI coding with permission-gated tools. Greptile reviews code with sandbox execution, catching 20% more bugs.
Atlas with GPT-5: The Original 400K Reasoning Model in 2026
GPT-5 in Atlas: the August 2025 launch model with a 400K context, 128K max output, and $1.25 per Mtok input, still the floor price for a full size GPT-5 class model.
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 Poolside Laguna XS 2.1 in 2026
Poolside Laguna XS 2.1 in Atlas, 2026: the fast tier of Poolside's coding-native line at $0.06/$0.12 per Mtok on OpenRouter, holding 262,144 tokens of context.
Atlas with Qwen2.5 7B Instruct in 2026: The Cheap Dense Small Model
Qwen2.5 7B Instruct runs Atlas's small_model slot at $0.175 per Mtok input and $0.70 per Mtok output, keeping the full 131,072 token window on a dense 7B checkpoint.