[Bug]: Sent message appears to start working only after returning to its thread

[jdlar18]

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)

1. Send a message in a thread during normal coding.
2. Stay in the desktop app and navigate to other T3 threads to read or chat.
3. Return after roughly one or two minutes in the specifically captured occurrence (the initial report described waits of around five minutes).
4. 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:

• ChatView enqueue path stores a running-turn follow-up in the local queue and returns before sending a server command.
• Queue selection reads messages for activeThreadKey.
• Automatic queue dispatch runs in a ChatView effect. 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.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.

[juliusmarminge]

The multi-minute stall matches the web/desktop follow-up queue, not a slow server start.

Working for counts from the turn start the server recorded. Projection fills that timestamp from the pending request when the session becomes running. A counter that begins near zero on return means thread.turn.start was issued around then. The same-day scan in this report (116 request-to-running gaps, largest about 10.6 seconds) fits that: the long wait is before the request.

With Settings → General → Follow-up behavior set to Queue (the default), a message sent during a running turn is stored only in the in-memory queue and is not sent yet (ChatView running-turn enqueue). The effect that later sends it watches the queue for the selected thread only. Switching threads reuses that one chat view for the thread you opened; leaving the chat layout, including Settings, unmounts it. The previous thread’s queue waits until you select it again, which is when the timer starts.

PR #13122 already reproduces this: finishing thread A while B is selected produces no send. It is open and not on main. CI on the latest commit is green.

A message sent while the thread is idle takes the immediate send path and does not need the thread to stay selected. Steer also sends during a running turn instead of queueing.

Mobile is a separate queue. #5436 is the same failure when the app is backgrounded, and #13122 does not change that outbox.

One captured send would still pin this occurrence: client surface, Queue vs Steer, whether a turn was already running, and the thread.turn.start time versus when you left and came back.

[jdlar18]

Thanks, this seems consistent with your explanation. I confirmed Follow-up behavior is set to Queue.

It just happened with a “please continue” message: I left the conversation, and it appeared to start only when I reopened it. I haven’t verified the server timing for this occurrence.

I usually send when the previous turn looks nearly finished, so I may be unintentionally queueing while it’s technically still running. That could explain why it feels intermittent—I don’t deliberately use the queue often.

I’ll watch for whether the previous turn is still running next time to confirm the match with #13122.