Sign up
View stargazersSign up

[Bug]: Subagent updates reset the main thread working timer during ongoing work#22931

opened21d agobyKKhalil abdalamgeed

## What happened

While a main thread was working with delegated subagents, messages labeled "Sent by another agent" reset its elapsed working timer. The user reports that a thread working for about an hour starts counting again when a subagent sends an update, even though the same task is still underway and the user has sent no new request.

These updates appear in user-style message bubbles, sometimes marked "Steer", making the reset look as though the user started a new request.

What I expected

A subagent reporting progress during ongoing work should preserve the elapsed time of that work. A steer should not reset the timer. If coordination starts a separate continuation turn, the duration of the ongoing work should remain visible rather than appear to restart from zero.

Steps to reproduce

  1. Start a long-running task in a main thread and have it delegate work to subagents.
  2. Let the main thread accumulate a noticeable working duration.
  3. Have a subagent send an update to the main thread with t3_thread_send while the main task remains underway.
  4. Compare the elapsed working timer immediately before and after the update. Repeat with another update.

Additional context

  • Reported on Windows desktop. The main thread's composer shows Codex, GPT 6.1 Sol. Exact installed version was not captured.
  • This report records the user's observation; the timer reset was not independently reproduced in a running client.
  • The shared timer logic explicitly says timers count from the work start, never last activity, and that a wake keeps the start of the work it continues. Existing tests also expect repeated steers to preserve the original duration. Source inspected at commit 9a43c64ec0ef69d57efe96e3635527f085f80b1e.
  • Related but different reports: #19736 concerns timer/header placement after queued input; #21895 concerns agent steers cancelling Claude tools. Neither covers the elapsed timer resetting.
  • Impact: misleading duration during long-running delegated work. No workaround confirmed.

Before submitting

  • I searched existing open issues and did not find a duplicate covering the timer reset.
  • I included steps and enough context to investigate; independent reproduction is still needed.