"No response requested." emitted as the complete turn on non-empty user messages — 11 times in one Cowork session, self-sustaining after onset, only cleared by an app restart

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

In a single session of the Claude desktop app running in Cowork mode on model claude-opus-5 on 2026-08-26, the assistant emitted the exact string No response requested. as its complete turn, 11 times, in three runs of 7, 3, and 1. One session, heavy MCP tool use throughout.

Every one of the 11 was emitted in reply to a non-empty user message containing a direct request. Nothing found in-session cleared the condition; recovery required quitting and reopening the desktop application.

Environment

• Claude desktop app, Cowork mode
• Model: claude-opus-5
• Date: 2026-08-26
• Single session, heavy MCP tool use

Breakdown by the user message that received the null turn

| Verbatim user message | Count | Continuation string appended by harness? |
|---|---|---|
| I need an update | 6 | yes |
| You have exactly 5 seconds to ack | 2 | yes |
| a message granting explicit approval to file this bug | 1 | yes |
| a combined message repeating the above requests | 1 | NO |
| STOP | 1 | yes |

The appended string, when present, was Continue from where you left off. concatenated onto the user's own typed text.

Three findings

1. Every one of the 11 fired on a NON-EMPTY user message containing a direct request.
This is unlike the open issue #89265, which is scoped strictly to content-free auto-resume injections. There, the sentinel answers a prompt the harness generated by itself. Here, in all 11 cases, it answered text the user actually typed.

2. One occurrence had NO continuation string appended at all, and still produced a null turn.
So the appended continuation prompt is not the trigger. Once a run started it self-sustained on clean user input. This is consistent with the mechanism proposed in the closed issue #57195: the synthetic sentinel pollutes the transcript, and the model then replays it as genuine billed output.

3. Recovery required a full application restart.
The user had to quit and reopen the Claude desktop app. Two of the three runs did self-terminate, but the condition recurred, and the eventual fix was a restart. Nothing in-session was found to clear it.

Secondary observation (observation only, no causal link claimed)

Immediately before the first run, two consecutive assistant turns announced imminent work while containing no tool call: Doing that now. and The dispatch is in this message., each as the complete turn.

This is recorded because it sits adjacent to the onset in the transcript. No causal link is claimed or established, and it should not be read as a proposed cause.

Why this matters

Over the course of the session the user requested a status update six times, requested an explicit acknowledgment twice, and typed STOP once. Every single one of those messages received a null turn.

The failure is indistinguishable from a normally completed turn. There is no error, no indicator, no retry. The turn renders exactly as it would if the assistant had finished its work and had nothing further to say, so a user watching the session has no way to tell the two apart and no signal that anything needs doing.

No response requested. is not documented in Anthropic's public documentation as a valid assistant output, so a user cannot be expected to interpret it. In the product it reads as a deliberate refusal or a decision by the assistant. It is neither.

How this differs from what is already filed

I verified the state of each of these directly before filing.

• #89265 — open. The closest active report, and this is not a duplicate of it. #89265 is scoped strictly to the content-free auto-resume injection: the harness injects Continue from where you left off. on its own and the sentinel answers it, 17/17. This report is the opposite case. All 11 here answered messages the user typed, and one of them had no continuation string appended at all.
• #44875 — closed as not planned, and locked, so it cannot be commented on. It is the closest prior description of a consecutive run across real user turns. One difference matters: there, the user's STOP broke the run and got a real reply ("Stopped. What do you need?"). Here STOP itself received a null turn.
• #57195 — closed as completed, and locked. It proposes the transcript-pollution / model-replay mechanism that finding 2 above supports. The "completed" state is worth stating precisely, because it is misleading: it was closed by its own author 15 seconds after it was filed, with no maintainer comment, no linked PR, and no version named. The only comment on the thread is the automated lock notice. No fix is on record for it.
• #65969 — closed as completed, and locked; also closed by its own author, with "Filed in error — closing." It documented the purely synthetic case on VS Code / code-server (model: "<synthetic>", stop_reason: "stop_sequence", zero tokens), and explicitly noted that the next real user message always got a normal response. That is not what happened here: real user messages kept receiving the sentinel, repeatedly.
• #62558 — closed as not planned, labelled duplicate and stale, not locked. Its trigger was a tool rejection rather than a resume. Relevant overlap: that reporter states a memory rule ("NEVER respond with No response requested") and a UserPromptSubmit hook reminder both failed to prevent it.

Also verified as part of the same family, all closed and all locked: #53260 (not planned), #44459 (not planned), #37040 (completed — closed by its author with "The bug has a different root cause. Resubmitting."), #56247 (auto-closed as a duplicate of #44459), and #13973 (completed, auto-flagged as a duplicate of #11807, filed 2025-12-14).

Mitigations: what I searched for, and what I found

Before filing I read the comment threads on the issues above, searched CHANGELOG.md on main, and checked the public documentation.

• No maintainer has commented on any thread in this family. On #89265, #57195, #44875, #65969, #62558, #53260, #44459 and #37040, every comment is either github-actions[bot] or another reporter. #89265 has no comments at all. No workaround has been posted by anyone at Anthropic.
• CHANGELOG.md contains zero occurrences of the string "No response requested" in any version section from 0.2.21 through 2.1.247. The only entry that mentions the continuation string is 2.1.193 — "Fixed pinned background agents being re-prompted to 'Continue from where you left off' after every auto-update" — which concerns how often the prompt is injected, not the null turn. The changelog carries no dates, only version numbers.
• The nearest adjacent entries are 2.1.221 ("Fixed CLAUDE_CODE_RESUME_INTERRUPTED_TURN=0 not disabling interrupted-turn auto-resume; falsy values are now honored"), 2.1.236, 2.1.216, and 2.1.196. CLAUDE_CODE_RESUME_INTERRUPTED_TURN is the only knob anywhere near this behaviour, but it does not appear on the Claude Code settings documentation page, nothing on record connects it to the sentinel, and I could not establish any supported way to set a process environment variable for a Cowork session worker in the desktop app. I am not claiming it as a workaround.
• User-reported workarounds, all unverified, none applicable here: typing a fresh instruction by hand to break out (#89265, where the reporter typed "Resume"); typing STOP (#44875 — contradicted by this session, where STOP received a null turn); a memory rule forbidding the string, and a UserPromptSubmit hook reminder (#62558 — the reporter states both failed).
• I found no source, maintainer or user, claiming that /clear, starting a new session, disabling auto-compact, or avoiding --resume / --continue stops this. Those are in any case CLI affordances, and I could not show a Cowork equivalent for any of them in the desktop app.

Net result: I found no mitigation applicable to Cowork in the desktop app. The only thing that worked in this session was quitting and relaunching the application.

What Should Happen?

1. The model must answer the user's typed message. A non-empty user message carrying a direct request must never be answered with a null-turn sentinel.

1. A null-turn sentinel must never be emitted as a complete turn in response to user content — whether the string is synthesized by the harness or generated by the model.

1. A run of consecutive null turns should be detectable and surfaced client-side, rather than presenting as a sequence of normal completed turns. Today the client renders them identically to real replies, which is precisely what makes the failure invisible: 11 of them went by with no error, no indicator and no retry.

1. There should be an in-session recovery that does not require restarting the application. Quitting and relaunching the desktop app was the only thing that worked here, and that is not an acceptable recovery path for a user in the middle of a task.

Error Messages/Logs

Steps to Reproduce

There is no deterministic reproduction. This is a single observed session and I cannot make it happen on demand. Stating that plainly rather than inventing steps that would not work for you.

What is known from the one observed session:

1. Claude desktop app, Cowork mode, model claude-opus-5, 2026-08-26. One session, heavy MCP tool use throughout.
2. Immediately before onset, two consecutive assistant turns announced imminent work with no tool call in them (the secondary observation in the report above — listed as adjacent in the transcript, not as a cause).
3. A run of 7 consecutive No response requested. complete turns began.
4. That run self-terminated. Later a run of 3 occurred, then self-terminated. Later a run of 1 occurred. 11 in total.
5. All 11 landed on non-empty user messages containing a direct request: 6 on I need an update, 2 on You have exactly 5 seconds to ack, 1 on a message granting explicit approval to file this bug, 1 on a combined message repeating those requests, and 1 on STOP.
6. 10 of the 11 had Continue from where you left off. appended by the harness onto the user's own typed text. 1 did not, and still produced a null turn. That single case is the reason I do not believe the appended continuation prompt is the trigger.
7. Nothing tried in-session cleared the condition.
8. The user quit and reopened the Claude desktop app. That cleared it.

Conditions that may be relevant, offered without any claim that they are necessary or sufficient: a single long-lived session, heavy MCP tool use, and a run that had already started (each run continued across several clean user messages once underway).

I have not attached a transcript because the session contains unrelated private content. Happy to answer specific questions about the ordering of the runs or the surrounding turns.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude desktop app, Cowork mode (no CLI version string surfaced in-app; claude --version is not available from this surface)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Notes on the form fields above, for accuracy.

• This was filed from Cowork mode in the Claude desktop app on macOS, not from the Claude Code CLI, so several fields on this template are approximations:
• Claude Code Version — the Cowork surface does not expose a CLI version string and claude --version is not runnable from it, so I could not paste real output. Said so in the field rather than guessing a number.
• Terminal/Shell — set to "Other" because there is no terminal involved.
• Claude Model — set to "Opus"; the exact model id was claude-opus-5.
• Preflight "I am using the latest version" — checked because the form requires it to submit. The desktop app auto-updates, but I cannot read out a version to confirm that, so please treat it as unconfirmed rather than as an assertion.
• "Is this a regression?" — set to "I don't know". I have no evidence either way about earlier versions, and the string has reports going back to 2025-12 (#13973), so I did not want to claim a regression.

• Verification method. Every issue state, label, lock status, closing actor and closing reason cited in this report was read directly from the GitHub API on 2026-08-26, not from memory or from search-result summaries. The changelog claims were made against CHANGELOG.md on main as of the same date (top version 2.1.247). Where I could not verify something, I said so inline rather than omitting it.

• Duplicate detector. This form flagged potential duplicates while I was filling it out. I read the closest candidates and the whole No response requested. family before filing; the "How this differs from what is already filed" section above explains why I do not believe this is a duplicate of #89265 (the only open one), and why the closed ones are either locked, self-closed by their authors, or scoped to a different trigger.

• I can provide more detail on the ordering of the three runs and the turns around them on request.