[MODEL] "NEVER generate or guess URLs" instruction causes model to withhold URLs entirely, not just prevent hallucination

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude refused a reasonable request

What You Asked Claude to Do

Various tasks that involve URLs:

1. Asked Claude Code to fetch a PDF URL that was written in a GitHub issue body (i.e., provided by the user in a prior message). Claude hesitated in chain-of-thought about whether it was "allowed" to use the URL, even though the system prompt says "You may use URLs provided by the user."

1. Asked Claude Code to help with a non-programming task (tax filing). Claude refused to provide the National Tax Agency's e-Tax website URL — a well-known government URL — because the system prompt restricts URLs to "helping the user with programming."

What Claude Actually Did

In case 1, Claude's chain-of-thought shows it second-guessing itself:

"I need to use this URL... but I'm told to NEVER generate or guess URLs..."

The URL was already present in the conversation (provided by the user in an issue body), yet the model treated using it as potentially violating the restriction.

In case 2, Claude simply refused to provide the URL, forcing the user to search for it themselves.

The pattern: the model interprets "NEVER generate or guess URLs" as "never output a URL string" rather than the intended "never hallucinate a URL that might not exist."

Expected Behavior

The instruction should prevent URL hallucination (making up URLs that don't exist), not prevent the model from:

• Using URLs the user has already provided in the conversation
• Providing well-known, stable URLs (official documentation, government sites, major platforms) when relevant to the user's task

The word "generate" is ambiguous — to a language model, all output is "generated." The current wording causes the model to treat any URL output as potentially violating the rule, even when the URL is known to be correct.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. In a conversation, paste a message containing a URL (e.g., a GitHub issue body with a link)
2. Ask Claude to fetch or use that URL
3. Observe chain-of-thought: Claude hesitates about whether it's "allowed" to use the URL

Or:

1. Ask Claude Code to help with a task outside software engineering
2. Ask for a well-known URL related to that task (e.g., government website, official documentation)
3. Claude refuses or hedges

Claude Model

Opus

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.70

Platform

Anthropic API

Additional Context

Related: #27607 covers the broader problem of non-SE task refusal. This issue focuses specifically on the URL restriction, which is a separate mechanism in the system prompt with a different root cause and fix.

The current system prompt wording is:

"You must NEVER generate or guess URLs for the user unless you are confident that the URLs are for helping the user with programming."

This has two independent problems:

1. "generate" is over-broad: To a language model, all output is "generated." The model interprets this as "never output a URL" rather than "never fabricate a URL." A clearer wording would target hallucination specifically (e.g., "Do not fabricate URLs — only provide URLs you are confident exist").
2. "for helping the user with programming" is unnecessarily narrow: When CLAUDE.md defines a broader role, the URL restriction should respect that scope, not hard-code a programming-only constraint.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)