Repository navigation
Opencode Desktop - files touched in submodules aren't shown in Review panel #10658
Closed as not planned
Description
Description
The review panel showing edited files in the Desktop app only shows the files from the main repo, not the ones in the submodule.
Plugins
No response
OpenCode version
1.1.35
Steps to reproduce
- open opencode desktop in an environment with a submodule
- ask opencode to edit a file inside the main repo
- ask opencode to edit a file inside a submodule
- notice the review panel doesn't show the edited file, only the one in the main repo
Screenshot and/or share link
No response
Operating System
macos 26
Terminal
No response
Reacted by Philip Kocanda, Aleksi Wikman and 飞飞余
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Jan 26, 2026
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
panta82 commentedon Jan 28, 2026
I've explored this a bit. It's not a trivial fix.
Seems opencode detects a repo in current work dir. Then if it has one, before it starts work, it creates a snapshot under
~/.local/share/opencode/snapshot/(id). After it finishes, it uses git-diff to list the changed files between current snapshot and the saved one. Later, it can perform more elaborate diffs, but it's always between two single git snapshots based on the work dir.This covers the most common use case.
But it doesn't cover:
To handle this properly, a session would need to track a list of snapshots, for all detected repositories inside it, and not just the top repository. Then generate snapshots for each one, and compare them all. And what if you tell the agent to create / remove repos inside the work dir? Ugh.
Other option would be to ignore the project's own git entirely, and create an entirely separate private version control, for the sole purposes of tracking changes within the worktree. Ignore own repos, ignore submodules. Just always create a hidden git, and always track changes. Like JetBrains Local History.
This is IMO the correct approach. But it'd require a pretty significant changes to how change tracking works. Like I said, no easy fix. :/
abrouaux commentedon Jan 29, 2026
I guess what matters here is how these snapshots are made technically? Is it a shallow clone? Why is it impacted by the submodule bounds?
panta82 commentedon Jan 29, 2026
I looked a bit more. Refined my initial understanding.
Opencode creates a hidden git repo it seems and tracks changes that way. Unfortunately, git will NOT index child git repos (including submodules) and there's no way to make it. I tried. So opencode would have to track a series of snapshots for all git submodules underneath.
My super dumb, super not-recommended workaround:
PATH)jeremyakers commentedon Jan 29, 2026
Would this also impact the ability to do /undo on changes that happen in nested git repos? That could be a big deal if people don't understand this nuance.
I am kind of shocked that OpenCode would be set up this way. I am not really even sure how one would ever set up a workspace for any reasonably complex project under a single git repo for. I work on projects for example where there is a server written in C (src repo). A website where some web API clients have to interface with that C code (public_html repo), and the actual file assets that are read and served by the server (lib repo)
It doesn't make sense for these to be tracked in the same repo: When I branch the server source, I rarely want to branch the website or the file assets at the same time. Most changes to the server are independent from the website and file assets, and vice versa.
But not ALL changes are independent. So I need these to all be available for editing in the same workspace, because if I am adding a feature to the website that requires adding a new API to the server: I need both code trees in a single workspace where they can be edited/tested together. So I have a parent git repo that houses the parent "workspace" and then within that I have an "_agent_work" folder where every agent I'm running sets up their own clones of the src, lib, and public_html repos and does their work from there. I simply use .gitignore to have the parent git repo ignore the subrepos.
I have been primarily using Cursor before trying out OpenCode, and Cursor handles this layout without any issues, is able to roll back agent changes no problem, etc.
panta82 commentedon Jan 29, 2026
Agent will figure out subrepo management. The real problem is that opencode doesn't detect the changes and show them in UI due to the limitations of git itself and/or the way they are using it. And yes, that will also be a problem with undo/snapshots AFAIK (not an expert, I only looked at this for like a hour or two, trying to solve my own problem).
So far, my solution to this is:
Lustyn commentedon Feb 3, 2026
In my case, this is happening for a workspace with multiple repositories, but without a root-level repository at all. It is part of our build tooling to have multiple repos checked out alongside each other and open them together in your editor / agent.
abrouaux commentedon Feb 5, 2026
I feel like it's tied to a bigger feature (snapshots / reversals, reverting to a previous state anywhere in the session).
Is there a discussion related to that subject in the roadmap?
dylanmoz commentedon Feb 7, 2026
Dealing with this issue as well. I tend to work in a folder above several Git repos so that I can work across them with a single OpenCode session. It would be nice to be able to see the changes in the web version of OpenCode.
Yuruzuu commentedon Feb 17, 2026
still an issue in 1.2.6, review panel doesn't show anything, neither does the diff view below the agent's response appear. I'm working with a folder that's not connected to any GitHub repository. the Codex app handles this really cleanly though, it would be nice if it's fixed in OC
awikman commentedon Mar 3, 2026
Having the same issue as well.
Even getting a note about the sub modules as whole having changes would be improvement (similar togit status).EDIT: Looks like it now shows the sub module as changed:
That's already a major improvement.
abrouaux commentedon Mar 5, 2026
Another big pain point is that any work I do, from a higher-level project, on submodule files, is that not only they don't show up in review, but the /undo doesn't undo anything on those files.
And that is very annoying if I don't manage my commits in parallel with opencode (which feels really detached)
github-actions commentedon Jul 6, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.