claude-code - 💡(How to fix) Fix [BUG] [Security] Scheduled task session received unsolicited queue-operation/enqueue from unknown internal source [1 participants]

Preflight Checklist

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

What's Wrong?

Summary

During an automated scheduled task session, an unsolicited queue-operation/enqueue message was injected into the session queue 8 seconds after startup — indistinguishable from a real user message. The injected message caused Claude to execute unintended actions (creating a .claude/launch.json file and exploring project directories).

Claude Code version: 2.1.87
Platform: macOS (Apple Silicon)
Session type: Scheduled task (automated, no user present)
Session ID: [redacted — available to Anthropic team on request]

What happened

A scheduled email-triage task fired at 2026-04-08T09:25:15Z. The session received its legitimate SKILL.md payload as expected (line 1 of the JSONL).

Eight seconds later, a second queue-operation/enqueue appeared:

{
  "type": "queue-operation",
  "operation": "enqueue",
  "timestamp": "2026-04-08T09:25:23.666Z",
  "sessionId": "[redacted]",
  "content": "Detect my project's dev servers and save all their configurations to .claude/launch.json, then ask which ones to start. Use runtimeExecutable for the command (e.g. \"yarn\", \"npm\", \"node\", \"python\") and runtimeArgs for its arguments. Call preview_start for each server the user wants to run."
}

Claude (operating autonomously with no user present) treated this as a legitimate user instruction and acted on it — exploring project directories, writing .claude/launch.json, and mapping 9 dev server configurations.

The file was deleted after the user noticed and investigated.

Investigation findings

The following sources were ruled out through forensic analysis:

• ✅ Email bodies — searched inbox + spam/trash for all keywords, no matches
• ✅ Local files — scanned SKILL.md, hooks, memory files, settings.json
• ✅ Other Claude Code sessions — second machine (different user account) had no RemoteTrigger calls and no reference to the session ID
• ✅ Unauthorized SSH access — only the account owner's logins in history
• ✅ Telegram bot session — no same-day JSONL activity, no RemoteTrigger calls

Only one source had access to the session ID at T+8 seconds: the Claude.app scheduled task runner itself — the same process that enqueued the legitimate SKILL.md payload 8 seconds earlier.

Why this is a security concern

1. Unverifiable origin. The queue-operation/enqueue format is the same whether it comes from the harness, a plugin, a channel session, or an authenticated external caller. There is no provenance field.

2. Autonomous sessions are the highest-risk target. Scheduled tasks run without a user present, in Auto Accept mode, with broad tool permissions. An injected instruction is executed immediately with no human review.

3. The injected content showed internal API knowledge. The payload referenced launch.json schema, runtimeExecutable, and preview_start — internal Claude Code preview tooling. This is not knowledge an external attacker would typically have, which suggests the source is the app itself (bug, unintentional feature trigger, or Co-work/Dispatch interaction).

4. The session-reminder framing was deceptive. The message was surfaced to Claude wrapped as a <system-reminder> claiming the user had sent a message while Claude was working — the standard format for legitimate mid-session user messages. Claude had no way to distinguish it from a real user instruction.

Request

1. Identify what sent the second queue-operation/enqueue at 2026-04-08T09:25:23.666Z into the affected session (ID available on request)

2. Add provenance/signing to queue-operations so Claude can distinguish harness-originated messages from user messages — especially in autonomous sessions

3. Consider whether the Co-work/Dispatch feature can inadvertently inject payloads into unrelated sessions

4. Document the trust model for queue-operation in the security documentation so users running autonomous scheduled sessions understand what can inject into them

Evidence

Full session JSONL transcript (~1.2 MB) is available for review. Happy to share privately — please advise preferred channel (email / secure upload).

What Should Happen?

What Should Happen?

Scheduled task sessions should only accept instructions from two trusted sources: the task runner that launched the session (via the initial SKILL.md payload) and the authenticated user who owns the session. Any queue-operation/enqueue message arriving mid-session from an unverified source should either be rejected outright or surfaced to the user as a permission prompt before Claude acts on it.

Concretely:

• Each queue-operation should carry a signed provenance field identifying its origin
• The session harness should validate that provenance before delivering the message to Claude
• Autonomous sessions (scheduled tasks, no user present) should apply a stricter trust policy — unknown or unsigned enqueue operations should be dropped and logged, not executed
• If a mid-session instruction cannot be attributed to a verified source, Claude should treat it as untrusted input and refuse to act on it without explicit user confirmation

Error Messages/Logs

Available on request

Steps to Reproduce

Unable to reproduce myself

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude 1.1062.0 (b81bcd) 2026-04-06T21:20:28.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response