### Summary When troubleshooting a recent DAP outage we quickly noticed that if you had an open GitLab project and had an open agentic chat session, if you were to open a new window and navigate to a completely different project the agentic chat would still make changes on your initial project. The caveat is that as long as the projects are semi similar or forks of the same initial project (in this case our base workshop project) it will never determine that you are working on a totally separate code base. However if you navigate to something completely different it does track that your project is different. The total impact for this is probably pretty low, but could cause major problems for people actively forking or migrating work. ### Steps to reproduce 1. Have 2 versions of similar projects, I will provide two different forks of the same workshop project (reach out if you need access) - but this seems to work with anything: https://gitlab.com/gitlab-learn-labs/events/session-g9g7m3x2z/group-x2x8y9t/dap-swag-shop/-/work_items https://gitlab.com/gitlab-learn-labs/events/session-g8d2j4g7p/group-m6t6m5n/dap-swag-shop/-/work_items 2. Open agentic chat in the first one and ask it to create an issue for you of some sort, the type of issue does not matter. 3. Dont close that window, but open a new window with the second project. Chat will most likely still be open - ask it to create a new issue on your current project. 4. Navigate back to the inital project and check to see that both issues you asked chat to make have been created just on the initial project. ### Example Project https://gitlab.com/gitlab-learn-labs/events/session-g9g7m3x2z/group-x2x8y9t/dap-swag-shop/-/work_items https://gitlab.com/gitlab-learn-labs/events/session-g8d2j4g7p/group-m6t6m5n/dap-swag-shop/-/work_items Please reach out to @lfstucker for access ### What is the current _bug_ behavior? Chat not swapping project context ### What is the expected _correct_ behavior? Chat swaps project context based on project id ### Relevant logs and/or screenshots Examples are in the projects provided above ### Output of checks <!--If you are reporting a bug on GitLab.com, uncomment below--> This bug happens on GitLab.com <!--and uncomment below if you have /label privileges--> <!--or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not--> ### Possible fixes Base project context on id - it sees that the context is based on project content ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!--If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"`-->