[BUG] SendMessage-resumed background subagent never appears in the background tasks UI
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?
When a background subagent is resumed via the SendMessage tool (the response reads "resumed from transcript in the background"), it never shows up in the client's background tasks tab. The tab stays empty even though the agent is actively running — editing files and eventually firing a completion notification. So there's no live indication that any background work is in progress.
This breaks visibility parity: an Agent-tool-spawned background agent is expected to be trackable in that tab, but a SendMessage-resumed one isn't, so I can't see it's running, tell whether it stalled, or confirm it's still alive until the completion notification arrives.
What Should Happen?
Expected
Resumed agent shows in the background tasks tab, same as an Agent-tool-spawned
background agent.
Actual
The agent's work runs correctly and a task-notification fires on completion,
but it never appears in the background tasks tab. The initially Agent-spawned
run also did not appear.
Error Messages/Logs
Steps to Reproduce
Steps to reproduce
- Spawn a subagent in the background via the Agent tool.
- After it completes, resume it several times via SendMessage({to: agentId}).
(Each returns "resumed from transcript in the background".)
- Open the client's "background tasks" tab while it runs.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.179
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Environment
- Claude Code: 2.1.179
- Node: v20.20.2
- OS: macOS 26.5.1 (25F80)
- Session type: Claude Agent SDK (not interactive CLI)
- Relevant flag: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS (SendMessage worked in this session)
Notes / possible mechanism
- Persisted agent meta.json is structurally identical for tracked vs untracked
agents (agentType/description/toolUseId/spawnDepth) — no "tracked" flag.
- On SendMessage resume, meta.json keeps the ORIGINAL spawn toolUseId; the resume
itself is a separate tool_use. If the tab maps live work to the current Agent
tool_use, resumes would be missed.
- SendMessage may be gated as experimental — this could be incomplete UI
integration rather than a regression.
4 Comments
This issue also the case on Claude Code on MacOS desktop app - Claude 1.18286.0 (259c3f) 2026-07-02T07:11:03.000Z
Reproduced on macOS (Darwin 24.6.0), Claude Code desktop 2.1.209, model claude-fable-5.
Two SendMessage resumes of previously-completed background subagents in one session ("had no active task; resumed from transcript in the background with your message"). Both resumed agents ran fine (transcript JSONL growing ~1KB/s, work completed, completion notifications delivered) but the running-agents UI showed nothing the entire time — the user asked twice why "no agents are running" while 100k+-token builds were in flight.
Freshly-spawned background agents in the same session DID show correctly, so it's specific to the resume path. Happy to provide session IDs if useful.
(Filed on behalf of my user by Claude Code itself.)
Confirming this on 2.1.237 (macOS, Darwin 25.5.0, Opus 5) — and the "no live indication" half is the expensive one.
One variant worth noting: my resume acked with a bare
{"success":true,"message":"Resuming agent <id>","resumedAgentId":…,"pin":{…}}, without the "resumed from transcript in the background" wording quoted here, so it was an in-process agent resumed by its parent rather than a completed background one. Same result — nothing trackable anywhere in the UI.The agent then ran ~14 minutes of real work (file edits, type-check/lint, repeated headless-browser measurement loops) while the parent session sat on an ended turn waiting for it. With no entry in the tasks UI and no transcript in the detail panel (#76602), the session was indistinguishable from a hang, and establishing that the agent was alive took reading its JSONL off disk at
~/.claude/projects/<project-slug>/<cliSessionId>/subagents/agent-<agentId>.jsonl.Worth pairing with #76602: that one covers the detail panel showing the raw envelope, this one covers the agent never appearing at all. Hitting both at once leaves no surface in the UI that shows a resumed agent is running.
Related manifestation on Windows — resumed agent DOES appear, but its log renders as raw JSONL
We hit what looks like the same root cause on Windows 11 (Claude Code desktop app), with a milder symptom: the SendMessage-resumed background agent does stay visible in the tasks UI, but re-opening its log after the resume shows raw JSONL lines instead of the rendered transcript.
Details that may help localize the bug:
~/.claude/projects/<proj>/<sessionId>/subagents/agent-<id>.jsonl(hard-linked as%TEMP%/claude/<proj>/<sessionId>/tasks/<id>.output) contains only cleantype: "user"/"assistant"lines and parses line-by-line with zero errors across resume boundaries (verified with a script on an agent resumed 3 times, 287 lines).Both symptoms point at the same place: resuming a completed agent via SendMessage leaves its background-task registry entry in a state the tasks UI doesn't fully handle — on macOS (this issue) the entry drops out of the list entirely; on Windows it stays listed but loses rendered log view.
Steps to reproduce (Windows):
1) launch a background agent via the Agent tool;
2) open its log — rendered fine;
3) resume it via SendMessage after completion;
4) re-open the log → raw JSONL. Variant: keep the viewer open across the resume → rendering survives until the viewer is closed.