claude-code - 💡(How to fix) Fix `/resume` picker permanently hides sessions tainted with `sessionKind: "bg"` after FleetView + `/compact` fork

Summary

/resume picker permanently hides any session whose JSONL contains entries with sessionKind:"bg". Once a session is "tainted" with this marker, no /rename or graceful exit recovers picker visibility. The only workaround is claude --resume <sessionId> directly with the UUID.

Reproducer

1. Open the agent view (FleetView). This spawns one or more kind:"bg" peek processes — each writes a sidecar to ~/.claude/sessions/<pid>.json with "kind":"bg" and attaches to an existing session (e.g., session A).
2. Inside that bg process, trigger a /compact (manual or auto). This creates a forked session B whose first JSONL entry is type:"system", subtype:"compact_boundary" with "sessionKind":"bg" baked in, and every subsequent entry written by that bg process also carries "sessionKind":"bg".
3. Exit the bg process, optionally rename session B via /rename, then /exit it gracefully.
4. From a fresh terminal, run claude --resume. Session B is absent from the picker, no matter what custom title was set.

The taint propagates through further forks: forking session B (e.g., via another /compact) into session C also inherits "sessionKind":"bg" → C is also hidden.

Evidence (verified on 2.1.142, macOS)

In our case:

• Session 3dc4caa7-... was opened by FleetView with kind:"bg" (sidecar PID 41775 confirmed).
• /compact inside that bg session created 63048f89-.... Its compact_boundary entry shows:

  {
    "type": "system",
    "subtype": "compact_boundary",
    "sessionKind": "bg",
    "forkedFrom": {"sessionId": "3dc4caa7-..."}
  }

  1831 out of 2848 JSONL entries carried "sessionKind":"bg".
• A second fork created 70b18b86-... — same inheritance pattern, 4 of 737 entries tainted.
• Both sessions were invisible in the /resume picker; both became visible immediately after stripping "sessionKind":"bg" from every JSONL entry (verified with sed -i '' 's/,"sessionKind":"bg"//g').

Expected behavior

A session created by /compact while attached to an interactive terminal (even if the underlying process happens to be kind:"bg" for FleetView display reasons) should be treated as a regular user session. sessionKind should reflect the current process's role, not be inherited as persistent JSONL metadata.

Suggested fixes (any one would resolve)

1. Don't propagate sessionKind to forked sessions. Always start a new session fresh; let its own runtime determine its kind.
2. Use the sidecar (~/.claude/sessions/<pid>.json) as the source of truth for kind, not historical JSONL entries. The picker should look up the current attached process kind (if any), not historical tagging.
3. Stop writing sessionKind into every JSONL entry. If audit-trail of process kind is needed, write it once per session-attach event, not on every assistant/tool/user entry.

Why this is a high-impact bug

• FleetView/agent view is a featured workflow. Any user who runs /compact while agent view is open is at risk of "losing" the resulting session from /resume — they can only recover it by knowing the UUID.
• /rename becomes silently no-op for these sessions, which is a major UX regression. Users report "I named the session and now it's gone" without realizing the picker filter is the cause.
• The taint propagates through fork chains, so one mistake compounds across multiple session generations.

Workaround for affected users

# Find affected sessions
grep -l '"sessionKind":"bg"' ~/.claude/projects/*/<sid>.jsonl

# Backup + strip (macOS sed)
cp <file>.jsonl <file>.jsonl.bak
sed -i '' 's/,"sessionKind":"bg"//g' <file>.jsonl

After stripping, the session appears in /resume immediately on next picker invocation — no restart needed.

Environment

• Claude Code version: 2.1.142
• OS: macOS (Darwin 25.4.0)
• Shell: zsh