[BUG] /clear silently terminates persistent Monitor background tasks - the session loses its only wake mechanism and is never told

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?

A background task started with Monitor({command: ..., persistent: true}) is terminated when the owning session runs /clear. Neither the session nor the user is notified.

That monitor is the session's only mechanism for being woken by an external event. After /clear the session is deaf, and because nothing reports the change, it cannot discover this about itself.

Evidence - two independent occurrences, same day, same machine

Measurement method: enumerate Win32_Process for the monitor's python.exe by its CommandLine, and check whether each process's ParentProcessId still exists.

Session A

09:59:40 JST   2 processes (parent + child), parent alive
     ---> the only intervening action was /clear
10:01:27 JST   0 processes

The 09:59:40 reading was captured incidentally by an unrelated estate-wide sweep, so it is not a post-hoc reconstruction.

Session B - a different session, about 20 minutes later

10:19:xx JST   2 processes, parent alive
     ---> /clear
10:20:51 JST   0 processes
10:25:00 JST   still 0 processes

Nothing else was run against either session between the two measurements.

The session cannot recover on its own

This is what turns it from annoying into costly:

• Re-arming requires the session to take a turn and call Monitor again.
• A session only takes a turn when a human types into it.
• A session that just ran /clear has, by definition, nobody typing into it.

So the monitor stays down until a human happens to open that session again.

In Session B we confirmed the session had received a message telling it to re-arm - our SessionStart hook delivered it and it was marked read at 10:17:38 - and the monitor was still absent at 10:25:00. Delivery into context is not the same as the model taking a turn.

Another session cannot fix it either: Monitor can only be called from inside the session that owns it.

What Should Happen?

Any one of these would be enough:

1. persistent: true monitors survive /clear (the session id is unchanged, after all), or
2. the post-/clear session is told that its background tasks were terminated, so it can re-arm on its first turn, or
3. /clear warns before clearing: "N background tasks will be terminated."

(2) is probably the smallest change and would fully solve it for us.

Error Messages/Logs

No error is emitted anywhere - that is the substance of the report. The transcript contains no notice, and no notification is raised.

The only observable is the process table. Detection command used:


$all = Get-CimInstance Win32_Process
$all | Where-Object { $_.CommandLine -like '*<your monitor script>*' } | ForEach-Object {
  $p = $_
  $parent = $all | Where-Object { $_.ProcessId -eq $p.ParentProcessId }
  '{0} PPID={1} parent={2}' -f $p.ProcessId, $p.ParentProcessId, $(if ($parent) { 'alive' } else { 'DEAD' })
}


Before `/clear` (2 rows, parent alive), after `/clear` (0 rows).

Steps to Reproduce

1. In a session, start a long-running monitor:

Monitor({command: '<a script that prints a line every 45s>', description: 'watch', persistent: true})

1. Confirm the OS process exists (Task Manager, or Get-CimInstance Win32_Process).
2. Run /clear in that session.
3. Re-check the process list - the process is gone.
4. Observe that nothing in the transcript, and no notification, indicates that a background task was terminated.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.237 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Version-dependent failure mode

On 2.1.229 we observed the other half of this: after /clear the shell parent died but the child kept running as an orphan - process alive, state file still advancing, notifications going nowhere. Filed as a separate issue.

| version | what /clear does to a persistent Monitor |
|---|---|
| 2.1.229 | child survives orphaned (parent dead) - looks healthy, delivers nothing |
| 2.1.237 | child is terminated outright |

Different symptom, same practical result: the monitor stops working and nothing says so. Because of this we cannot name a "last working version" - both versions are broken, in different ways.

Environment

• Claude Code 2.1.237, Windows desktop app (MSIX)
• OS: Windows 11 Home 10.0.26200
• Locale: ja-JP
• About 18 concurrent local sessions on one machine, each running one Monitor background task with persistent: true

Impact

Multi-session setups where each session runs a monitor so it can be notified of work arriving from elsewhere. /clear is recommended practice for managing context; right now every /clear silently removes that session from the notification network, and the loss is invisible from both sides.