Atlas tells the model The user rejected permission to use this specific tool call because Permission.ask parks the tool call on a Deferred until you reply, and replying reject fails it with PermissionRejectedError. This is working as designed: approve the call, or approve with `always` to add a rule. Replying with a correction instead fails the call with PermissionCorrectedError, which embeds your feedback into the message the model sees, so the message becomes The user rejected permission to use this specific tool call with the following feedback: <feedback>.
Why does Atlas say the user rejected permission to use this specific tool call?
Atlas reports The user rejected permission to use this specific tool call because Permission.ask parks the call on a Deferred until you reply, and replying reject fails it with PermissionRejectedError. Every Atlas tool call is gated against 3 kinds of rule, allow, ask, and deny, before it runs.
The message is not an error in the usual sense. Permission.ask suspends the tool call on a Deferred, meaning the call is held open, doing nothing, until a human answers. A reject answer resolves that Deferred by failing the call with PermissionRejectedError, and Atlas reports the outcome to the model in plain language so the model knows the call did not run and why. Seeing this message means the permission system did exactly what it exists to do.
What if I rejected the Atlas tool call by accident?
If you rejected an Atlas tool call by accident, re-ask. The model receives the rejection text and will normally retry, and 0 config changes are needed to recover, because Permission.ask simply failed that 1 Deferred. The next attempt raises a fresh prompt you can approve.
Accidental rejects are common and cheap to undo. Because the rejection message is delivered to the model rather than swallowed, the model knows the call did not run, and asking again generally produces the same tool call, this time with a prompt you can approve. Nothing about the rejected call is remembered as a rule. A bare reject affects one call only. If you want the approval to stick for future calls of the same kind, approve with `always` instead of approving once.
How to steer the model instead of rejecting an Atlas tool call
Use the Atlas correction path instead of a bare reject, which is step 3 of the documented fix. Replying with a correction fails the call with PermissionCorrectedError, which embeds your feedback verbatim, so the model reads The user rejected permission to use this specific tool call with the following feedback: <feedback>.
A bare reject tells the model only that the call was refused. A correction tells it why, and the feedback is passed straight through, unedited, into the message the model reads. That difference matters when the tool call was nearly right, for example the right command against the wrong path. Correcting with a sentence naming the right path is far more likely to produce a good second attempt than rejecting and hoping the model guesses. Treat the correction field as a channel to the model, because that is literally what PermissionCorrectedError makes it.
How to stop Atlas asking for permission on every tool call
To stop Atlas asking about a whole class of calls, add an allow rule under `permission` in config. Every Atlas tool call is gated against 3 kinds of rule, allow, ask, and deny, so an allow rule lets matching calls run without Permission.ask parking them on a Deferred.
Two ways exist to reduce prompting, and they differ in scope. Approving with `always` adds a rule from within the prompt, which is the convenient path when you are already looking at a call you expect to see repeatedly. Editing `permission` in config directly is the deliberate path, and it is the one to use when you know up front which class of calls should never prompt. Be honest about the trade: an allow rule removes the human checkpoint for everything it matches, so write it as narrowly as the work allows.
Is the permission rejection an Atlas bug?
The Atlas permission rejection is not a bug. Permission.ask parks the tool call on a Deferred until you reply, and a reject reply fails it with PermissionRejectedError by design. Every Atlas tool call is gated against 3 kinds of rule, allow, ask, and deny, so a rejected call is the system working.
The reason to say so plainly is that the message reads like a failure and lands in the model's transcript like one. Nothing is broken. The tool call was held, a human said no, and the call failed with PermissionRejectedError as designed. If the prompting itself is the problem, the answer is a permission rule and not a workaround. If the specific call was wrong, the correction path exists so you can say what was wrong. Both are supported paths, and neither requires reporting an issue.
How to verify the permission fix worked in Atlas
Verify the Atlas permission fix by re-running the request and confirming the tool call proceeds. After approving with `always` or adding 1 allow rule under `permission` in config, the matching call runs without Permission.ask parking it on a Deferred and without the rejection message reaching the model.
Re-running the request is the verification, because permission rules are evaluated before every tool call. A call that now runs without prompting means the allow rule matched. A call that still prompts means the rule did not match it, and the rule is narrower or differently shaped than the call. Read the tool call in the prompt and compare it against the rule you wrote. If the model still reports The user rejected permission to use this specific tool call, a reject reply is still being sent, so check who or what is answering the prompt.
How to fix it
- 01Recognize that this is working as designed: approve the call, or approve with `always` to add a rule.
- 02If you rejected by accident, re-ask, because the model receives the rejection text and will normally retry.
- 03Use the correction path to steer the model instead of a bare reject, since the feedback is passed straight through.
- 04To stop being asked for a class of calls, add an allow rule under `permission` in config.
- 05Re-run the request and confirm the tool call proceeds without the permission prompt.
Frequently asked questions
- How do I fix The user rejected permission to use this specific tool call in Atlas?
- Approve the call, or approve with `always` to add a rule. The message is working as designed: Permission.ask parks the tool call on a Deferred until you reply, and a reject reply fails it with PermissionRejectedError.
- I rejected an Atlas tool call by mistake. What now?
- Re-ask. The model receives the rejection text and will normally retry, and Atlas will prompt you again so you can approve. A bare reject affects only that one call and does not create a lasting rule.
- How do I give the model feedback when rejecting a tool call in Atlas?
- Use the correction path instead of a bare reject. Replying with a correction fails the call with PermissionCorrectedError, which embeds your feedback into the message the model sees, and the feedback is passed straight through.
- How do I stop Atlas from asking permission every time?
- Add an allow rule under `permission` in config, or approve with `always` from the prompt. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so an allow rule lets matching calls run without prompting.
- What is PermissionRejectedError in Atlas?
- PermissionRejectedError is the error that fails a tool call when you reply reject to an Atlas permission prompt. Permission.ask parks the call on a Deferred until you reply, and the reject reply resolves it as a failure the model is told about.
- What is the difference between reject and correct in an Atlas permission prompt?
- Reject fails the call with PermissionRejectedError and tells the model only that permission was refused. Correct fails it with PermissionCorrectedError and embeds your feedback into the message the model sees, so the model knows what to do differently.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with Phi-4 (local via Ollama): The 16K Context Tradeoff in 2026
Phi-4 (local via Ollama) drives Atlas at Free (self-hosted) pricing with a 16K tokens (16,384) window. Setup, the 14B reasoning case, and where it breaks.
Atlas with Kimi K2 0711: The Original Trillion-Parameter Preview in 2026
Run Atlas on Kimi K2 0711 in 2026. Moonshot's original K2 preview costs $0.60 per Mtok input, $2.50 per Mtok output, with a 128K tokens (131,072) context.
Atlas with GitHub Models in 2026: Free Model Access Behind a GITHUB_TOKEN
Run Atlas on GitHub Models in 2026: every model listed at $0/$0 per Mtok, auth with the GITHUB_TOKEN you already have, and 256,000 tokens on AI21 Jamba 1.5 Large.
Atlas vs Cline: Terminal AI Coding Agents in 2026
Compare Atlas and Cline, two leading AI coding agents for 2026. Atlas offers terminal-native TUI and permission-gated tools, while Cline integrates with VS Code and provides checkpoint rollbacks.
Atlas with Amazon Nova Lite in 2026: 300K Context on Your AWS Bill
Amazon Nova Lite drives Atlas at $0.06 per Mtok input and $0.24 per Mtok output with a 300K token context, billed through IAM with no new vendor API key to manage.
Atlas for Axum in 2026
Atlas is a terminal-native AI coding agent for Axum in 2026. It decodes tower trait-bound errors, adds IntoResponse types, and runs cargo nextest run.
Atlas for Scala in 2026
Atlas is a terminal-native AI coding agent for Scala in 2026. Run it in a project with a build.sbt, let it read your traits and implicits, and approve every diff.
Refactor a Legacy Module with Atlas in 2026
How to refactor a legacy module with Atlas in 2026: findReferences maps every callsite, apply_patch refuses to apply against a drifted file, and bash proves behavior.