[BUG] Agent-tool subagents in the usage-limit retry wait show no retry status (the main session shows "Retrying in")

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 an Agent-tool subagent (here a background general-purpose agent) gets a usage-limit 429 and goes into Claude Code's quota retry wait, nothing in the agent panel says so. A main session in the same wait shows a clear banner, for example Weekly limit reached · Retrying in 5h (<reset date and time>) · attempt 1/300. The subagent just sits in the agent panel with its elapsed timer counting up and its token count frozen. When I selected one, its panel row showed about 1 hour 4 minutes elapsed and 395.1K tokens, and no hint that it was waiting on a limit or when it would try again.

From the outside this looks exactly like a hung agent. I could not tell whether it was stuck, still thinking, or waiting for a reset, and nothing in the panel told me the next attempt could be hours away.

Subagents in at least three concurrent sessions on the same account entered this wait, refused within a few seconds of each other when the account crossed its weekly limit. I selected one of them (above).

Setup note: my settings set CLAUDE_CODE_RETRY_WATCHDOG=1, which raises the retry count to 300 (hence attempt 1/300). I have not checked whether a subagent enters this wait without it.

What Should Happen?

A subagent in the usage-limit retry wait should show the same retry status the main session gets: which limit was hit, when the next attempt is, and the attempt count. That should appear in the agent panel row and in the agent's own view.

Error Messages/Logs

Main turn of another session on the same account, in the same wait (banner in the main view):
  Weekly limit reached · Retrying in 5h (<reset date and time>) · attempt 1/300

Selected subagent in a different session (agent panel row):
  elapsed timer climbing and token count frozen; no retry or limit status in the agent panel

Steps to Reproduce

This spends real quota and can block further model requests on the account until quota is restored (for the weekly limit, possibly days). Use a throwaway session and keep the subagent's work read-only, with no project edits or state-changing commands.

1. On Claude Code 2.1.280, with CLAUDE_CODE_RETRY_WATCHDOG=1 set (as in my runs) and a subscription account close to its weekly limit with extra usage turned off, start a session and ask it to launch a background general-purpose subagent with a long, read-only, multi-step task (for example, reading and summarizing many files). The cases I saw were background subagents; from reading the code a foreground subagent looks the same, but I have not checked that live.
2. Keep working until the account crosses its weekly limit while the subagent is mid-task, so the subagent's next request is refused with a usage-limit 429.
3. If a main-session request is also refused by the weekly limit, it shows the Weekly limit reached · Retrying in ... · attempt 1/300 banner.
4. Open the agent panel and select the subagent. Its elapsed time keeps climbing and its token count stays frozen. No retry or limit status is shown.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.280 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Some notes from reading the bundled 2.1.280 CLI, offered in case they help; I have not patched or tested a fix. The main REPL passes an onRetryStatus callback into its query options, and that feeds the spinner's Retrying in ... · attempt N/M line. The agent-teams teammate runner passes onRetryStatus too. There is also a per-agent agent-retry-status spinner event and a renderer that reads an agent's retry state, but it renders nothing while that state is empty. Ordinary Agent-tool subagents do not seem to get onRetryStatus wired in, so the retry loop's callback is undefined for them and the per-agent retry state is never set. The other retry signal, the agent_api_retry progress event, is emitted only for foreground agents and appears to be consumed only by SDK / stream-json output, not by the terminal UI. There is also a usageLimitWaits registry of quota waits that I did not trace to anything on screen.

Also from the code only (not tested live): the retry wait has an early-wake hook (subscribeRetryWake), but it only seems to be created for agent-teams teammates. For an ordinary subagent the wait is a plain timer, capped at 6 hours per attempt as far as I can tell. A SendMessage to a subagent in this wait is queued for its next tool round, which does not come until a retry succeeds, so it would not wake it.

Two ways did resume a parked subagent early, after a one-time reset of the limit: stopping it from the panel with x and then typing and submitting a message in the agent's own view; or having the main session's model call TaskStop on it and then SendMessage to resume it. From the code (not tested live), an x stop appears to count as a user stop, after which a model SendMessage to that agent is refused, so after x the typed message is the way back. The main and agent views share one composer, so stash any unsent main-view draft (Ctrl+S) before composing the agent's resume message. The panel did not suggest either recovery sequence.

Related but different: #91093 asks for a general liveness/progress signal for background subagents; #74162 and #78224 ask for subagents to pause instead of fail on a usage limit (with CLAUDE_CODE_RETRY_WATCHDOG=1 set, my subagents paused in the retry wait rather than failing; this report is only about the missing status display); #89263 is about auto-continue not arming when only subagents hit the limit.