read_agent returns nothing of a background agent's work when it failed, or after --resume #5345

Describe the bug

When a background agent fails, read_agent returns only the error. None of the agent's messages, commands or file edits come back, even when it did a lot before failing. After the session is resumed in a new process, it's worse: read_agent answers "Agent not found" for any agent started before the restart.

Either way, the main agent can't tell what the subagent did, so it goes through the files on disk and guesses, or redoes the work. The last time this happened to me, a subagent had worked for almost three hours (215 shell commands, 3 files written) when a network blip failed its model call 5 times. Then the session restarted, and the main agent got "Agent not found".

The work is all still in the parent session's events.jsonl: every event of the subagent is there, with parentToolCallId set to the id of the task call that started it. read_agent just doesn't look there once the agent is gone from memory or failed.

Maybe related: #2595 (completed agents purged quickly) and #2137 (results lost after compaction). This one is about failed agents and resumed sessions.

Affected version

GitHub Copilot CLI 1.0.105

Steps to reproduce the behavior

I used a clean container (node:22-bookworm), npm i -g @github/copilot@1.0.105, an empty working directory and Claude Haiku 4.5.

Agent forgotten after a resume

1. copilot -p "<prompt>" --model claude-haiku-4.5 --allow-all-tools, where the prompt asks the main agent to launch one background agent with the task tool (a small job that ends with a known reply) and read it with read_agent.
2. This works: read_agent returns the agent's reply.
3. copilot --resume=<id> -p "Use read_agent on the agent you launched earlier and give me its reply." --model claude-haiku-4.5 --allow-all-tools
4. read_agent answers "Agent not found".

Failed agent returns only the error

1. In one copilot -p run, the main agent launches a background agent whose job includes sleep 20, then runs sleep 150 itself so the process stays up.
2. While the agent is in its sleep, block outbound 443 (iptables -A OUTPUT -p tcp --dport 443 -j REJECT), so its next model call fails.
3. Unblock, and let the main agent call read_agent. It gets:

Agent failed ... total_turns: 0
Error: Failed to get response from the AI model; retried 5 times ... ECONNREFUSED

and nothing else, while the parent's events.jsonl has 7 events for that agent under its parentToolCallId.

Expected behavior

read_agent on a failed agent returns what it did up to the failure, along with the error: at least its last messages and the files it touched. After --resume, agents from the earlier process can still be read, from the session's events if they're no longer in memory.

Additional context

• Linux x86_64 (Docker), bash. I see it in my normal sessions on Linux too.
• For now I work around it with a small script that reads the agent's events from events.jsonl by parentToolCallId, and an instruction telling the agent to run it when read_agent fails. Sonnet 4.6 follows it; Haiku 4.5 still guessed from the files instead.