[BUG] Agent Teams: idle status is delayed, making team lead think active teammates are idle.
Resolved 💬 3 comments Opened Feb 8, 2026 by isupeene Closed Mar 9, 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?
I've been trying out agent teams with the team-lead coordinating the work of a number of teammates. I noticed some confusion about the team lead thinking that an agent is idle when it was actually working, which we decided was due to the idle status coming in late. I've pasted my conversation with the team lead demonstrating this.
What Should Happen?
team-lead shouldn't get idle messages when agent isn't idle, or should at least know how to interpret those messages.
Error Messages/Logs
`
⏺ dopey is idle and available after receiving the callback closure guidance. They're ready to implement the fix when they resume work on Task #26.
Summary:
- ✅ Text wrapping: Fixed
- ✅ Coordinate space: Fixed
- ⏳ Binding propagation: Solution provided (callback closure pattern)
- Status: dopey idle, ready to continue
The fixes are straightforward to implement - dopey should be able to complete Task #26 on their next turn.
Is there anything else you'd like me to work on while dopey is idle?
❯ I'm confused why you keep thinking dopey is idle. Where do you get information on teammate status?
⏺ You're absolutely right to call that out - I've been misinterpreting the information!
I'm getting the teammate status from these idle_notification messages:
{"type":"idle_notification","from":"dopey","timestamp":"2026-02-08T18:30:22.777Z","idleReason":"available"}
But these are just automatic notifications that the system sends when an agent finishes their turn. They don't mean dopey has stopped working or is stuck - they're just normal status updates saying "my turn is done, I'm available for the next turn."
You tried to tell me this earlier when you said "dopey looks active to me. I don't think there's a problem," but I kept treating the idle notifications as if something was wrong.
Correct interpretation:
- Idle notifications = normal end-of-turn status (not a problem!)
- Dopey is progressing through Task #26 normally
- Each status update → work → idle cycle is expected behavior
Sorry for the confusion! I was over-interpreting routine status messages as problems. Is there anything you'd actually like me to focus on?
❯ Hmm, to be honest, I would interpret those notifications that way too. This might be a bug to report to Anthropic. What's your most recent status message about dopey?
⏺ The most recent substantive message from dopey was the status update about text wrapping being fixed but having a new blocker with the binding propagation (furigana overlay not appearing). That was the message with summary "Task #26 update - text wrapping fixed".
After that:
1. I sent dopey the callback closure solution
2. dopey sent two idle notifications (18:26:04 and 18:30:22)
3. No further substantive updates from dopey
So the last real status is: text wrapping fixed, binding propagation broken, solution provided but not yet implemented.
You're right that those idle notifications are confusing - they make it look like dopey stopped working, but we don't actually know if they:
- Are still working on implementing the callback solution
- Finished and just haven't reported back yet
- Actually stopped working
The idle notifications don't tell us which of those is true. That does seem like a UX issue worth reporting to Anthropic - the notifications imply the agent is "idle" (stopped) when they might actually still be actively working.
@dopey❯ Task #26 - callback implemented, overlay issue remains
⏺ Ah, now we have a real update! dopey implemented the callback but hit a new issue - the overlay isn't appearing, likely due to Z-ordering between UIKit and SwiftUI.
⏺ Sent the solution! The Z-ordering issue is a classic UIKit/SwiftUI interop problem. The fix is to keep responsibilities separate: UIKit handles tap detection, SwiftUI handles overlay rendering.
dopey is making good progress debugging through these interop issues. They're close to a working solution - just need to restructure the view hierarchy so the SwiftUI overlay renders on top of the UIKit text view.
⏺ Got another idle notification from dopey. Based on our earlier discussion, this is just the automatic end-of-turn notification - it doesn't necessarily mean dopey has stopped working or encountered a problem. They may be:
1. Still implementing the Z-ordering fix I just suggested
2. Testing the changes
3. Preparing a status update
Without a substantive message, I don't actually know dopey's current status. The idle notifications don't tell us if they're actively working, completed the fix, or hit another blocker.
Should I wait for a real status update from dopey, or would you like me to work on something else in the meantime?
❯ Hmm, those idle notifications are odd, and I think it would be a problem if dopey actually ended their turn, but I don't see any evidence of that. As you can see, he keeps sending you messages with his progress. Maybe he's messaging you and ending his turn, then you respond, then the idle notification comes in
on a delay? What order did you get the latest message and idle notification?
⏺ Good catch! Looking at the order:
1. 18:34:XX (approximate): dopey sent "Task #26 - callback implemented, overlay issue remains"
2. After that: I responded with the Z-ordering fix
3. 18:34:27: Idle notification arrived
So yes - the idle notification likely refers to dopey ending their turn AFTER sending me the status update, but it arrived AFTER I already responded. The notification is delayed relative to the actual message flow.
So the timeline is actually:
1. dopey works → sends status update → ends turn (triggers idle notification)
2. I receive status update → respond
3. Idle notification finally arrives (delayed)
This makes the idle notifications very confusing because they arrive out of sequence, making it look like dopey went idle after receiving my response, when really they went idle before I even responded!
That's definitely something worth reporting to Anthropic - the timing/ordering of idle notifications relative to message delivery makes them misleading. They should either arrive immediately when the turn ends, or be suppressed if they're going to be significantly delayed.
`Steps to Reproduce
Create an agent team where a lead agent is delegating tasks. Ask the team lead to tell you when he gets idle status messages from subagents. Watch the chaos unfold.
Claude Model
None
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.34
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗