[Bug]: [Critical]: T3Code forgets complete session history

[degrootruben]

Before submitting

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

Area

apps/desktop

Steps to reproduce

I had a few sessions that we're a bit more long running research threads. They are on Worktrees usually with a fresh branch.

If I come back to the session after a few days Opus has completely forgotten about the session history and treats it as a fresh session, which means I need to copy my whole session history in a user message to be able to continue (and copying the session history in T3Code is nearly impossible if there is plan UI elements and diff UI elements in the thread).

This has happened for multiple sessions.

See screenshot.

Expected behavior

We should just be able to continue on the thread with the session history that is there.

Actual behavior

The session is treated as completely fresh

Impact

Major degradation or frequent failure

Version or commit

0.0.21 (188df6d)

Environment

macOS Tahoe 26.4

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Copy the whole session history and add as user message (very annoying and hacky)

[betterthanclay]

I've had this with Opus a number of times recently when it completes a turn around when context fills and compaction happens. It just completely forgets the whole thread and the conversation has to start from scratch.

[a-chugunov]

Happened to me with Codex as well. Haven't had it before t3@0.0.21. Seems to be v0.0.21 issue?

[juliusmarminge]

gonna need a reproduction to debug this more. i've not experienced this on 0.0.21

[alexanderwford]

I've experienced this a bunch of times. The conversation just breaks. It's as if everything is forgotten. Often after only a single round of work. It's caused me to fear starting new conversations and I've spent the last week back in Claude code instead. Came here looking to see if this had been reported.

I don't think time is a factor. It's happened inside active conversations. It's not just because time has passed.

[betterthanclay]

I've not had it happen in the last few days now.. it's a hard one to replicate as it seems to be based on timing around ending a turn at the point of compaction rather than time between turns. It's only been with Claude too - I wonder if it was partly an issue on their side that has since been fixed? I will post details if it does happen again.

[mci-kmd]

This does sound an awful lot like the caching optimization bug in Claude Code described here: https://www.anthropic.com/engineering/april-23-postmortem (Under the "A caching optimization that dropped prior reasoning" header). This was fixed in Claude Code v2.1.101 on April 10th, so maybe unlikely, but if people are stuck on an old version I guess it could be related.

[sbward]

I'm using OpenCode + DeepSeek API and I also have this issue frequently

[mattgoody]

I have been having this issue using OpenCode with a Kimi subscription. I have not had any issues with Claude or Codex/ChatGPTt, but I am using their official CLI's through t3code.

Repro evidence from the OpenCode provider side (Linux, t3 desktop, opencode 1.18.3, Kimi K3 via kimi-for-coding).

What happened: Mid-conversation (active thread, minutes between turns), the agent responded with zero knowledge of everything prior in the thread. From the T3 UI it looked like one continuous conversation.

What the opencode session DB shows: a single T3 conversation maps to multiple opencode sessions. In ~/.local/share/opencode/opencode.db, table session, there are 7 sessions with the identical title T3 Code f62fc6b6-bcdd-45d8-a4f0-f3e077c2c553 (the T3 conversation ID), all in the same directory:

opencode session	input tokens	created (UTC)	lifespan
ses_077c6538fffeG7mu6CYCKPGlEk	152,991	2026-07-22 05:08	~73 min
ses_07780816effeIE7I7y9i6RbLkr	28,061	2026-07-22 06:24	~34 min
ses_077450bf1ffesv2zCiGpwnHY3t	11,618	2026-07-22 07:29	~1 min
ses_076ed8746ffeMgACC8YgX0nEoo	13,113	2026-07-22 09:05	~1 min
ses_074527210ffeWl7c046EBlh6pX	24,855	2026-07-22 21:13	~19 min
ses_073245c2affeSh1z6u5cZerHuu	104,286	2026-07-23 02:43	~31 min
ses_072e871a5ffeY1kWW7QAQzKyOs	109,275	2026-07-23 03:49	current

The user-visible "forgot everything" event is the ses_0732... → ses_072e... transition (03:14 → 03:49 UTC): the next user message in the same T3 thread was routed to a brand-new opencode session with parent_id: null, so the model started cold. The old session's full history (54 messages, 245 parts) is still intact on disk — never compacted, never resumed, just abandoned.

Log evidence: zero occurrences of compact in the entire 1.8 MB ~/.local/share/opencode/log/opencode.log. No compaction was ever attempted by opencode. The old session exited cleanly after its 51st loop step with no error, and 35 minutes later the log shows a fresh created id=ses_072e... with the identical T3 title.

Hypothesis: T3 (or its opencode provider layer) creates a new provider session for the same T3 thread instead of resuming/compacting the existing one — possibly related to #3601 (large-thread resume being expensive/fragile on the opencode provider). Note the trigger is not purely context pressure: two of the rotated sessions above lived ~1 minute at ~12–13k input tokens. The UI keeps rendering one continuous thread, so the history loss is invisible until the model responds with no context.

Full evidence bundle (DB rows, per-session message/part counts, log excerpts) collected in a markdown file — I've attached it here.

t3code-2343-evidence.md

[repparw]

Same root cause as mattgoody's evidence above — adding another confirmed reproduction (OpenCode provider, DeepSeek, Linux).

Repro: One continuous T3 thread in the GUI, but the opencode side rotated to a fresh session mid-conversation. The model answered "no context" despite the UI showing one unbroken thread.

opencode side (~/.local/share/opencode/opencode-stable.db, table session): the T3 thread 4cee89ea-ad75-451e-88f8-58afd26b3d6d maps to 3 opencode sessions with the identical title T3 Code 4cee89ea-ad75-451e-88f8-58afd26b3d6d in the same directory:

opencode session	created (UTC)
ses_04a7b6971ffekIOlY3dGoksayF	2026-07-31 00:13
ses_04a7787c7ffeVvy407u9LkqisI	2026-07-31 00:17
ses_041b93918ffeXswMZEuZ7MJOmg	2026-08-01 17:02

The user-visible "forgot everything" event is the third transition: the message was routed to ses_041b... created fresh with parent_id: null, title: "New session - ...", auto-titled later. The old sessions' full history is intact on disk — never compacted, never resumed.

Not just the current thread. Across the whole opencode DB, 27 of 95 T3 threads have duplicate sessions with the same T3 Code <uuid> title (many with 3). So this is systemic, not one-off context pressure:

• 1f622fff-... → 3 sessions (2026-07-31 13:34, 17:03, 08-01 15:24)
• aace89e3-... → 4 sessions (2026-06-19 → 06-22)
• 718c70a7-..., 56895413-..., dbf7ffd8-... → 3 each

Strongest evidence — T3 side (~/.t3/userdata/state.sqlite, projection_thread_sessions): provider_session_id is NULL for every single row across all threads/providers. T3 never persists which opencode session a thread binds to; it relies on the T3 Code <uuid> session title to find/resume. When that lookup fails (or a fresh thread continuation skips it), a brand-new opencode session is created with parent_id: null.

Log evidence: no compact events in the opencode log around either rotation. The old session exited cleanly; opencode's own compaction/resume never triggered.

Why it's invisible: the T3 UI keeps rendering one continuous thread (opencode session IDs aren't surfaced), so history loss appears only when the model replies with zero prior context.

Suggestion: persist the durable opencode session_id (or a thread↔session binding) in projection_thread_sessions instead of deriving it from a mutable session title, and have the opencode provider resume that ID. Happy to attach a fuller DB/log dump if useful.