> **Note:** This issue description was originally drafted from AI-generated analysis (GitLab Duo Chat) of the codebase and related issues. The "Proposed fix" section below has since been revised after implementation — see the "Status" note. ### Summary Classic Duo Chat and Duo Agentic Chat both render via `LsWebviewController`, which loads content from a URL provided by the Language Server (`http://127.0.0.1:<port>/webview/<id>`). In remote/browser-based environments (e.g. VS Code Web via Coder), this loopback address can be unreachable from the browser, which runs separately from the remote extension host. Classic Duo Chat already has a fallback for this: when the `gitlab:isRemoteEnvironment` context key is true (or the `languageServerWebviews` feature flag is disabled), the extension switches to a legacy, non-LS-hosted chat implementation (`src/common/chat/gitlab_chat_view.ts`) that talks to the backend directly instead of depending on the LS's local HTTP server. See the `when` clauses in `package.json` / `desktop.package.json`, e.g.: ```json "when": "... && (!gitlab.featureFlags.languageServerWebviews || gitlab:isRemoteEnvironment) ..." // legacy webview "when": "... && (gitlab.featureFlags.languageServerWebviews && !gitlab:isRemoteEnvironment) ..." // LS-hosted webview ``` **Agentic Chat and Agentic Tabs have no equivalent fallback, and setting `languageServerWebviews: false` does not fix them** — confirmed both by code inspection and by a customer report on gitlab-org/gitlab#604254 who tried that exact workaround. That flag/`when`-clause pair only swaps `gl.webview.duo-chat-v2` back to the classic `gl.chatView`; Agentic Chat and Agentic Tabs are wired only through `src/common/webview/setup_webviews.ts` → `LsWebviewController`/`LSDuoChatWebviewController`, with no non-LS-hosted equivalent to swap to. This relies on `vscode.env.asExternalUri()` / the remote-authority resolver implementing automatic loopback port forwarding, which isn't reliable (or in pure browser-based VS Code Web, isn't possible at all) for some remote/web setups — resulting in the "Unable to connect to localhost" error reported by a customer. ### Status: short-term fix implemented The originally-proposed short-term fix below (extend the classic-chat `isRemoteEnvironment` fallback/flag-swap to Agentic Chat) turned out to be the wrong shape of fix, for two reasons: 1. There is no non-LS-hosted implementation of Agentic Chat to swap to (unlike classic Duo Chat's `gitlab_chat_view.ts`), so a swap-based fallback would have nothing to fall back to — it would have meant pointing users at classic Duo Chat as a substitute, which is a worse product experience and was explicitly rejected. 2. The failure isn't universal to "remote" — the localhost port is often reachable in Remote-SSH/Dev Containers (forwarding works), so blanket-disabling Agentic Chat for every `gitlab:isRemoteEnvironment` session would break it even where it would have worked fine. What shipped instead, in `src/common/webview/ls_webview_controller.ts`: - `LsWebviewController` now **awaits** its existing `#isUrlAvailble()` reachability check (previously fire-and-forget, only logged) before deciding what to render. Agentic Chat/Tabs (and every other LS-hosted webview) still attempt to load normally, in any environment — nothing is disabled preemptively. - Only when the localhost URL is genuinely unreachable does it render a clear, GitLab-branded error screen (via a generalized `getErrorScreenHtml()`) instead of a silently-dead iframe or the raw "webview didn't initialize in 10000ms" / browser network-error page. - The message is environment-aware via `vscode.env.uiKind` (see comment below): on the VS Code **desktop** app (including Remote-SSH/Dev Containers/WSL) it points to the Ports panel and firewall/VPN/antivirus settings, which is reliably actionable there. In browser-based VS Code (`uiKind === Web`, e.g. vscode.dev, github.dev, Coder), it instead explains that port-forwarding may not be supported at all in that environment and suggests the desktop app or filing a report, rather than confidently pointing at a Ports panel that may not exist for that provider. - `LSDuoChatWebviewController` skips its own redundant `#waitForChatReady()` timeout when the base class already reported the URL unreachable, so its more specific message isn't overwritten by the generic "didn't initialize" one. This does **not** restore Agentic Chat functionality in environments where the localhost port is structurally unreachable (e.g. plain browser-based VS Code Web without tunnel support) — see the "longer-term architectural fix" note below for that. ### Related issues - https://gitlab.com/gitlab-org/gitlab/-/work_items/604254 — customer-facing tracking issue (moved from https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/2303); has **Customer Interest** label and an active pubsec FSI customer escalation; confirms the `languageServerWebviews: false` workaround does not fix Agentic Chat - https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1944 — "Duo Chat fails to initialize in VS Code Web environment" (fixed for classic Chat) - https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1943 — "Duo Chat fails to initialize in VS Code Remote SSH environments" (fixed for classic Chat) - https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/2145 — "GitLab Duo Chat is not available on VSCode Web" (still open; suggests the existing classic-chat fallback may itself be incomplete and worth re-validating separately) ### ~~Proposed fix (short-term)~~ — superseded, see "Status" above <details> <summary>Original proposal (not implemented as written)</summary> Extend the same remote-environment detection/fallback used for classic Duo Chat to also cover Agentic Chat and Agentic Tabs: 1. In `src/common/webview/setup_webviews.ts`, extend the `isRemoteEnvironment`-gated branching (currently only wired for `DUO_CHAT_WEBVIEW_ID`) to `AGENTIC_CHAT_WEBVIEW_ID` and `AGENTIC_TABS_WEBVIEW_ID`. 2. Provide (or reuse) a non-LS-hosted rendering path for Agentic Chat when remote, mirroring the pattern in `gitlab_chat_view.ts`, so it doesn't depend on `vscode.env.asExternalUri()` succeeding. 3. Update the relevant `when` clauses in `package.json` / `desktop.package.json` for the Agentic Chat / Agentic Tabs commands and views, matching the existing classic-chat pattern. 4. Verify against a VS Code Web (Coder) environment and against Remote-SSH, since #2145 suggests the existing fallback doesn't cover every web/remote setup. Superseded because there is no non-LS-hosted Agentic Chat implementation to swap to (step 2 has nothing to reuse), and gating on `isRemoteEnvironment` alone would have disabled Agentic Chat even in remote setups where the port is actually reachable. </details> ### Note: longer-term architectural fix (still out of scope here) A separate, longer-term architectural fix (removing the network/tunnel dependency for webview content and messaging entirely, e.g. bundling webview assets as local extension resources via `webview.asWebviewUri()` and relaying messages over the existing LSP connection instead of a parallel HTTP/Socket.IO server) is out of scope for this issue and should be tracked separately. This is the only approach that would restore full Agentic Chat functionality in environments with no localhost path at all (e.g. plain browser-based VS Code Web without tunnel support).