Completed background-agent sessions can't be removed from the `claude agents` fleet view (persist as status:null; stop/close/rm don't clear them) — confirmed 2.1.210

Summary

On the claude agents (fleet) view, a completed background session cannot be removed. It persists in the Completed list as status: null, the interactive close (Ctrl+X) clears the row but it reappears on refresh, claude stop <id> reports success yet leaves the entry listed, and there is no claude agents rm. The only way out is to manually delete the on-disk job record. Confirmed reproducing on 2.1.210 with a throwaway job (steps below).

Environment

• Claude Code 2.1.210, macOS (darwin).
• Background/daemon mode. Job records live under <config-dir>/jobs/<id>/.

Steps to reproduce (confirmed on 2.1.210)

1. claude --bg --name repro-delete-test "Output exactly REPRO_A_DONE then stop. Do not use any tools."
2. Let it finish. <config-dir>/jobs/<id>/state.json shows "state": "done", and claude agents --json --all lists it (status: "idle", settling to null).
3. claude stop <id> → prints stopped <id>, but claude agents --json --all still lists it (status: null), and <config-dir>/jobs/<id>/state.json is still present on disk. stop nulls the status but does not remove the record.
4. There is no claude agents rm/delete, and the fleet-view close (Ctrl+X) doesn't persist — the entry stays. Over repeated use the Completed list accumulates un-removable entries.

Only working removal: move <config-dir>/jobs/<id>/ aside on disk; the daemon then drops it from claude agents --json --all and the fleet view.

Expected vs. actual

• Expected: a finished session can be dismissed from the fleet view (via close, stop, or an rm), and its record is removed.
• Actual: no supported command removes a completed record; it lingers as status: null until the on-disk directory is manually deleted.

Not a duplicate of the auto-flagged issues

• #75540 — closed NOT_PLANNED as account-scoping / user error (switching between two accounts surfaced the other account's sessions; switching back cleared them). This report is a genuine on-disk state: "done" record under a single account/config-dir that only clears by deleting the directory — a different, still-open problem.
• #71562 — a different trust-flag persistence bug (hasTrustDialogAccepted staying false in the same ~/.claude.json). Related theme, not this defect.
• #77649 — a different background-daemon lifecycle bundle (un-settled worker pins daemon; --continue drops permission mode; forks inherit auto/computer-use). Adjacent area, not the fleet-view removal defect.

Related secondary observations (lower priority; happy to split out)

• With the daemon running under a non-default CLAUDE_CONFIG_DIR, accepting the interactive trust dialog writes hasTrustDialogAccepted into ~/.claude.json, while the daemon reads <config-dir>/.claude.json. So the on-screen "run Claude Code interactively here once and accept the trust dialog" remediation targets a file the daemon doesn't consult. (Config-specific, not the core bug.)
• Resuming a session into a workspace the daemon treats as untrusted loops [bg] bg claimed-spare <id> (fleet) → [bg] bg settled <id> (killed) with no surfaced reason, leaving the session wedged on Session is starting — showing its transcript until it appears.

Suggested fixes

• Add a supported way to delete a completed record — claude agents rm <id> and/or make the fleet-view close (and/or claude stop) actually remove state: "done" / status: null records from disk rather than just nulling status.
• Point the trust remediation message at the config dir the daemon actually reads.
• Surface untrusted-resume failures with the remediation instead of silently retrying claimed-spare → settled (killed).