<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "feature" label: - https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues?label_name%5B%5D=type%3A%3Afeature and verify the issue you're about to submit isn't a duplicate. ---> ### Problem to solve <!--What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)."--> **Summary** When using GitLab Duo Agent Platform features (Agentic Chat, flows, agents) from an IDE, the extension only recognizes a GitLab project if the IDE workspace root is the Git repository root (directory containing `.git`). If a user opens a **subfolder** of a Git project as the workspace, Agent Platform features often report that Agentic Chat is not supported for the current project or have no project context, even though the folder is inside a valid GitLab project. This is especially painful for monorepos or large projects where developers routinely open only a subdirectory (service, package, or component) in the IDE. **Current behavior** * IDE workspace root is a **subfolder** of a GitLab project (e.g. `project/api/` instead of `project/`). * The `.git` directory lives in the parent folder (`project/.git`), not in the workspace root. * GitLab Duo Agent Platform diagnostics / status report something like: * `Agentic Chat is supported for the current project: false` * Agentic Chat / flows either: * Do not appear at all, or * Appear but have no project context (cannot resolve project path, cannot access repo files properly). * A similar limitation is already tracked for **git worktrees**, where Agentic Chat shows `Agentic Chat is supported for the current project (false)` in the worktree even though it works in the main clone. **Expected behavior** * When the user opens **any subfolder of a Git repository that is connected to a GitLab project**, Duo Agent Platform features in the IDE should: * Correctly detect the **Git repository root** above the workspace folder. * Correctly resolve the GitLab remote and associated project. * Enable Agentic Chat and other DAP features with full project context, even if the IDE is not opened at the Git root. **Why this matters** * Many users of large monorepos or structured repos prefer to open only the relevant subdirectory in their IDE. * Requiring everyone to open the repo root just so DAP can detect the project: * Causes confusion (“Why is Agentic Chat not supported here but works in the UI?”). * Leads to inconsistent UX between GitLab UI and IDE. * Makes GitLab Duo Agent Platform feel brittle/unreliable in real-world monorepo workflows. **Proposed behavior / design ideas** Implementation details are up to the Editor Extensions / DAP teams, but from a user perspective: 1. **Detect Git root above workspace** * When the workspace root has no `.git`, walk up parent directories until a `.git` directory (or worktree config) is found. * Use that directory as the repository root for: * Mapping remotes to GitLab projects. * Determining eligibility for Agent Platform (Agentic Chat, flows, agents). 2. **Honor Git worktrees and alternative layouts** * Ensure the same logic works for: * `git worktree` directories (already tracked in `gitlab-vscode-extension#2203`). * Multi-root workspaces where each root may map to a different Git repo / GitLab project. 3. **Diagnostics & UX** * Update `GitLab: Diagnostics` / language-server logs to explicitly say: * Which directory was detected as the Git root. * Which remote and GitLab project were matched (or why none was matched). * If DAP is disabled only because no Git root was detected above the workspace, surface a clear hint: * e.g. “No Git repository found above this folder. Either open the project root or configure a default Duo namespace.” ### Proposal <!--How are we going to solve the problem?--> ### Further details <!--Include examples, use cases, benefits, goals, or any other details that will help us understand the problem better.--> ### Links / references