Fetching context from adjacent repositories in the same GitLab Group

[arsalanyavari]

Hello PR-Agent team and community,
I have set up PR-Agent using the gitlab_webhook image on my self-hosted GitLab instance. My setup consists of a single GitLab Group containing multiple related repositories.
I've encountered a scenario where a Merge Request in one repository modifies code that utilizes a package/library whose source code resides in a different repository within the same GitLab Group.
My question is: How can PR-Agent understand this cross-repository context?
Is there a way to configure the agent so it can fetch the necessary context or files from the secondary repository? I want the AI model to be aware of the package's logic from the adjacent repo so it can provide an accurate and relevant review for the MR in the primary repo.
I checked the documentation (including features like repo_context and Agent Skills) but couldn't find anything that explicitly supports pulling context from other repositories automatically.
If this feature is natively supported, could you please point me to the relevant documentation? If it is not supported out of the box, do you have any suggested workarounds or best practices to achieve this?
Thank you in advance for your help and time!

[IsmaelMartinez]

There is no cross-repository context today, and nothing in the configuration can enable it. Repo context resolves files through the provider bound to the merge request, and the GitLab implementation is scoped to that single project, reading only paths relative to its own tree, so repo_context_files cannot reach a sibling project. The one tool that ever cloned an arbitrary repository was /help_docs, and it has been disabled since v0.36.1 as mitigation for a credential-exposure vulnerability, so any design here has to avoid that shape. Agent Skills are host-level filesystem paths, useful for sharing written guidance across your group but not for pulling a neighbouring repository's source.

The practical workaround is to vendor the interface you want reviewed against, an API summary or type stubs rather than the whole library, into the consuming repository and list that file in config.repo_context_files; group-wide configuration can be shared via extra_config_url or the global settings repository.

I have opened #3299 to track this properly, with the credential and scoping questions written up. Please follow that issue for progress. Closing this thread in favour of it so the work lives in one place.