Agent host: file watches fail with ENOPRO in a remote window, because the host is handed vscode-remote URIs it cannot resolve

In a dev container window, every chat bind makes the agent host try to watch resources in the window's `vscode-remote://` namespace, which it has no file system provider for. The watch throws and the resource ends up unwatched.

## Symptom

```
[info] [Claude] Bound chat ahp-chat://default/… to fresh conversation …
[error] CodeExpectedError: ENOPRO: No file system provider found for resource
'vscode-remote://dev-container%2B7b22…/workspace/printstream'
at Fa.withProvider (…/out/vs/platform/agentHost/node/agentHostMain.js)
at async Fa.doWatch (…/out/vs/platform/agentHost/node/agentHostMain.js)
```

It fires immediately after `Bound chat … to fresh conversation`, every time. Across four log directories on this machine there are 104 occurrences, 73 of them in a single day's log.

Three resources fail, all addressed as `vscode-remote://dev-container+…`:

| resource | what it is |
|---|---|
| `/workspace/printstream` | the workspace folder |
| `/workspace/printstream/.claude` | the project customizations directory |
| `…/.vscode-server/data/agentSessionData//attachments/` | a session's attachments directory |

The third is the odd one: that path is internal to the agent host, under its own `.vscode-server` directory, yet it is being addressed in the window's remote namespace.

## Why it fails

The agent host runs inside the container and serves its own files as plain `file:` paths. It has no provider registered for `vscode-remote`, and the source does not appear to expect one: the only reference to `Schemas.vscodeRemote` under `src/vs/platform/agentHost` is an identity comparison in `agentHostConfigurationSync.ts`. So a `vscode-remote://` URI reaching `IFileService.watch` in the host has nowhere to resolve.

The watch call sites that match the three resources above are:

- `agentHostFileMonitorService.ts` (`_createEntry` → `this._fileService.watch(folder, …)`) for the workspace folder
- `claudeSessionCustomizationDiscovery.ts` (`this._register(fileService.watch(uri, …))`) for `.claude`

## Ruling out a local cause

I run a set of local patches against the shipped bundle, including several that change how agent host paths are expressed in a remote window, so I tested whether those were responsible rather than assuming.

Same window, same dev container, same one-line prompt, counting new ENOPRO entries produced by a single chat turn:

| workbench patches | ENOPRO from one turn |
|---|---|
| applied | **+4** |
| the four remote-window path patches reverted | **+6** |

It reproduces with those patches reverted, slightly more often, so they are not the cause. The stack, the trigger and the failing resources are identical in both runs.

## Impact

The watch never attaches, so the host is not notified of changes to the workspace folder, to the project's `.claude` customizations, or to the session's attachments. I have confirmed the watches fail; I have not traced each downstream consequence, so I am reporting the failure rather than asserting what specifically stops updating as a result.

It is also noisy: each occurrence logs an error with a stack trace, which makes the agent host log harder to read when looking for real failures.

## Environment

VS Code 1.135.0 (`08d4889f9ec4a1685d257b9b95de036c8e1ce1e5`), dev container on Docker, agent host running in the container. Client is Windows, container is Debian on arm64.

Related, in that they are all the client and host disagreeing about which namespace a path belongs to: #330979, #331526, and the cluster in #333174.

*AI disclosure: this issue and the related investigation were written with the assistance of AI.*

### Public patches and patcher scripts

[Public patch catalog and patcher scripts](https://github.com/RyanEwen/vscode-patches/blob/main/CATALOG.md) · [Source patch index](https://github.com/RyanEwen/vscode-patches/blob/main/SOURCE-PATCHES.md). The [public collection](https://github.com/RyanEwen/vscode-patches) includes the maintained patchers, rollback instructions, regression scripts, and historical snapshots. Build restrictions and exact installer coverage are documented there.