[Bug]: Nightly — conversation/agent context from one Project leaks into another when running parallel tasks across multiple Projects

Summary

On T3 Code Nightly, when running multiple parallel agent tasks across multiple Projects, a conversation/session that belongs to Project A in the UI sometimes ends up with the agent reading context from Project B (wrong project workspace / conversation history). The frontend still shows the thread as belonging to Project A, so the mismatch is easy to miss until the agent starts working against the wrong codebase.

Environment

• Channel: Nightly
• App: T3 Code desktop / web GUI
• Repro scenario: Multiple Projects open; multiple agent tasks running in parallel across those projects

Steps to reproduce

1. Open T3 Code Nightly with two or more Projects configured (e.g. Project A and Project B).
2. In each project, start one or more concurrent agent tasks (parallel sessions / threads).
3. Keep several agents running at the same time across those projects.
4. Continue chatting or inspecting agent tool use / file access in a session that the UI lists under Project A.

Expected behavior

• Each session is strictly scoped to its Project.
• The agent’s working directory, conversation history, and injected project context always match the Project that owns the thread in the UI.
• Parallel tasks across projects must not share or swap conversation/context state.

Actual behavior

• Intermittently, a thread that appears under Project A in the T3 Code frontend has its agent operating on Project B’s context (wrong workspace / files / prior conversation belonging to another project).
• From the UI, the session still “belongs” to the current project, which makes the corruption look like a normal in-project chat.
• This appears under multi-project + multi-parallel-task load; it is not 100% every run (race / routing bug likely).

Impact

• High risk of wrong-repo edits, leaked secrets/context across projects, and confusing agent behavior.
• Hard to trust multi-project parallel workflows on Nightly until fixed.

Notes / possible causes (speculation)

Could be related to session/thread ID routing, shared global state for “active project”, message projection across threads, or a race when multiple agents start/resume concurrently. Related historical issue in spirit (cross-thread collision): #871 — but this report is specifically cross-Project context leakage under parallel multi-project use, not only same-project thread collision.

Requested follow-ups from maintainers

If useful for triage, I can try to capture:

• Exact Nightly build version / commit
• Provider used (Codex / Claude / Cursor / OpenCode)
• Whether worktrees were involved
• Logs / screenshots showing UI project assignment vs agent cwd / opened files

Thanks!

Start by reproducing the multi-Project, parallel-agent scenario described in the issue and compare the UI project assignment with each agent's working directory, conversation history, and injected project context. Trace session/thread routing and shared active-project state during concurrent starts or resumes; done means parallel sessions remain isolated and a regression test covers the cross-Project case.