[Bug]: T3 re-sends every earlier turn to a resumed Claude session #14391

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

I hit this on a long-running Claude thread and don't have a deterministic repro. The T3 event store and the Claude transcript line up exactly, so both are below.

1. Run t3 serve with the Claude provider in full-access runtime mode.
2. Keep one thread going for several hours. Mine had 13 turns between 13:16 and 18:06 UTC, and each one completed normally.
3. Send another message. Mine went out at 18:57:29 and the turn finished at 18:58:02.
4. Wait. At 18:58:12, with no user action, T3 restarted the thread's Claude session. A new claude --output-format stream-json process started and resumed the same Claude session ID.

Expected behavior

A resumed session gets only new input. T3 never sends a turn that already ran to the provider a second time.

Actual behavior

T3 sent all 13 earlier turns to the new Claude process as fresh input, and the agent started working on them again.

T3 event store. Right after the last turn settled, T3 appended 13 thread.session-set events with status: "starting" to the thread's stream in orchestration_events. Their sequence numbers are new but their occurred_at values are stale. Each one matches the time of an earlier thread.turn-start-requested on the same thread.

seq    occurred_at           event
69877  2026-09-28T18:58:02   session-set ready            <- last real turn done
69881  2026-09-28T13:16:50   session-set starting (server)
69882  2026-09-28T13:16:50   session-set starting (server)
69884  2026-09-28T13:23:54   session-set starting (server)
69886  2026-09-28T14:00:34   session-set starting (server)
69887  2026-09-28T14:12:20   ...
69888  2026-09-28T14:12:46
69889  2026-09-28T14:47:47
69890  2026-09-28T14:50:01
69891  2026-09-28T17:57:45
69892  2026-09-28T17:59:49
69893  2026-09-28T18:00:49
69894  2026-09-28T18:02:01
69895  2026-09-28T18:03:13
69896  2026-09-28T18:06:57
69899  2026-09-28T18:58:13   session-set running (new activeTurnId)

Claude transcript. The resumed session's ~/.claude/projects/<dir>/<session>.jsonl shows the new process receiving 13 inputs on stdin within 22 ms.

18:58:13.864Z  queue-operation enqueue   x9
18:58:13.885Z  queue-operation enqueue   x4
18:58:15.034Z  user: [9 text blocks]   <- 9 earlier user messages, answered hours before, glued into one turn
18:58:39.605Z  user: /orchestrate ...   <- earlier slash-command prompt, run again
18:58:56.896Z  user: /route-work ...    <- earlier slash-command prompt, run again

None of those inputs was new. What worries me is what they contained. Some of the replayed messages were instructions I'd given hours earlier to run bulk database updates, and those updates were already done. The agent caught it, replied "This message looks like a replay of your earlier messages joined together", and skipped the writes. A less careful turn would have run them twice. The replayed /orchestrate and /route-work prompts did start new work, in a project checkout that other threads were also using. From where I sat, agents appeared out of nowhere and overwrote each other's files and branches.

Impact

Major degradation or frequent failure

Version or commit

0.0.43-nightly.20260928.2375. It was installed at 15:38 UTC on 2026-09-28, and the next nightly didn't land until 20:06 UTC, after the incident.

Environment

Linux 7.0 x86_64, t3 serve --host 127.0.0.1 with the web client, Claude Code CLI 2.1.285, provider claudeAgent, model claude-opus-5-5 with 1M context, full-access runtime mode. The thread ran in local mode, not in a worktree.

Logs or stack traces

# New provider process, started at the moment of the replay. From `ps` the next day.
3624728  Mon Sep 28 18:58:12 2026  /path/to/project  claude --output-format stream-json --verbose --input-format stream-json ...

# Idle Claude processes for the same project, still alive at that point.
2644209  Thu Sep 24 12:32:25 2026  /path/to/project  claude --output-format stream-json ...
3620458  Thu Sep 24 17:34:31 2026  /path/to/project  claude --output-format stream-json ...
4142837  Thu Sep 24 20:27:49 2026  /path/to/project  claude --output-format stream-json ...

Two more things I saw on the same machine. They may share a cause.

• Provider processes for idle threads were still running 5 days later, each one a live agent in the same working directory.
• I sent SIGTERM to those three idle processes at 14:10:36 UTC on 2026-09-29. Three new claude processes started in the same directory between 14:10:39 and 14:10:41, and the old threads went back to ready.

This might be related to #14115, where several servers share one base dir and resume each other's threads. I can't say how many servers were running at 18:58 on 09-28, because the trace logs have rotated past that time. The replay above happened inside one thread and one Claude session.

Workaround

Give every thread that writes code its own worktree, so a replayed turn can't touch another thread's checkout. Stop threads when you're done with them instead of leaving them idle.