Summary
After sending a message and leaving its thread, I can spend roughly five minutes doing other things, return to the thread, and see it apparently only start working then: the working-time counter begins on return rather than reflecting the time away.
This makes it difficult to trust that submitted work is progressing unattended. The report is based on observed use; we have not yet established whether execution itself is delayed or whether the client is displaying stale progress.
Steps to reproduce (reported workflow; not yet a deterministic repro)
- Send a message in a thread during normal coding.
- Stay in the desktop app and navigate to other T3 threads to read or chat.
- Return after roughly one or two minutes in the specifically captured occurrence (the initial report described waits of around five minutes).
- Observe the working-time counter start at approximately 1, 2, 3 seconds, creating the impression that work only starts on return.
The reporter thinks the agent was not working when the delayed message was sent, but does not remember with certainty. Treat an ordinary send into an idle thread as a primary case to investigate, rather than assuming a queued follow-up.
Still to establish for a captured occurrence: whether the previous turn was still running (queued follow-up versus an idle-thread send), and whether new provider activity really begins only on return.
Expected behavior
Once a message is submitted, it should be dispatched when eligible without requiring its thread to remain selected. Returning to the thread should show accurate progress and elapsed time. If a submission is still only local/pending, that should be clear.
Actual behavior / impact
The thread appears not to begin work until revisited, potentially losing several minutes of unattended work per occurrence. The reporter experiences this frequently, approximately twice per day. A recent occurrence was within roughly 20 minutes before their follow-up during this investigation; they do not remember the affected thread. The exact trigger remains unconfirmed.
Environment
- Installed server at investigation time:
0.0.43-nightly.20260923.2150, running as a persistent Linux user service.
- The reporter confirms this happens in the desktop client. Recent server connection records identify macOS/Electron desktop on the same nightly; the OS/version of the specific occurrence was not separately confirmed by the reporter.
- Source inspected:
f5ef0ddb90a8c36584e181b1913e7b8a5df30ffc (local main checkout; not asserted to be the exact installed release commit).
Read-only investigation
No live services were restarted and no application state was modified.
For September 23, a scan of persisted thread.turn-start-requested events and subsequent same-thread thread.session-set events with status running matched 116 transitions. The largest observed gap was approximately 10.59 seconds, not five minutes. This is a coarse same-thread correlation, not proof about the specific reported occurrence; it does not measure time spent in a client queue before dispatch, and does not prove provider output had started.
The projected projection_turns.requested_at and started_at fields alone are not independent timing evidence: the projection code can fill both from the pending request timestamp.
Conditional queue hypothesis (may not explain this report)
The reporter’s recollection that the agent was idle weakens this hypothesis: the queue path below requires an already-running turn and may be unrelated. Ordinary idle-thread sends and stale progress rendering still need investigation.
Separately, the web/desktop follow-up queue appears tied to the selected chat view:
This suggests a targeted repro: queue a follow-up in thread A, switch to B before the next eligible dispatch boundary, let A finish, then return to A and check whether dispatch happens only then. This candidate repro has not been executed in a browser.
Related
#5436 describes queued mobile messages being delivered only after reopening the app. It may share the underlying cause if this report also turns out to involve queued follow-ups. This report leaves that relationship explicit rather than assuming all ordinary sends have the same bug.
Next useful evidence
Capture one affected send with client surface, queue/steer setting, prior turn state, send/navigation/return timestamps, outgoing thread.turn.start timing, and first provider activity. That should distinguish delayed client dispatch from server startup delay or stale UI/timer rendering. No private messages, raw database, credentials, or session identifiers are included here.
Follow-up on the captured occurrence
The reporter confirms that leaving means navigating between threads inside the desktop app, reading/chatting in other threads while expecting the submitted work to run. On returning after approximately one or two minutes, the counter starts at 1, 2, 3 seconds. This is not a report of closing the client.
The reporter cannot confidently map the server acceptance time (19:57:41 Bogotá) to the original send versus the return. Consequently, the captured server timeline still does not distinguish pre-dispatch delay from stale progress or elapsed-time rendering. Actual absence of provider execution throughout the time away is not established.
Summary
After sending a message and leaving its thread, I can spend roughly five minutes doing other things, return to the thread, and see it apparently only start working then: the working-time counter begins on return rather than reflecting the time away.
This makes it difficult to trust that submitted work is progressing unattended. The report is based on observed use; we have not yet established whether execution itself is delayed or whether the client is displaying stale progress.
Steps to reproduce (reported workflow; not yet a deterministic repro)
The reporter thinks the agent was not working when the delayed message was sent, but does not remember with certainty. Treat an ordinary send into an idle thread as a primary case to investigate, rather than assuming a queued follow-up.
Still to establish for a captured occurrence: whether the previous turn was still running (queued follow-up versus an idle-thread send), and whether new provider activity really begins only on return.
Expected behavior
Once a message is submitted, it should be dispatched when eligible without requiring its thread to remain selected. Returning to the thread should show accurate progress and elapsed time. If a submission is still only local/pending, that should be clear.
Actual behavior / impact
The thread appears not to begin work until revisited, potentially losing several minutes of unattended work per occurrence. The reporter experiences this frequently, approximately twice per day. A recent occurrence was within roughly 20 minutes before their follow-up during this investigation; they do not remember the affected thread. The exact trigger remains unconfirmed.
Environment
0.0.43-nightly.20260923.2150, running as a persistent Linux user service.f5ef0ddb90a8c36584e181b1913e7b8a5df30ffc(local main checkout; not asserted to be the exact installed release commit).Read-only investigation
No live services were restarted and no application state was modified.
For September 23, a scan of persisted
thread.turn-start-requestedevents and subsequent same-threadthread.session-setevents with statusrunningmatched 116 transitions. The largest observed gap was approximately 10.59 seconds, not five minutes. This is a coarse same-thread correlation, not proof about the specific reported occurrence; it does not measure time spent in a client queue before dispatch, and does not prove provider output had started.The projected
projection_turns.requested_atandstarted_atfields alone are not independent timing evidence: the projection code can fill both from the pending request timestamp.Conditional queue hypothesis (may not explain this report)
The reporter’s recollection that the agent was idle weakens this hypothesis: the queue path below requires an already-running turn and may be unrelated. Ordinary idle-thread sends and stale progress rendering still need investigation.
Separately, the web/desktop follow-up queue appears tied to the selected chat view:
activeThreadKey.ChatVieweffect. A source search found no separate background dispatcher for this store.This suggests a targeted repro: queue a follow-up in thread A, switch to B before the next eligible dispatch boundary, let A finish, then return to A and check whether dispatch happens only then. This candidate repro has not been executed in a browser.
Related
#5436 describes queued mobile messages being delivered only after reopening the app. It may share the underlying cause if this report also turns out to involve queued follow-ups. This report leaves that relationship explicit rather than assuming all ordinary sends have the same bug.
Next useful evidence
Capture one affected send with client surface, queue/steer setting, prior turn state, send/navigation/return timestamps, outgoing
thread.turn.starttiming, and first provider activity. That should distinguish delayed client dispatch from server startup delay or stale UI/timer rendering. No private messages, raw database, credentials, or session identifiers are included here.Follow-up on the captured occurrence
The reporter confirms that leaving means navigating between threads inside the desktop app, reading/chatting in other threads while expecting the submitted work to run. On returning after approximately one or two minutes, the counter starts at 1, 2, 3 seconds. This is not a report of closing the client.
The reporter cannot confidently map the server acceptance time (19:57:41 Bogotá) to the original send versus the return. Consequently, the captured server timeline still does not distinguish pre-dispatch delay from stale progress or elapsed-time rendering. Actual absence of provider execution throughout the time away is not established.