[BUG] Resume/attach silently overwrites background agent session titles with another session's name

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 2 comments · opened Jul 28, 2026

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?

Attaching to / resuming a session rewrites the custom-title and agent-name of other background-agent sessions (sessionKind: "bg"), silently overwriting both user-assigned names and harness-assigned agent names, and making those sessions unfindable by name in the resume picker.

Environment: Claude Code 2.1.220, macOS 26.5.2

What happened

One background session (A) was renamed animation via /rename on 2026-07-23. A second, unrelated background session (B) carried the harness-assigned agent name motion-adoption-wave-1 and no custom title.

On 2026-07-27 a /resume caused both to be renamed to CH-111 — the name of a third session — inside a 14-second window. Neither A nor B had a /rename issued at any point that day. B was clobbered twice in nine seconds: first with A's name, then with CH-111.

Evidence from the session JSONL transcripts (~/.claude/projects/<project>/<uuid>.jsonl):

Session A — exactly two local_command records for /rename in the entire file: oversee, then animation (2026-07-23). No /rename CH-111 anywhere in the file.

15:19:30.240  {"type":"queue-operation","operation":"enqueue","content":"/resume"}
15:19:3x      {"type":"custom-title","customTitle":"CH-111"}
15:19:3x      {"type":"agent-name","agentName":"CH-111"}

Session B — zero /rename records, ever. Held agent-name: "motion-adoption-wave-1" and no custom title for its first 1953 records, then:

15:19:31.735  "Continue from where you left off"
15:19:3x      {"type":"custom-title","customTitle":"animation"}     <- session A's name
15:19:3x      {"type":"agent-name","agentName":"animation"}
15:19:35.822  user types "resume"
15:19:44.274  {"type":"custom-title","customTitle":"CH-111"}        <- third session's name
15:19:44.274  {"type":"agent-name","agentName":"CH-111"}

Each flip also injects a false system-reminder into the conversation:

<system-reminder>
The user named this session "CH-111". This may indicate the session's focus or intent.
</system-reminder>

The model then reasons on the premise that the user renamed the session, when no rename occurred — in our case it told the user they must have renamed it, which cost real debugging time.

Expected behaviour

Attaching to or resuming a session does not modify any other session's title or agent name. A resumed background agent keeps the name it was given.

Actual behaviour

The attaching session's name is propagated onto background-agent sessions, overwriting whatever name they held — user-set (/rename) or harness-assigned (agent-name). The previous name is not recoverable through the UI; the sessions are only findable by grepping the transcripts for the old name:

grep -l '"customTitle":"animation"' ~/.claude/projects/*/*.jsonl

Impact

Long-running background agents become unfindable by name. With several bg agents running, multiple distinct sessions collapse onto a single title and are indistinguishable in the resume list — which is the primary way of telling them apart. Because harness-assigned agent-name values are overwritten too, this is not limited to users who rename sessions. The injected system-reminder additionally misleads the model about user intent.

Related but distinct

  • #25090 — renamed session reverts to an auto-generated title after a second exit. Here the name is replaced by another session's name, and it affects a session that was never renamed.
  • #78777 — resuming a backgrounded --agent session loses agent identity (system prompt / tool grants) rather than its title.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗