[BUG] After stop+resume of a bg session, the stale dashboard row mirrors "working" and opening it kills the live shell (exit 1)

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?

Related: #85886, #85888 (same environment/collaboration). Claude Code v2.1.227 (native install), macOS (Darwin 25.5.0).

To reload a background (daemon-hosted) session, /resume from a fresh terminal is refused ("it is a background agent, stop it first"), so the supported path is: agents dashboard → Ctrl+X once (Stopped) → /resume it from the new terminal. This works and the resumed conversation continues the SAME session id / transcript under a new job shell + PID. But afterwards:

1. BOTH dashboard rows track the one live session: when the resumed session works, the old row — explicitly Stopped by the user — flips to "working" as well. The status apparently derives from session-level activity, and both job shells reference the same session.
2. Pressing Enter on the stale (stopped) row opens it — and the live resumed shell immediately dies with "exit with code 1" and can no longer be entered until the stale row is Ctrl+X-stopped again. Two engines contend for one transcript; the loser is killed with no explanation shown to the user.
3. On-disk metadata desyncs: the new job shell's state.json still records sessionId = its own original session id (from before the /resume), not the session it actually hosts now. The old shell's state.json also claims the same live session id. So no registry reflects reality, and the user cannot tell which row is safe to delete.
4. The user is left afraid to delete the stale row at all: the UI gives no indication whether "Delete" removes just the job-shell registration or the shared session transcript both rows point to.

Searched existing issues — related but none covers this combination: #81662 (bg handoff mints self-referential session id — same metadata-desync family as our point 3, but at handoff not resume), #85657 (resume/continue disagree on bg sessions — the refusal in our step 2, but not what happens after the workaround), #75495 (Ctrl+X delete doesn't persist / double-rendered rows — rendering-level duplication, ours is two real job shells with live status mirroring), #85759 (Enter in empty desktop chat stops all agents — accidental global stop, not stale-row-kills-live-shell), #75986 (stale agent reopen crashes exit 1 — crash on reopen itself, not cross-shell contention). The distinctive parts here: a user-stopped row resurrecting to "working" in lockstep with the resumed shell, and opening the stale row terminating the live one.

What Should Happen?

After a session is resumed under a new job shell: the stale shell's row should either disappear, or show a terminal state ("superseded by <new name>") that never mirrors "working" and is not enterable; job-shell metadata (state.json sessionId) should be updated to the session actually hosted; and the Delete action should state what it deletes (job registration vs session transcript) so users can clean up without fearing data loss of the live session.

Error Messages/Logs

Steps to Reproduce

1. Run a session as a daemon-hosted background agent via the claude agents dashboard; let it work.
2. From a fresh terminal, /resume that session — observe refusal ("background agent, stop it first").
3. In the dashboard, select its row and press Ctrl+X once → Stopped.
4. /resume it from the fresh terminal — succeeds; same session id/transcript, new job shell + PID. Optionally /rename it.
5. Give the resumed session work; watch the dashboard: the old Stopped row flips to "working" in lockstep with the new row.
6. Press Enter on the old row: it opens, and the resumed shell exits with code 1 and becomes un-enterable until the old row is stopped again.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.227

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_