[BUG] Interrupting a hung WebFetch with "Send now" is recorded as "User rejected tool use"

Status Open
Reported on v2.1.295
Maintainer reply None cached
Activity 0 comments · opened Oct 12, 2026

Environment

  • Claude Desktop for macOS 2.31226.1 (Code tab), Claude Code 2.1.295; also seen on 2.1.219
  • macOS 27.2

What's wrong

Sometimes WebFetch doesn't return. If the user interrupts it with Send now, for example to ask "are you stuck?", the CLI ends the pending WebFetch with the permission-rejection result instead of an interrupt:

  • toolUseResult: "User rejected tool use"
  • content: "The user doesn't want to proceed with this tool use. The tool use was rejected … STOP what you are doing and wait for the user to tell you how to proceed."

The model then tells the user they declined the fetch ("not stuck — the web request was rejected, so I stopped") and stops. The user didn't decline anything, and WebFetch never showed a permission prompt in these sessions.

Steps to reproduce

  1. In the Code tab of Claude Desktop, ask Claude to look something up on the web so it calls WebFetch.
  2. Wait until the WebFetch call has been pending for a while without returning (seen from ~30 s up to ~45 min).
  3. Type a message such as "are you stuck?" and press Send now.
  4. Look at the session transcript and at Claude's reply.

Actual

  • About 1–2 s after the message is queued, the WebFetch tool_result is written with toolUseResult: "User rejected tool use" and the rejection text above, followed by [Request interrupted by user for tool use].
  • Claude replies that the user rejected the web request.
  • This happened 12 times in my local transcripts between 2026-08-05 and 2026-10-11.

Expected

  1. When the user interrupts a running tool, the result should say it was interrupted, not that the user rejected it. Otherwise the model tells the user they made a decision they never made, and it avoids the tool afterwards.
  2. WebFetch should time out with an error and not hang indefinitely (possibly related: #86910).

Related: #100963, #97676, #83486

View original on GitHub ↗