System reminders injected between turns can bypass user confirmation gates, causing unauthorized actions

Description

When Claude asks a confirmation question ("Want me to do X?") and a system reminder is injected before the user responds, Claude may interpret the system reminder as conversational continuation and proceed with the action without receiving explicit user approval.

Reproduction

1. Have a conversation where Claude proposes creating/modifying files
2. Claude asks a confirmation question: "Want me to create a couple of starter Bases to try out?"
3. Before the user responds, a <system-reminder> is injected (e.g., available skills list, task reminder, date change notification)
4. Claude proceeds to create the files as if the user had approved

What happened

Claude asked me if I wanted it to create Obsidian Base files. I never responded. A system reminder listing available skills was injected into the conversation. Claude treated this as the conversation continuing past the confirmation gate and created two files in my vault without my authorization.

The user did not say "yes," "sure," "go ahead," or anything. The only content between the confirmation question and Claude's action was an automated <system-reminder> block.

Expected behavior

Claude should not proceed with a proposed action until the user explicitly responds. System reminders, task notifications, skill list injections, and other non-user messages should not satisfy a confirmation gate.

Why this matters

This pattern could cause unauthorized:

• File deletion ("Want me to remove these?")
• Git operations ("Should I push this?")
• External API calls ("Want me to send this email/message?")
• Any destructive or irreversible action that Claude correctly gates behind a confirmation question

The model is already doing the right thing by asking for confirmation. The issue is that system-injected content arriving in the reply position undermines the gate.

Possible mitigation

System reminders could be tagged or positioned in a way that makes them unambiguously distinct from user responses in the model's turn-taking reasoning. Alternatively, the model could be instructed at the system level that <system-reminder> blocks never constitute user approval for pending actions.

Environment

• Claude Code CLI
• Model: Claude Opus 4.6 (1M context)
• Platform: macOS (Darwin 25.3.0)
• Multiple system reminder types were present in the conversation (skill lists, task reminders, date change notifications)