Concurrent sessions working on different repos interfer each other

[mleader1]

Description

This is my first day using Opencode, and I must say, I’m impressed. I’m a Claude Code user, so I was expecting something similar.

However, there’s a significant issue that’s holding me back. Our codebase is massive and consists of multiple repositories, each serving a different part of a large platform.

• rootDir
  | - repo 1
  |. - system A
  |. - - | System A - repo A.1
  |. - - | System A - repo A.2
  |. - - | System A - repo A.3
  | …
  |. - repo 2
  |. - repo 3
  etc. etc.

Each repository may contain a similar folder structure, such as /web/dashboard.

Today, I encountered several issues:

1. I created four terminal sessions (using Termius) to work in different repositories.
2. At the start of each session, I provided a clear definition and scope of the working repository boundaries to prevent tampering with other repositories.

Initially, everything worked well for the first few conversations. However, as I started working on some serious code (based on my “Implementation Plan”s), the four sessions became chaotic and extremely dangerous to work with. Eventually, I had to revert the last few commits they created because:

a) They started working on other repositories where the other three sessions were working.
b) The right-hand column statistics “Modified Files” showed a confusing mix of file changes across the four terminal sessions. They showed different numbers of modified files and interfered with each other, showing modified files that didn’t belong to their scoped repository.

Due to these issues, I had to give up. I’m not sure whether it’s an Opencode issue or a problem with the LM model (I used Claude as well as a few other models, switching between them during the test).

The issue above sounds chaotic, and it was chaotic to me as well, which is why I lost confidence in continuing to use it. I’m quite OCD about knowing exactly which files can and should be worked on.

I think this issue is only because I tried it on a platform codebase that contains over 30 repositories as the root for Opencode to operate on.

Regardless of the underlying issue, I believe it’s worth submitting my feedback. I really do love this product and its flexible model provider approach!

Thank you.

[github-actions]

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

• Sessions are now mixed with home directory session list, disregarding which directory you're in #3551: Sessions are now mixed with home directory session list, disregarding which directory you're in - describes similar directory-based session confusion
• [FEATURE]: tie working directory / directories with chat session #4048: [FEATURE]: tie working directory / directories with chat session - feature request to properly tie working directories with sessions
• Performance issue: session-child-cycle becomes extremely slow with many sessions #3526: Performance issue: session-child-cycle becomes extremely slow with many sessions - performance issues when dealing with many sessions
• Concurrency bug: Polaris edit session blocked by self-induced file change #4079: Concurrency bug: Polaris edit session blocked by self-induced file change - concurrency issues with file modifications across sessions

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

[rekram1-node]

so it sounds like for ur usecase having more finegrained control of the filesystem allowing u to control what that the agent can access would be important

[mleader1]

@rekram1-node My personal view is that the agent needs read access to the entire codebase for context understanding (and documentation references, as we have coding standards and system documentation in a centralized repo). However, it should also be restricted to work within the boundaries of the session’s scope (read and write permissions for serious coding work).

While there might be alternatives or compromises, such as setting the repo as root where Opencode starts, and referencing parent folders or other repos for references (I haven't tested this approach but I'm not going to either), this isn’t straightforward thinking and isn’t ideal for the agent to understand the bigger picture of the codebase they’re given to work on.

[tbarron-xyz]

Just an idea, you could use a read-only agent in the root dir for getting all context and writing an implementation plan, writing a plan file to the relevant sub dir. Then trigger an edit-enabled agent in the subdir, have it read the plan file and execute.

[tbarron-xyz]

I also just experienced this issue: b) The right-hand column statistics “Modified Files” showed a confusing mix of file changes across the four terminal sessions. They showed different numbers of modified files and interfered with each other, showing modified files that didn’t belong to their scoped repository.

I have one plan mode agent running in ./ planning things, and another build mode agent executing a plan in the same working dir (disjoint working areas). The Build agent edited 2 files. 1 of the edited files shows up in the Modified Files pane of the Plan agent, but not the other.