Repository navigation
feature: ability to rewind #338
Description
When working with AI tools, they occasionally wander off in a direction we don't want or get stuck in a loop that requires additional input or guidance.
It would be great if we could rewind the state as much as needed. This would roll back file changes and messages to a previous point in time. Ideally, we could choose how far to rewind using the keyboard or something similar, then provide additional input and let the AI explore possible solutions again.
This feature would be especially helpful for optimizing context usage and reducing input costs by avoiding unnecessary or repetitive queries.
Possible implementation considerations:
- Initially, when rolling files back, it might be possible to rely on rolling back write tool usage. However, sometimes LLMs batch replace content in files using tools like
sed, so a more advanced solution may be needed. - A possible solution is relying on Git.
- An issue is that this might clutter the user's Git usage.
- We could get the list of changed files and keep an entire copy of them in a database.
- One problem with this is that the project folder might not be using Git at all. In that case, we could disable the rewind feature or only allow rewinding write tool usages.
- UX could be like pressing
Ctrl+Shift+Ror something similar to enter rewind mode, then using the up and down arrow keys to navigate backward and forward through the history. The output could be grayed out while navigating, withEnterto roll back to the selected point in time orEscto exit rewind mode and return to normal operation.
On the previous v0.0.52 version, I was manually editing the SQLite database, rolling back files using Git, and restarting the app to reload the context.
Is there any interest in this, or is my workflow just very bad? :)
Activity
khalido commentedon Jun 25, 2025
fyi, the new Gemini cli handles this with a shadow git folder: https://github.com/google-gemini/gemini-cli/blob/main/docs/checkpointing.md
codetorex commentedon Jun 26, 2025
Hmm, interesting. Though I don’t like the idea of storing data in the home directory, especially under a hash that is meaningless to humans. Anything related to the project should be kept in the project folder. Something like /.opencode/history would be a far better option, in my opinion.
InsightfulFuture commentedon Jul 12, 2025
+1, especially if restoring allows you to edit past messages
SerialVelocity commentedon Jul 24, 2025
Ideally, it would be possible to also just to rollback the chat without also rewinding file changes. This is quite useful when you want to keep previous context, but ended up using lots of the context window just trying to implement something.
I've also used claude code like this when processing files. I can rewind, tell it that folder X has been processed previously, now just process folder Y. Otherwise, I end up hitting the context window limit.
dikkadev commentedon Jul 26, 2025
I like the previous points from this issue! Just another use-case that would be supported with this:
Suppose in a longer conversation the agent just finished a task/feature but it's not quite right (point A). Multiple message iterations are done to fix it in the same chat. It would be most useful to be able to go back to point A to continue the conversation normally but still have the fixes/changes without the tokens used in those messages after point A.
What's really unclear to me is what the UX should be like to do these things. Rollback with file changes and rollback without file changes. Would we also want branching? Probably not at first?
SerialVelocity commentedon Jul 27, 2025
I think there's probably different milestones to get something like this implemented:
Main reason for that ordering is that (1) and (2) are easy. They could even be tackled in the same PR most likely, but if it is complex for some reason, it can be split apart.
(3) is probably more difficult because you have to figure out whether to implement this with shadow git repos, or something else.
Open questions for that:
sed,tr, or an inlinepythonscript?dikkadev commentedon Jul 30, 2025
I agree with the milestones split.
(3) probably needs even more questions and answers when it comes to actually doing it and supporting a range of use cases. A separate issue to track those that conversation would probably be good at some point.
But 'just' (1) and (2) would provide use-cases, though they should be made with (3) in mind IMO
dikkadev commentedon Jul 30, 2025
It's probably good to note that in part this is already implemented over a snapshot sysytem.
#1268
And released, but disabled except in dev mode (?), in https://github.com/sst/opencode/releases/tag/v0.3.61
nerdo commentedon Aug 2, 2025
this may seem like a workaround, but i've been using it with pretty good results in claude code.
i use jj and colocate my repos with git. tldr: i don't let claude make changes with git but I give it pretty broad permissions with jj.
the result is that it can use version control locally to handle creating milestones, describing changes, etc. and claude code doesn't need to be concerned with how it happens. version control is incredibly complex, and that's effectively what I think this discussion is about.
rekram1-node commentedon Aug 29, 2025
checkpointing support was added, with redo & undo
Enelass commentedon Feb 3, 2026
The
/timelinecommand claims to offer rewind functionality but fails to deliver. It displays a message suggesting it can restore previous states, yet nothing actually happens.OpenCode is missing a critical feature that most CLI tools provide as standard: a functioning
/rewindcapability. This is not just inconvenient, it's dangerous. Users who discover that the advertised rewind feature doesn't actually work are left exposed to potential data loss. By the time you realise the safety net isn't there, it's already too late.Enelass commentedon Feb 3, 2026
This issue should be re-opened
feat(headless): bundle openwork server for openwrk (anomalyco#338)
mattcoleanderson commentedon Sep 16, 2026
@Enelass does /timeline revert still not work properly for you? I just tried it and it worked like a charm. Reverted all subsequent messages and file changes and reduced my used context window. Maybe a fix was introduced between your comment and now.