[BUG] Desktop Code inserts platform-generated messages without isMeta flag, causing context loss and stray responses

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?

The Desktop client generates platform messages that enter the conversation without the isMeta: true flag, so the model treats them as real conversation turns. This causes two distinct problems depending on the trigger.

Bug 1: Stop button causes "No response requested." + context amnesia

When the user presses Stop to interrupt Claude mid-response, Desktop inserts a synthetic assistant message ("No response requested.") with model: <synthetic> and no isMeta flag. This message sits in the conversation as a real assistant turn. On the next user prompt, the model loses effective awareness of the session before the stop - it re-reads files it had been actively editing, re-dispatches exploration agents, and treats the task as if starting fresh.

Transcript evidence from a session where the user accidentally submitted an incomplete prompt, pressed Stop after ~16 seconds, then retyped:

line 970 | user      | isMeta=absent  | "1) The information hierarchy is wrong..." (incomplete)
line 974 | assistant | model=<synthetic>, isMeta=absent | "No response requested."
line 975 | user      | isMeta=absent  | [full 5-point feedback, retyped]
line 976 | assistant | model=real     | "Let me start by reading the current dashboard code..."

At line 976, Claude starts from scratch - reading code and dispatching exploration agents for a codebase it had been actively editing moments earlier. No compaction event, no /clear, nothing in the JSONL explains the context loss. The synthetic message appears to act as a context barrier.

Bug 2: Background task notifications injected as user messages

When a background command (run_in_background: true) completes or is killed, Desktop injects a <task-notification> XML block into the conversation as a user-role message with no isMeta flag. The model treats this as a real user message and responds to it, causing unnecessary API round-trips and stray output.

Observed in two separate sessions on the same day:

Session 1, line 958:
<task-notification>
  <status>killed</status>
  <summary>Background command "find ... -name '_tools'" was stopped</summary>
</task-notification>
→ Claude responded: "That's just a stale background task being cleaned up"

Session 2, line 328:
<task-notification>
  <status>killed</status>
  <summary>Background command "Start dashboard dev server" was stopped</summary>
</task-notification>
→ Claude responded: "The earlier dev server process has been killed..."

Both notifications have isMeta: absent. Compare with <local-command-caveat> messages (e.g. before /context or /effort commands), which correctly carry isMeta: true and are handled silently.

Common root cause: Platform-generated messages are inconsistently tagged with isMeta. Some platform message types (local-command-caveat) are correctly marked; others (synthetic stop responses, task notifications) are not, so they pollute the conversation context.

Hooks are not involved. Both bugs reproduce with all hooks disabled. Earlier investigation initially attributed the symptoms to hook interactions, but disabling all hooks confirmed the bugs are platform-level.

What Should Happen?

1. The synthetic "No response requested." inserted on Stop should either carry isMeta: true or not be inserted at all. It should not cause the model to lose context from before the stop.
2. <task-notification> messages should carry isMeta: true so the model does not respond to platform housekeeping as if it were a user message.
3. More broadly, all platform-generated messages should consistently carry isMeta: true.

Error Messages/Logs

From transcript JSONL (content sanitised, paths redacted).

**Bug 1 - Stop button sequence:**

line 968 | queue-operation | enqueue     | (incomplete prompt submitted)
line 969 | queue-operation | dequeue     |
line 970 | user            | isMeta=absent | incomplete prompt text
line 971 | last-prompt     |             | platform snapshot
         | [~16 seconds pass, user presses Stop]
line 972 | queue-operation | enqueue     | (retyped full prompt)
line 973 | queue-operation | dequeue     |
line 974 | assistant       | model=<synthetic>, stop_reason=stop_sequence | "No response requested."
line 975 | user            | isMeta=absent | full 5-point feedback
line 976 | assistant       | model=real  | "Let me start by reading..." (context lost)


The `model: <synthetic>` field confirms client-side generation. The model at line 976 re-explores the entire codebase it had been editing for the previous ~30 minutes.

**Bug 2 - Task notification (two sessions):**

Session 1, line 958:
type: user, isMeta=absent
content: <task-notification><status>killed</status>...</task-notification>
→ assistant responds to it (unnecessary round-trip)

Session 2, line 328:
type: user, isMeta=absent
content: <task-notification><status>killed</status>...</task-notification>
→ assistant responds to it (unnecessary round-trip)


For comparison, platform messages that work correctly:

type: user, isMeta=true
content: <local-command-caveat>...</local-command-caveat>
→ model correctly ignores

Steps to Reproduce

Bug 1 (Stop + context loss):

1. Open a session in Claude Code Desktop (Code mode)
2. Work on a multi-turn task so the model builds up working context (e.g. iterating on code across several exchanges)
3. Submit a prompt, then immediately press Stop
4. Retype and submit a new prompt
5. Observe: "No response requested." appears between the two prompts. The model's response treats the task as if starting fresh - re-reading files, re-exploring the codebase

Bug 2 (task notification noise):

1. Open a session in Claude Code Desktop
2. Give a task that uses run_in_background: true for a shell command
3. Let the background task complete or get killed (e.g. by launching a replacement process)
4. Observe: a <task-notification> appears as a user message and the model responds to it

Both bugs are Desktop-specific. CLI sessions handle stops and background task notifications without these issues.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

Unknown - #13973 reported the same "No response requested" symptom and was closed as fixed

Claude Code Version

Observed across 2.1.51, 2.1.76, 2.1.78 (Desktop). CLI 2.1.81 unaffected.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Investigation timeline:

| Date | Finding |
|------|---------|
| 2026-03-03 | "No response requested" first observed (no hooks configured, v2.1.51) |
| 2026-03-13 to 2026-03-18 | Symptoms initially attributed to hook interactions (SessionStart firing on resume events) |
| 2026-03-18 | Hook matchers tightened - reduced frequency but bugs persisted |
| 2026-03-21 | All hooks disabled. Both bugs confirmed via transcript analysis across 3 Desktop sessions. Root cause identified as missing isMeta flags on platform-generated messages |

Key evidence:

• model: <synthetic> with zero token usage confirms client-side generation (not a model behaviour)
• Both bugs reproduce with all hooks disabled
• <local-command-caveat> messages correctly carry isMeta: true - shows the platform has this capability but doesn't apply it consistently
• CLI: 0 occurrences across multiple sessions. Desktop: consistent reproduction

Related issues:

• #13973 - Same "No response requested" symptom (closed as completed, Dec 2025). May have regressed or never been fully fixed for Desktop
• #25435 - Confirms "Continue where you left off" is a Desktop auto-message (closed as duplicate)
• #32085 - Background agent resume issues (open)