Background tasks silently relaunched as duplicates + /tasks lacks elapsed time to triage

Description

When multiple background tasks are running simultaneously (e.g., subagents via the Agent tool), some tasks appear to get relaunched after approximately 90–120 seconds, even though the original process is still executing. This results in two identical commands running in parallel (duplicated work).

This happens frequently with long-running commands like npx tsc --noEmit 2>&1, pnpm lint, or any check that takes over ~90s on a large codebase.

Performance impact: The duplicated heavy processes (tsc, eslint) accumulate and severely degrade laptop performance — CPU spikes, fans spinning, general system sluggishness — because multiple instances of the same expensive command run concurrently without the user realizing it.

Steps to reproduce

1. Have multiple background tasks running (e.g., via Agent tool or run_in_background)
2. One or more tasks take longer than ~90s (common with tsc --noEmit on large codebases)
3. The system relaunches the same task while the original is still running
4. Now two identical processes run in parallel, consuming double the CPU/memory

Expected behavior

1. Prevent or surface duplicate relaunches

• Detect the duplicate and kill the older one before relaunching (if it might be stuck)
• Warn the user showing which task has been running longer, so they can manually decide which to stop
• Don't relaunch if the original process is still alive and producing output
• At minimum: surface the duplication so the user knows it happened

2. Show elapsed time and start order in /tasks (related UX gap)

Currently /tasks shows task names and status but no timing information. When duplicate tasks are running, there's no way to tell:

• Which task started first (execution order)
• How long each task has been running (elapsed time)
• Which one might be stuck vs. which is the duplicate

Proposed: Add elapsed time and/or start timestamp to the /tasks view:

# Current:
  1. ✅ Research phase
  2. 🔄 Running tsc --noEmit
  3. 🔄 Running tsc --noEmit    ← which is which??

# Proposed:
  1. ✅ Research phase (completed in 12s)
  2. 🔄 Running tsc --noEmit (running for 2m 34s, started 14:02:11)
  3. 🔄 Running tsc --noEmit (running for 0m 08s, started 14:04:37)  ← clearly the relaunch

This would make it trivial to identify duplicates, stuck tasks, and manage them accordingly.

Current behavior

The task is silently relaunched without killing the original. No indication is given to the user that duplicate processes are running. Heavy commands like tsc --noEmit or pnpm lint stack up, thrashing the system. /tasks provides no timing info to help triage.

Environment

• macOS (Darwin 24.6.0)
• Claude Code CLI (background jobs / Agent tool)
• Large TypeScript codebase (~1500+ files)
• Commonly triggered by: npx tsc --noEmit, pnpm lint, and similar long-running checks

Related issues

• #9780 — Claude fails to track background dev server processes, starts duplicates
• #45717 — Bash tool timeout kills Claude Code process (SIGTERM propagation)
• #51052 — Session terminates silently while awaiting long-running background processes
• #60072 — Tasks sidebar shows zombie "Running" entries after background Bash tasks complete