[BUG] Pending background-task notification is absorbed into a slash command's <command-args> / $ARGUMENTS, corrupting the prompt and exposing raw internal tags

What's Wrong?

When a background-task notification (The user started your suggested background task ... in a separate local session) becomes pending at the same moment a slash command is dispatched, the notification's text is delivered as that slash command's argument payload instead of as its own message turn.

Three things follow from that single misroute:

1. <command-args> holds the full <system-reminder>…</system-reminder> notification text instead of the arguments the user actually typed (none, in the observed case).
2. If the invoked command/skill template contains an $ARGUMENTS placeholder, the notification text is substituted into the expanded prompt verbatim — so it reaches the model as if the user had typed it as the command's arguments. This is a content-corruption bug, not only a display artifact.
3. In the Claude Desktop app (Code tab), the raw <command-args><system-reminder>…</system-reminder></command-args> markup renders as user-visible chat content (a collapsible gray card) — internal harness plumbing surfacing in the transcript.

Elsewhere in the same session, identically-shaped background-task notifications are delivered normally as their own standalone <system-reminder> turn, separate from any command. That is what makes this look like a delivery race rather than the intended general path: the same notification shape has two different destinations depending on whether a slash command happened to be dispatched at that instant.

Evidence

Sanitized excerpt from a real session transcript (custom command renamed to /my-skill; task IDs, task descriptions, and skill body redacted):

[assistant] Two chips created — task_aaaaaaaa (...), task_bbbbbbbb (...).

[user] <command-message>my-skill</command-message>
<command-name>/my-skill</command-name>
<command-args><system-reminder>
The user started your suggested background task task_aaaaaaaa ("(task description)") in a separate local session. It is running independently. You will be notified here when it ends.
</system-reminder></command-args>

[user] Base directory for this skill: (redacted)
# my-skill — (redacted)
...
ARGUMENTS: <system-reminder>
The user started your suggested background task task_aaaaaaaa ("(task description)") in a separate local session. It is running independently. You will be notified here when it ends.
</system-reminder>

The second [user] block is the expanded command template: the same notification text has been substituted into the template's $ARGUMENTS slot.

Impact

• Prompt corruption — harness-generated notification text is presented to the model as user-authored command arguments. A command that parses, validates, or echoes its arguments will act on text the user never typed.
• Command semantics — a command invoked with no arguments behaves as if given a long argument string.
• Leakage — internal tags (<command-args>, <system-reminder>) render as chat content in the Desktop app.
• Possible loss of the notification's normal delivery — in the observed occurrence the notification appears only inside the command payload for that dispatch. Whether it is also delivered separately (i.e. whether this is a misroute or a duplication) is not determinable from the excerpt.

What Should Happen?

• A pending background-task notification should be delivered as its own turn, regardless of what else is dispatched at that moment.
• <command-args> should contain only user-typed argument text — empty when the user typed none — so $ARGUMENTS expands to what the user actually wrote.
• Internal harness markup (<command-args>, <system-reminder>) should never render as user-visible chat content.

Steps to Reproduce

This is a timing-sensitive race. The recipe below is the general form inferred from one observed occurrence in a real session transcript; it has not been re-verified live in a fresh session, and it may take several attempts to hit the window.

1. In session A, arrange for a background-task suggestion chip to exist (e.g. have the assistant propose a background task at the end of a turn).
2. In a separate session/window, start that background task, so a "background task started" notification is generated for session A.
3. At approximately that same moment, in session A, dispatch a slash command with no arguments — either a built-in such as /compact, or any custom command whose prompt template contains an $ARGUMENTS placeholder.
4. Inspect the resulting turn: <command-args> contains the notification's <system-reminder> text rather than being empty, the $ARGUMENTS placeholder in the expanded template is filled with that same text, and in the Desktop app the raw markup renders as a collapsible gray card in the chat.

Related

• #81080 — "Slash command typed during a pending background-task notification renders twice (echo + dispatch), looks like /compact ran twice". Same underlying race (a background-task notification pending delivery at the moment a slash command is dispatched), but a different symptom: there the command bar renders twice while the command still executes exactly once with no content change. This report is about the notification's text being routed into the argument payload and reaching the model prompt.

Claude Code Version / Platform

Claude Code 2.1.229 (Desktop reported falling back to installed version 2.1.227 on this launch), Desktop app shell 1.30096.1

Operating System

Windows

Terminal or Shell

Claude Desktop app, Code tab (not a terminal session)