Skip to content

[Bug]: Thread shows as live after the idle reaper has stopped its Claude Code process #9586

Description

@mckhendry

A thread idle 30 minutes still shows as live in T3 after the backend has stopped its Claude Code process. Peers lose it: ListAgents drops the thread, and SendMessage to its last address fails.

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Open two Claude Code threads in the same working directory; send a turn in each.
  2. From thread A, call ListAgents; thread B is listed with a socket path.
  3. Leave thread B idle 30+ minutes, then SendMessage to that address from thread A.

Expected behavior

A thread shown as live stays addressable from its peers, or stops being shown as live. The ask: exempt sessions that are live cross-session messaging endpoints, in the same shape as the backgroundLiveness guard from #4198/#5677.

Actual behavior

Thread B is gone from the roster and the send fails; T3 shows no change.

It's the inactivity reaper — verified in ProviderSessionReaper.ts: DEFAULT_INACTIVITY_THRESHOLD_MS is 30 minutes, swept every 5, with exactly two exemptions, an active turn and backgroundLiveness (added by #5677 for #4198). Everything else past the threshold goes to providerService.stopSession. A thread idle because it's waiting to be messaged has neither exemption.

Resuming doesn't heal it: the roster is process-scoped (~/.claude/sessions/<pid>.json, socket /tmp/cc-socks/<pid>.sock), so the endpoint dies with the process. The conversation returns under a new pid, socket, and derived name (observed: "nameSource":"derived"), so addressing by roster name doesn't survive either.

Some of these peers are terminal sessions T3 never started, so the T3 process must stay on Claude Code's roster.

Impact

Major degradation or frequent failure

Version or commit

0.0.38 desktop (Alpha); citations against main @ 70cd258d

Environment

macOS 26.6.2 (Darwin 25.6.0), Node v26.3.1, Claude Code 2.1.259

Logs or stack traces

none — server.trace.ndjson rotates faster than the 30-min threshold

Workaround

Re-run ListAgents before every send and wake the target with a turn — which takes a human in that thread.

Related: #5523 asked to make the threshold configurable; this asks for an exemption, not a setting.

Drafted with Claude Code (Claude Opus 5) from source and transcripts on my machine; I reviewed and posted it.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions