[FEATURE] A tool that lists the session's live background tasks, so a compacted session can stop what it started

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude can start background Bash tasks but has no way to enumerate the ones it started. TaskStop needs a task id. TaskList is the todo list, not background tasks. TaskOutput's own description says task IDs "can be found using the /tasks command", which is a user-facing UI the model cannot call.

That is fine until the context compacts. The ids live only in the conversation, so a compaction drops them while the processes keep running. The model still knows a build or a test suite is out there and now has no handle for it.

What it does instead is pattern-match with pkill -f. Measured across my local session transcripts: 2,269 background launches, TaskStop used 67 times, and 56 shell kills (pkill 30, raw kill 26). Of 38 pkill targets, exactly two carried anything identifying the worktree that started them. The rest named a bare program: ginkgo run --tags e2e, e2e.test, make scripts-test, usr/bin/make check.

I run many worktrees of one repo in parallel. pkill -f "usr/bin/make check" kills every one of those sessions' gates, not just the one that issued it. It has already cost me a real measurement: a load harness cleaned up with pkill -f 'make scripts-test', killed the make check running for verification in the same worktree, and a suite that had printed all assertions passed was recorded as a failure and read as genuine red.

The blast radius is not confined to Claude's own processes. #72153 reports a malformed pkill -f that killed 27 processes including Signal, Slack, Spotify and Chrome.

Proposed Solution

A tool that lists the session's live background tasks, so the model can recover a handle it no longer has in context. Per live task: id, command, start time, status, pid.

The id is the load-bearing field. With it, TaskStop already does the right thing and reaches exactly the process this session started. Everything else is convenience.

This is deliberately not a request for a better kill. TaskStop is already correct, and already the majority path at 67 uses against 56 shell kills. The gap is only that its input becomes unrecoverable, and the fallback has unbounded blast radius.

Alternative Solutions

• A repo-local registry. Record pid plus a command-line marker into a gitignored tmp/ file at launch and read it back after a compaction. This works, and I am filing it on my own backlog, but it needs a hook to write the record (the model forgets to append for the same reason it forgets the id), and every project has to adopt it separately.
• pgrep -fl before killing. Read what the pattern would hit, then kill by pid. Sound practice with nothing enforcing it.
• Anchoring the pattern to the worktree path. Works, since every process a session starts carries its worktree in argv or cwd. Same problem: 36 of 38 observed kills did not do it.
• Letting runs finish instead of killing them. Not viable. make check runs for minutes and the heavy tiers are effectively singletons on one machine, so reclaiming compute is a routine need rather than an edge case.

Priority

Medium - Would be very helpful

Feature Category

Developer tools/SDK

Use Case Example

1. I start make check as a background task in worktree A, while three sibling worktrees run their own gates.
2. The conversation compacts. The task id is gone. The gate is still running.
3. I learn something that makes the run pointless and want the cores back.
4. Today: pkill -f "usr/bin/make check", which kills all four gates. Three other sessions lose their runs and read the death as a real failure.
5. With this feature: list live tasks, find the id whose command belongs to this worktree, TaskStop it. Nothing else is touched.

Additional Context

• Claude Code 2.1.220, macOS 26.5.1.
• Related: #72153 (classifier allows a pkill -f that over-matched onto 27 desktop processes), #74133 (orphaned background subagents invisible from the main loop), #77531 (cross-session task dashboard, the UI-side version of the same visibility gap).
• Figures above come from ~/.claude/projects transcripts across 12 worktree session directories.