Why Claude Refuses to Do Things: Limits and Permissions

Claude refuses requests for four distinct reasons: the request crosses a safety or usage policy limit, Claude lacks a tool or capability needed for the task, the request involves a permission Claude has not been granted in its current setup, or the instruction is too ambiguous for Claude to follow reliably. Each type of refusal has a different cause and a different response.

Understanding which type you are seeing saves time and frustration. A tool like fenbs makes the approved scope and an assistant's role explicit before work begins, which reduces permission-related refusals from the start.

Safety and usage policy limits

Anthropic has trained Claude not to help with certain categories of request: content that could facilitate serious harm, detailed instructions for creating weapons, and others. These are not bugs or configuration issues. They are deliberate limits, and rephrasing the request will not change the answer if the underlying ask is the same.

These refusals tend to be clear and consistent. Claude will usually explain that it cannot help with the request. There is no workaround for a genuine safety limit, and looking for one is not a productive use of time.

Missing capabilities and tools

Claude is a language model. It can read and write text, reason, analyze, and use tools that are explicitly connected to it. It cannot browse the web unless given a browser tool, cannot send email unless connected to an email tool, and cannot read files unless they are pasted into the conversation or available through a connected file system.

When Claude says it cannot check something or access a resource, it is often describing a missing connection rather than a permanent limit. In Claude Code, for example, additional tools give it file system access and the ability to run commands. Different Claude surfaces have different tools available.

Permission gaps in agent setups

When Claude is operating as an agent with a defined role, such as in a code review setup, a project management tool, or a customer-facing product, it may be limited to specific actions. A refusal in this context means the task falls outside what the agent is permitted to do for the role it holds, not outside what Claude can do in general.

In fenbs, an assistant acts as the person who approved its connection, within that person's role and the access they granted. If a connected assistant refuses a task, the reason includes what permission is missing and the role it holds. That information tells you exactly what to change to unblock it.

Ambiguous or unclear instructions

Claude sometimes declines to act not because of a policy but because the instruction is ambiguous in a way that matters. If a request could mean two very different things and acting on the wrong interpretation would have consequences, Claude may ask for clarification rather than guess.

This is the most fixable type of refusal. Add detail to the instruction: name the specific file, specify the output format, state what should happen when a condition is not met. The more specific the request, the less room there is for a misread.

Making instructions clearer

When a refusal is ambiguity-driven, the fastest fix is to add the information Claude would need to act. Think through what a capable but literal reader would need to know: which file, which version, which output format, what to do if the condition is not met.

Splitting a compound request into separate instructions also helps. "Research this topic and draft a recommendation" combines two tasks with different outputs. Breaking it into two separate instructions gives Claude a clear stopping point for each part and reduces the chance of a midway ambiguity.

If Claude asks a clarifying question, answer it directly rather than rephrasing the original instruction. The question usually identifies the exact gap. Filling it in is faster than guessing what a different phrasing might resolve.

How to tell which type of refusal you have

Read the refusal message carefully. A safety refusal usually states that Claude cannot help with this kind of request. A capability refusal often says Claude does not have access to a tool or resource. A permission refusal in an agent setup names the specific permission and role. An ambiguity refusal asks a clarifying question or describes two possible interpretations.

How to do this with fenbs

1. Create a free account and add your project.
2. Write Decisions and rules that describe the assistant's approved scope before any session starts.
3. Connect Claude over MCP from Integrations and assign it a role with the appropriate access.
4. If Claude refuses a task, read the refusal message to identify the type: policy, capability, permission, or ambiguity.
5. Update the scope, access level, or task instruction as needed, then record the change as a Decision so future sessions start with the corrected scope.

A refusal that repeats across sessions often points to a standing gap in your setup rather than a one-off instruction problem. If Claude refuses the same type of task every time you ask, write a rule in your project context that pre-authorizes it. An assistant that sees "you are allowed to read and summarize meeting notes" will not ask for confirmation each session.

For background on what Claude is and what it can do, see what is Claude AI. For Claude Code-specific behaviors and permissions, see what is Claude Code.