Repository navigation
[Bug]: t3code should resume same conversation after idle timeout ? #2378
Description
Before submitting
- 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 the conversation with opencode and come back after 1 hour
- ask agent to delete some orphan code in the same conversation.
- opencode start with fresh context and did some unexpected deletion .
Expected behavior
no unexpected deletion :)
Actual behavior
opencode started with fresh context and lost previous context.
actually I think you should always resume previous opencode session since we still in the same conversation box. claude code / codex already did so.
Impact
Major degradation or frequent failure
Version or commit
0.0.21
Environment
Web
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
No response
Reacted by Sebastián Maluk
Activity
carltonawong commentedon Apr 30, 2026
Same-conversation resume is one of those places where transcript restore is necessary but not sufficient.
The safer contract is probably: reload prior messages, but also show a small current-state receipt before the agent acts again: active repo/worktree, last observed tool result, pending plan/decision, and what was rechecked after the idle timeout. That helps avoid the dangerous case where the UI looks continuous but the agent is operating from a fresh or stale state.
sarpuser commentedon May 4, 2026
Can confirm that this is also an issue with Claude Code. Resuming a thread after a long timeout erases the context. This should ideally be done with --resume. While the thread and the messages in it show up correctly, the agent starts fresh. See attached image.
carltonawong commentedon May 4, 2026
Thanks, that distinction is useful: the UI/thread can look restored while the runtime has actually started from a fresh agent state.
I think the product contract should make that visible before the next tool call: which session id was resumed (or not), last message/tool boundary restored, active repo/worktree, and what was rechecked after the timeout. Otherwise
--resumebecomes implicit hidden state instead of an auditable handoff.mdmdj commentedon May 8, 2026
I'm not sure if this is exactly the same thing but I am having the problem where T3 Chat doesn't pick up it's own session from OpenCode and will create a new one. On the T3 Code side it looks like the same session but the agent doesn't see anything from before
T3 Chat:
OpenCode:
juliusmarminge commentedon Jun 9, 2026
Duplicate of #2980
Same underlying behavior: the idle session reaper kills the provider session after ~30 minutes and resuming silently loses context. #2980 documents the root cause (inactivity threshold + force-kill) across all providers, so consolidating the discussion there.