[Bug] All sessions are gone

[ddanielcruzz]

I ran the command /compact, it seemed stuck so I proceeded to quit the app and when I re-opened and try to list my sessions I found out all of them were gone 🥲

[github-actions[bot]]

This issue might be a duplicate of existing issues. Please check:

• #2928: bug: /compact is not interruptable - similar issue where compact gets stuck
• #2609: BUG: Compact + Queue interaction - issues with compact causing problems
• #2945: Session automatically compacted, destroying the entire working context - compact destroying session context
• #1548: compact zaps plan - compact causing data loss

The common pattern is that the /compact command can get stuck or cause unexpected behavior that results in loss of session data. Several users have reported similar issues where /compact appears to hang and requires force quitting the app, sometimes leading to session loss.

Feel free to ignore if none of these address your specific case.

[rekram1-node]

@ddanielcruzz all your sessions, everywhere?

[rekram1-node]

is there any chance this was in a project that didnt have any commits yet and then you did an initial commit?

[ddanielcruzz]

Hey @rekram1-node

1. I used opencode for only one project, so all my sessions were related to that project.

2. The repository had many commits. I initially started my session in a specific branch, but later switched to another branch to work on something else. I forgot to switch back and continued chatting. The responses were not accurate, which made me realize I was in the wrong branch. After switching back, I encountered a context window error, even though the TUI showed about 60% of the context in use, which was unusual. I decided to run /compact, but it got stuck, so I quit. After that, all my sessions were gone.

[rekram1-node]

@ddanielcruzz just wanna see the "damage" so to speak can you run a few commands and see if data is still there for me?

id=$(git rev-list --max-parents=0 --all)
ls ~/.local/share/opencode/storage/session/${id} # if this is empty then run next ls command and show output if possible
ls ~/.local/share/opencode/storage/session

git rev-list --max-parents=0 --all

^^ Run this in your project, it will give the project id, that can then be used to list sessions^^

[ddanielcruzz]

Hi @rekram1-node the latest data if from 2 days ago, so sadly my data is gone.

I encountered another issue where I closed a session as I added a new local MCP, once I re-opened I couldn't find the session in the list.

Running the commands you shared I have two directories, is that normal?.

I'm using git town to keep branches in sync as well as worktrees to have multiple instances of opencode in different branches. Not sure if it's related

[rekram1-node]

when u say running the commands shared which command and what was output?

[ddanielcruzz]

Running ls ~/.local/share/opencode/storage/session gives me two directories

[rekram1-node]

what if u use the id one?

[ddanielcruzz]

Running these two

id=$(git rev-list --max-parents=0 --all)
ls ~/.local/share/opencode/storage/session/${id}
# output
/.local/share/opencode/storage/session/7b9ebd75da850e8f2ce0013a13d973314c3c26c1\n97d5b7390b6695f5f8189e90aac11e97c707b93f\n15175d963f0ed863af3d3c0f6287ef8ab81db034\na8e844dad56388522ddbaa68a3285570d5cef7b3": No such file or directory (os error 2)

ls ~/.local/share/opencode/storage/session
# outputs two direcotries

[sjswerdloff]

I'm having a similar problem, but not related to compaction. I did compact, without interruption. I was able to continue, with no problem. Then I exited and restarted, and no sessions. started with dev (v.0.14.x?) yesterday, had this problem, updated to v.0.15.0 today, no joy. However a "new" session that I started is showing up as available. The old session ses_625e82ae4ffeJuaY06cCPYUQ3X.json was gone from the previous project subdirectory: ./session/4b0ea68d7af9a6031a7ffda7ad66e0cb83315750 and was in ./session/global

[rekram1-node]

there is a known issue that if you have a git repo without any commits, have sessions (they will be in global storage) then once you make commits you kinda “lose them” since the repo has commits and is no longer tracked in global

we ofc should handle this but does that sound like what may have happened for you?

[sjswerdloff]

there is a known issue that if you have a git repo without any commits, have sessions (they will be in global storage) then once you make commits you kinda “lose them” since the repo has commits and is no longer tracked in global

we ofc should handle this but does that sound like what may have happened for you?

#3123 fixed my problem. My first commit in the repo I was working in: Date: Mon Oct 13 16:44:45 2025 +1300 Problem occurred after that, so I started working on a fix for it with first commit in opencode branch Date: Mon Oct 13 18:17:05 2025 +1300

So, no, I don't think it had to do with a git repo without commits. It looks like a straight forward migration/backward compatibility issue. Not that at 0.x you owe anyone backward compatibility, but... for me, if I couldn't fix this quickly, I would have given up on opencode, which would have been a shame because it is exactly the kind of tool I have been looking for and really want to use (across a variety of LLMs, and support for Cerebras was a huge bonus, the qwen-code fork that supported Cerebras was not playing well with newer commits to qwen-code). Huge gratitude to the maintainers and contributors of opencode.
I used a Gemini in gemini-cli to help me find and fix (#3123) and it threw in the "--continue" type behaviour as an automatic thing (which works for me, I have what is perhaps a different approach than some/many) but isn't really appropriate given that --continue is an option) so you probably want to remove that particular part of it. I'm using a Claude Sonnet 4.5 (the session that got lost), and I'm really happy with how opencode works compared to Claude Code (and the stability/lack of unasked for automatic updates), and look forward to using it for gemini and qwen (without the sticky release issues or visible tearing when trying to avoid that issue).

[ddanielcruzz]

@rekram1-node I think multiple causes can trigger this bug. I got it again yesterday, in a repo with commits. What happened was that the agent started a dev server process and got stuck, my messages to tell it to stop got queued and trying to exit was not working. I kept hitting ctrl + c until it exited, after reopening opencode the session I just exited was gone.

[rekram1-node]

Hm okay, having a single session have that happen makes sense as a possibility, having all session disappear on the other hand seems very strange

thanks for sharing this

[remorses]

This happened to me (all sessions are gone) after I started a server with opencode serve then attached to it with opencode attach ...

Then listing sessions with /sessions in normal opencode returns nothing

[redtux]

Hi, I see several issues with this bug. (#3669 says this was closed.) Any idea already what's causing it? Maybe git reverts or update-ref? I still have my reflog, so can the old session somehow be restored? (Nothing crucial, I'm just curious...)

While /session in this repo is empty (this is a fresh repo with one commit, but the agent revered several times - as always without asking for permission lol) I can still see sessions when in another repo. The prompt history inside the app is working fine, and I can see 16 global sessions and 5 git sessions:

$ ls -1 ~/.local/share/opencode/storage/session/global  | wc -l                              
16

$ ls -1 ~/.local/share/opencode/storage/session | wc -l # minus 1 for "global"
6

$ ls -l ~/.local/share/opencode/storage/session | grep --count $(git rev-list --max-parents=0 --all)
0

[!NOTE] I did not use compact, and I did not upgrade the CLI. The program did exit without issues (no crash, etc.).

---

Version: 1.0.110 (Updating to 1.0.115 did not help btw...)

Edit: No servers were started and no opencode processes are running. The agent called a subagent asking it for a web search, but this all worked fine. I only realized the issue when coming home and starting opencode -c to continue were we left. 😺

[sirmo]

Esc to interrupt doesn't work for me, so I often <ctr-c> the whole client mid task. Which can sometimes result in the complete loss of session for me. <ctrl-c> exits immediately when it should have a graceful exit probably.

[redtux]

Hi @sirmo, it has been pretty quiet here for a while. When you lose your sessions, can you still see the files using the git hash as described above? It would be interesting to know if those sessions are really gone, or if the JSON files (for restoring them?) exist. I had no luck in restoring my sessions for the above project - but I still have hope… 🪄🤣

[sirmo]

Hi @sirmo, it has been pretty quiet here for a while. When you lose your sessions, can you still see the files using the git hash as described above? It would be interesting to know if those sessions are really gone, or if the JSON files (for restoring them?) exist. I had no luck in restoring my sessions for the above project - but I still have hope… 🪄🤣

Hi redtux. When I run the commands you provided this is what I see.

ls -1 ~/.local/share/opencode/storage/session/global  | wc -l
30
ls -1 ~/.local/share/opencode/storage/session | wc -l # minus 1 for "global"
11
ls -l ~/.local/share/opencode/storage/session | grep --count $(git rev-list --max-parents=0 --all)
1

I ran this from the project root where I lost the initial session. When I go to OpenCode client I can see 3 sessions there, but there should be 4 sessions, the original session disappeared when I cancelled the task by exiting OpenCode.

[rekram1-node]

I did some changes that should fix this, one of them lands in next release

[redtux]

I did some changes that should fix this, one of them lands in next release

Wow, cool! Will this also fix disappearing subagent sessions (in the first place when being called by another subagent), or is this another issue? I often have the issue that I cannot find the window anymore (with ctrl-x left/right) after switching window (by accident or to search some text in the previous window), and the bot said it's related to "a bug with session handling for subagents" but I'm not sure whether this is correct or not (I learned not to trust them too much in such cases 😂).

[rekram1-node]

im unfamiliar with this bug can u reliably reproduce it?

[redtux]

Sorry, haven't seen this. I guess that this can be reproduced by undoing all commits, or by running into certain bugs when calling subagents, but I don't know if there are certain steps to consistently reproduce this. I experienced this several times and I observed certain patterns, but I am afraid I don't know enough about the reason why this happens to provide a reproducible workflow for consistent testing.