You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Main timeline keeps counting "Working for X" while thread is awaiting user input #1069
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
Start T3 Code on the latest main.
Open a plan-mode thread and send a prompt that causes the agent to ask a follow-up question.
Wait until the thread is clearly blocked on that question and shows Awaiting Input in the sidebar.
Leave the thread idle for an extended period without answering, for example overnight.
Return to the same thread.
Expected behavior
Once the agent is blocked on user input, the main chat timeline should stop presenting the thread as actively working.
One of these should happen:
the Working for ... timer stops or pauses while awaiting input, or
the row changes to an explicit awaiting-input state in the main timeline
The main thread view and the sidebar should agree on the thread state.
Actual behavior
The sidebar shows Awaiting Input, but the main chat timeline continues to show Working for Xh Ym, where Xh Ym includes the entire idle time while the thread was waiting on me.
This makes it look like the agent actively worked for hours when it was actually blocked on a question.
Impact
Minor bug or occasional failure
Version or commit
main
Environment
Web app ran with npx t3, latest main, Codex provider, Windows with WSL2 (Ubuntu)
Logs, stack traces, or screenshots
Related context:
- Issue #576 ("New Thread Status for 'Awaiting response'.") mentioned that the working timer should probably pause while awaiting response.
- That issue was closed via PR #701.
- PR #701 appears to have fixed the sidebar status, but not the main timeline timer/state wording.
Current behavior on latest main:
- Sidebar: "Awaiting Input"
- Main timeline: "Working for Xh Ym"
Awaiting-input is now a separate projected thread state, and the working timer/status is derived from the current turn state rather than continuing while blocked on a question.
This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.
Still seeing this on Nightly 0.0.46-nightly.20261007.2774 (macOS). When an agent asks me a question and I step away, the "Working for X" clock keeps counting the whole time it's waiting on my answer, so the time shown includes stretches where nothing was happening. I'd expect the clock to pause while a question or approval is waiting on me and pick back up when I answer.
Looking at the source for this build, runtime waiting still counts as working and the elapsed time is just now minus start, with no input-wait time subtracted. #1074 had a fix but was never merged. Could this be reopened?
Activity
fix: timer stops counting when waiting for user input (pingdotgg#1069)
fix: stop working timer when agent is awaiting user input
fix: stop working timer when turn is complete or awaiting user input
juliusmarminge commentedon Jun 20, 2026
Awaiting-input is now a separate projected thread state, and the working timer/status is derived from the current turn state rather than continuing while blocked on a question.
This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.
PrivateVictories-Main commentedon Oct 8, 2026
Still seeing this on Nightly 0.0.46-nightly.20261007.2774 (macOS). When an agent asks me a question and I step away, the "Working for X" clock keeps counting the whole time it's waiting on my answer, so the time shown includes stretches where nothing was happening. I'd expect the clock to pause while a question or approval is waiting on me and pick back up when I answer.
Looking at the source for this build, runtime
waitingstill counts as working and the elapsed time is just now minus start, with no input-wait time subtracted. #1074 had a fix but was never merged. Could this be reopened?