Agent memory is one of the best parts of modern agentic tooling. It makes long-running work feel continuous, cuts down on repeated setup, leaves an audit trail, and keeps the context window from filling up with the same background over and over.

That only helps, though, if the agent knows where one project ends and another begins.

Recently I ran into a case where OpenCode did not make that distinction. I had two local clones of the same Git repository checked out to different branches, and OpenCode treated them as the same project. Memory, snapshots, and task state started leaking across clones.

The Symptom

The setup looked like this:

  • ~/projects/clone-a on feature-alpha
  • ~/projects/clone-b on feature-beta

Those were separate directories with separate working trees, but OpenCode behaved as if they were one logical workspace. I could be in one tmux session on feature-alpha and suddenly see context from feature-beta. Worse, the agent would act on that borrowed context with total confidence.

Once that happens, the session is effectively poisoned. The closest analogy I can think of is two construction workers operating power tools and suddenly swapping brains.

The Likely Cause

This appears to match OpenCode issue #17940.

The key detail seems to be project identity. OpenCode appears to derive it from shared repository characteristics, such as remote and root identity, rather than the full local path. If two separate clones share enough Git identity, they can collapse into one logical OpenCode project record. Then the snapshot and worktree metadata from whichever clone was opened last can overwrite the other.

To be fair, that behavior is not obviously wrong in every workflow. If you want a shared memory layer across multiple checkouts of the same repository, it might even feel convenient. But if the goal is branch or clone isolation, it is a footgun.

That is what makes this kind of bug so unsettling. The system is not merely forgetting context. It is reusing the wrong context with enough confidence to act on it.

There is a proposed fix in PR #17943. The approach is to make project identity path-aware, so distinct local clones become distinct OpenCode projects while true Git worktrees can still be treated appropriately. I do not know whether or when that will land in a release.

A Workaround That Works Today

If you want hard isolation right now, give each launch its own XDG_DATA_HOME.

I ended up with shell functions like this:

oc-clone-a() {
  (cd "$HOME/projects/clone-a" && XDG_DATA_HOME="$HOME/.local/share/opencode-clone-a" opencode "$@")
}

oc-clone-b() {
  (cd "$HOME/projects/clone-b" && XDG_DATA_HOME="$HOME/.local/share/opencode-clone-b" opencode "$@")
}

With that arrangement, each clone gets its own:

  • project records
  • snapshots
  • task history

One caveat: auth state is stored under XDG_DATA_HOME too, so each isolated profile has to be authenticated at least once.