Error: Permission to use WebSearch has been auto-denied in dontAsk mode
Nothing broke. The tool exists, your account has it, the network is fine, and no request was sent anywhere — a tool call was checked against the permission rules this session is running under and refused before it ran. That rules out an outage, a bad API key, a quota problem and a missing feature, none of which produce a message naming a mode. The word doing the work is auto-denied: a decision was made without asking you, because the mode you are in is one that does not ask.
The mode is the decision, and WebSearch is incidental
A permission mode answers one question: what happens to a tool call that has no standing approval? There are only three possible answers — ask a human, allow it, or deny it. A mode built around not asking has to pick one of the other two for everything it has not been told about in advance, and denying is the only answer that is safe to make on a user’s behalf.
So the message is not really about WebSearch. WebSearch is just the first tool the model reached for that nobody had approved in advance. If you go and special-case WebSearch, the next unapproved tool produces the same line with a different noun. The thing to look at is the set of approvals this session carries, and whether that set matches the work you are asking it to do.
This reframing matters because it changes what a fix looks like. You are not repairing something; you are reconciling two things you configured separately — a session that was told not to interrupt anyone, and a task that needs permissions nobody granted it.
The denial is not the end of the run, which is the expensive part
Before you touch any configuration, go and read what the session did after the denial.
A refused tool is an outcome, not a crash. The model is told it cannot use that tool, and it carries on with what it has. That is usually correct behaviour — but it means a session that was supposed to check the web can produce a complete, fluent, confident answer built entirely from what it already knew, with this one line buried above it in the log. If you are reading this error after the fact in a CI log or a transcript, the answer that came out of that run is now suspect, and the denial is the smaller of your two problems.
That is the case for treating a denial as a signal worth surfacing rather than a line to grep away: it is the only evidence that the output was produced under different conditions than you intended.
Is retrying useful?
No. The mode is configuration, and configuration does not change between attempts.
Send the same request again in the same session and the same check runs against the same rules and returns the same answer, instantly, every time. There is no capacity to wait for, no backoff, no reset. If you have wrapped this in a retry loop, the loop produces nothing but a log full of identical denials at whatever rate your code allows.
The only thing that changes the outcome is a change you make deliberately: different approvals, a different mode, a different session, or a different task. Each of those is a decision, and the rest of this page is about making it the right one rather than the quickest one. Retrying after a change, on the other hand, is the confirmation step — but it has to be a new session, since the rules are resolved when the session starts.
Find out what put you in that mode
Start with /status, which shows the settings sources in effect for the current
session. Do not skip this: the fix depends entirely on where the rule came from,
and the four possible sources belong to different people.
| Source | File | Who owns it |
|---|---|---|
| Your own settings | ~/.claude/settings.json | you |
| Shared project settings | .claude/settings.json (committed to the repo) | your team |
| Project-local settings | .claude/settings.local.json | you, for this project |
| Managed settings | a system directory: /Library/Application Support/ClaudeCode/managed-settings.json on macOS, /etc/claude-code/managed-settings.json on Linux and WSL, C:\Program Files\ClaudeCode\managed-settings.json on Windows | whoever administers the machine |
Two details that cost people time. On Windows the legacy
C:\ProgramData\ClaudeCode\managed-settings.json path is not read, so a
file sitting there explains nothing. And a fresh installation creates no
settings file at all — ~/.claude/settings.json appears the first time you
change a stored option, and .claude/settings.local.json appears the first time
you grant a standing permission approval. If you cannot find a file, the rule
came from somewhere else: the way the session was launched, or a managed
configuration you did not install.
If /status names the managed-settings file among your active sources, stop
editing your own configuration. Anything you did not put there was put there
by whoever manages that machine, and the change you want is a conversation, not
a file edit. Check the official docs for how sources combine rather than
assuming a local edit wins.
Telling your case apart from the ones next to it
- Only unattended runs deny; the same task works interactively — the mode is doing its job. Nobody is present in the unattended run, so nothing can be asked. The gap is your pre-approved set.
- An interactive session denies without ever prompting you — a stored
setting or a launch option put you in a non-asking mode.
/statusnames the source. - Every tool is denied, not just this one — suspect a customization rather
than the mode.
claude --safe-modestarts with all plugins, MCP servers and hooks disabled. If the denials stop under safe mode, something you installed is making the decision; if they continue, it is the settings. - The denial names a tool you never expected this task to need — the model went somewhere you did not anticipate. Before granting anything, decide whether the task should have been reaching for the web at all.
Working within the control, by case
- The session should have had this tool — grant the approval in the scope that matches who needs it: the committed project settings if the whole team’s automation needs it, project-local if it is your machine and your workflow. Approvals recorded in advance are exactly what a non-asking mode is designed to consume.
- The run genuinely must not reach the network — the denial is correct, and the fix belongs on the other side: supply the information in the prompt, or fetch it in a step that runs before the session starts and pass the result in.
- The rule is your organisation’s — ask for the specific tool, for the specific project, with the reason you need it. A narrow request is answerable; “please turn off the restrictions” is not, and it asks someone to take responsibility for everything you might do next.
- You chose the non-asking mode yourself to stop the prompts — that was a trade, and this is its price. Re-decide it openly: either accept the prompts for this kind of work, or invest once in an approval list that covers it.
What not to do: do not disable the control globally to unblock a single task, and do not move the work to a machine that does not have the policy. A mode that never asks is normally in place precisely because nobody is there to ask — removing it does not add a reviewer, it just removes the record that the review never happened. The narrow approval is less work anyway, and it is the only version of the fix that still holds next month.
Confirming it, with the half everyone skips
Start a new session — not a resumed one — in the same mode, and run the exact command that failed. The tool should now run with no prompt and no denial.
Then run the half that makes the test falsifiable: invoke a tool you did not approve and confirm it is still denied. If everything now succeeds, you did not grant a permission — you turned the mode off, and you have changed the security properties of every future run in that project without meaning to. Two observations, one positive and one negative, are what distinguish a fix from an accident.
Related decisions that look like this one
- Error: Remote Control is not enabled for your account is the other kind of “no” — decided by your account rather than by this session’s configuration, which means no local change can affect it and the person who can is different.
- Error in hook callback hook_0: Tool permission stream closed is what a broken permission decision looks like instead of a deliberate one: code you supplied was asked to approve a tool and never answered. If safe mode made your denials disappear, read that page next.
- The AI coding error triage tool sorts on the question this page opens with — was this refused by policy, by your account, or by something that actually failed — which is the fork that decides who can help you.