[Bug]: Rewind offers file restoration in a workspace where the backend rejects it #36464

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

The UI sequence below is the reporter's observed experience; the backend rejection is independently confirmed in traces. No screenshot or fresh UI reproduction is attached.

1. Start a conversation in an existing/shared project checkout, without creating an isolated worktree.
2. Make changes through the agent and accumulate conversation checkpoints.
3. Open the rewind controls and request a rewind that includes file restoration.
4. Submit the request.

Expected behavior

The UI should reflect whether file restoration is available for the current workspace before allowing submission. When unavailable, disable that option and explain the reason next to it, while clearly offering conversation-only rewind.

When choosing a workspace at session creation, disclose that this choice limits later file rollback. If a safe migration/recovery path exists, offer it explicitly; otherwise make the limitation clear before work begins.

The backend restriction may be a necessary safeguard against overwriting another conversation's changes. This report asks for accurate capability presentation and early explanation, not removal of that safeguard.

Suggested acceptance criteria:

• The rewind dialog obtains file-restore eligibility before submission.
• An ineligible workspace has a disabled file-restore option with an actionable explanation.
• Conversation-only rewind remains available and clearly states that files stay unchanged.
• Workspace creation communicates the recovery limitation.
• If eligibility changes while the dialog is open, the UI handles rejection without implying files were restored.

Actual behavior

The rewind UI allowed the user to request file restoration, but the backend rejected it because the workspace was not an isolated worktree. The prerequisite became apparent only when recovery was needed, after work had accumulated in the session.

A later conversation rollback succeeded, but that did not provide the file recovery initially selected. The interface presents a recovery action that cannot succeed in the current configuration. Conversation rewind and filesystem restoration have materially different outcomes; this late failure creates uncertainty about what was restored and leaves manual recovery work.

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.1.9

Environment

Linux desktop application; existing/shared project checkout rather than an isolated worktree. The prerequisite concerns workspace isolation, not a provider permission mode.

Logs or stack traces

The checkpoint.rollback request failed with this error excerpt:

File restore requires an isolated worktree.

The remaining error explanation identifies potentially shared changes and suggests conversation-only rewind or removing unneeded side chats. A failed rollback trace confirms the eligibility rejection. The selectable UI option is based on the reporter's account, not a saved screenshot. Local paths, identifiers and stack frames are omitted.

Screenshots, recordings, or supporting files

No response

Workaround

Conversation-only rewind is available, but does not undo files. Starting future work in an eligible isolated worktree avoids this specific limitation; it does not retroactively recover changes in an existing session.