Bug: Stale skill ARGUMENTS from prior session replayed as system-reminders after compaction, causing assistant to act on old instructions

Resolved 💬 4 comments Opened Apr 19, 2026 by Hazron8 Closed Apr 24, 2026

Bug: Stale skill ARGUMENTS from prior session replayed as system-reminders after compaction, causing assistant to act on old instructions

Summary

When a Claude Code session is compacted (context-window summary + resume) and the previous session had invoked a skill with a long, instruction-shaped ARGUMENTS string, that ARGUMENTS text is replayed in <system-reminder> blocks on the next turn. Because the text reads like a directive, the assistant can mistake the stale reminder for a new user instruction and start executing it — even though the user never typed it in the current turn.

Environment

  • Claude Code CLI (interactive session)
  • Model: Claude Opus 4.7 (claude-opus-4-7)
  • Session was resumed after automatic context compaction

Repro Steps

  1. In an interactive session, invoke a custom skill (one that takes free-form arguments — e.g. a /feedback NNN style skill where NNN is a project ID and the project file body contains long prose instructions). The skill body and the ARGUMENTS: line both end up in the conversation context.
  2. Let the conversation continue until the runtime triggers automatic compaction.
  3. After resume, the runtime replays the loaded skills, tool results, and ARGUMENTS lines as <system-reminder> blocks at the top of the next turn.
  4. Type any short, unrelated message — e.g. /backlog or just a follow-up question.
  5. Observe: the assistant may begin executing the prior ARGUMENTS text as if it were a fresh user request.

In my case, an old /feedback 204 invocation had pulled in a project file (#205) whose body included a paragraph that read like a direct ask ("consult these agents and debate folder structures, return 3-5 recommendations…"). Three turns later, when I typed only /backlog, the assistant started spawning subagents to act on the #205 instructions because the ARGUMENTS line for that earlier invocation was replayed verbatim in a system-reminder.

Expected Behavior

One of:

  • (a) The runtime strips or neutralizes stale ARGUMENTS strings from replayed system-reminders on resume, OR
  • (b) Skill ARGUMENTS are surfaced in a structurally distinct way (not as free-form text that mimics a user instruction), OR
  • (c) The replay clearly labels them as "previously loaded" so the assistant has an unambiguous signal not to act on them.

Actual Behavior

The replayed ARGUMENTS text is indistinguishable from a current user instruction in the assistant's context, and the assistant can act on it without the user having typed anything that round.

Frequency

Reproducible across multiple sessions. The user reported it had happened "several times" with the same project file, suggesting any project whose content reads like an instruction will trigger it after compaction.

Impact

  • Assistant performs work the user did not authorize in the current turn
  • Wastes tokens on subagents the user didn't ask for
  • Erodes trust — user has to interrupt and clarify "I didn't ask you to do that"
  • Particularly bad for skills that pass project-file content as ARGUMENTS, which is a common pattern for PM-style workflows

Suggested Mitigations

Runtime side:

  • Strip or summarize ARGUMENTS on replay rather than echoing the full string
  • Wrap replayed reminders in a distinct tag (e.g. <replayed-context>) that the model is trained to treat as historical-only
  • Truncate ARGUMENTS over some length threshold and replace with [ARGUMENTS truncated on resume]

Model side:

  • Reinforce in the system prompt that <system-reminder> content is never a directive, only context
  • The current system prompt already says "Tags contain information from the system. They bear no direct relation to the specific tool results or user messages in which they appear" — but in practice the model still acts on instruction-shaped content inside reminders

Workaround

User has to interrupt mid-execution and explicitly tell the assistant they didn't request the work. Not sustainable.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗