[FEATURE]:Inter-Project Context Bridging: Enable LLM Collaboration Across Sessions

[enesgur]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

What do you want to change or add?

I would like to propose a feature that allows two distinct active sessions (projects) within Opencode to communicate and share context with each other.

The Core Concept:
Imagine a scenario where a user has two open projects:

• Project A: A consumer application (e.g., Frontend or a Dependent Service).
• Project B: A dependency provider (e.g., Backend API or Core Library).

Currently, these projects run in isolated silos. I propose adding a "Link Session" or "Dependency Bridge" mechanism. Once linked, the LLM instance in Project A should be able to query or "talk" to the LLM instance/context of Project B.

Proposed Workflow:

1. Open Project A and Project B in separate Opencode windows/tabs.
2. In Project A, select an option to "Add Context from Active Session: Project B".
3. When asking the LLM in Project A to write an integration code (e.g., "Write a function to fetch user data from the API"), the LLM can reference the actual implementation details (routes, DTOs, models) currently existing in Project B’s active session.

What are the benefits of implementing this?

Implementing this feature would significantly enhance developer productivity in multi-repo environments:

• Seamless Integration Development: It eliminates the need to manually copy-paste code snippets (contracts, API schemas) from one project to another just to provide context to the LLM.
• Real-time Synchronization: If a developer modifies an API endpoint in Project B, Project A's LLM immediately "knows" about the change, reducing integration bugs caused by outdated documentation or context.
• Holistic Code Awareness: It mimics a "monorepo" experience for multi-repo setups, allowing the AI to understand the full flow of data from the database (Project B) to the UI (Project A).
• Error Reduction: The LLMs can cross-verify types and method signatures between projects, acting as an intelligent integration linter.

[github-actions]

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

• How do you handle multi-application collaboration and context handoff in OpenCode? #9777: How do you handle multi-application collaboration and context handoff in OpenCode? (directly addresses cross-session context sharing for dependent applications)
• Feature Request: Model-Agnostic Memory Layer (Global & Per-Project) #8043: Feature Request: Model-Agnostic Memory Layer (Global & Per-Project) (proposes persistent context/memory mechanism across sessions and providers)
• [FEATURE]: Multi-Agent Coding #9649: [FEATURE]: Multi-Agent Coding (discusses agent collaboration and context handoff between different agents)

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

[antonio-ivanovski]

Don't find the justification good enough for such a feature, also see that CC has done something similar.

Isn't it a better approach to have a shared spec that the two agents coordinate on and can both read from it. For example the spec can have tasks for backend and tasks for frontend with a special section of the API that will be used.

[enesgur]

Don't find the justification good enough for such a feature, also see that CC has done something similar.

Isn't it a better approach to have a shared spec that the two agents coordinate on and can both read from it. For example the spec can have tasks for backend and tasks for frontend with a special section of the API that will be used.

I see your point regarding the Shared Spec, and I agree it's the best approach for maintaining a "Single Source of Truth."

However, I feel that a Spec is the result of the work, not necessarily the best channel for the process itself.

When we are building a completely new feature (greenfield), there isn't a spec yet. The agents need to "negotiate" and handshake to decide on the data structures first. If we rely solely on reading/writing a file to coordinate, the feedback loop becomes much slower.

Think of it like debugging: If Agent A tries to consume an endpoint and fails, it should be able to tell Agent B, "Hey, this didn't work, check your parameters," directly. Doing this via a static file feels a bit too rigid and might reintroduce the need for manual intervention/testing.

Maybe a hybrid approach is the sweet spot? They communicate directly to iterate fast, but update the Shared Spec as the final output.