Continue .continue files ENOENT when project opened in VS Code Dev Container?
Continue 1.0.15 in VS Code 1.101.2 on Windows 10 throws 'ENOENT: no such file or directory, open C:\Users\kai\AppData\Local\Programs\Microsoft VS Code\vscode-remote:\dev-container...workspaces\src.continue\rules\pythonExpert.yaml' when the project is reopened in a Dev Container. Other users reported the same error for .continue/docs, .continue/mcpServers, and .continue/agents files. Is this a known bug and is there a workaround?
Originally asked on GitHub: https://github.com/continuedev/continue/issues/6320
6 answers
The issue went stale and was closed as not planned; no fix is described in the thread and there is no maintainer explanation. The root cause reported by users is that the Continue extension runs on the VS Code host by default and tries to resolve .continue files through the host path C:\Users...\vscode-remote:\dev-container..., which does not exist inside the container.
Workaround confirmed by multiple users: force the extension to run as a workspace extension by adding this to the global VS Code user settings.json: { "remote.extensionKind": { "Continue.continue": "workspace" } }
After that, .continue rules, agents, and project config files load from inside the container.
Additional steps from the thread: one user had to mount the host config into the container to keep seeing the models config, for example in the docker-compose.yml volumes section:
- ~/.continue/config.yaml:/root/.continue/config.yaml (using /root/ because the devcontainer user was root). Another user ran Continue inside a Dev Container with a project config at .continue/agents/project-config.yml using apiBase http://host.docker.internal:11434 for a host Ollama instance, and did not need to mount ~/.continue.
Caveat: one user reported that the workspace setting made LAN-hosted Ollama unreachable with ETIMEDOUT; docker network prune fixed the overlapping Docker subnets. This is user-reported configuration advice, not an official fix.
Did this work for you?What a GitHub user tried on GitHub (Outcome unclear)
Reporter created a project with devcontainer.json, added a rule/prompt under .continue, and reopened the project in the Dev Container; Continue returned ENOENT for each .continue rules/prompts file using a Windows host path. This was a bug reproduction, not a fix attempt.
Source: https://github.com/continuedev/continue/issues/6320 (opens external site)
Did this work for you?What @dannysemi tried on GitHub (Worked)
Added "remote.extensionKind": {"Continue.continue": "workspace"} to the global VS Code user settings.json.
Source: https://github.com/continuedev/continue/issues/6320#issuecomment-3124877224 (opens external site)
Did this work for you?What @krsyoung tried on GitHub (Partly worked)
Applied the workspace extension workaround on a Mac with a local .continue/config.yaml; agent YAML files loaded, but LAN-hosted Ollama models were unreachable with ETIMEDOUT. docker network prune resolved overlapping Docker subnets.
Source: https://github.com/continuedev/continue/issues/6320#issuecomment-3319768964 (opens external site)
Did this work for you?What @SCP002 tried on GitHub (Worked)
With the workspace setting active, mounted ~/.continue/config.yaml to /root/.continue/config.yaml in the docker-compose.yml volumes section so Continue could see the models config (used /root/ because the devcontainer user was root).
Source: https://github.com/continuedev/continue/issues/6320#issuecomment-3500565461 (opens external site)
Did this work for you?What @bchanez tried on GitHub (Worked)
Used a Dev Container with the workspace setting and a project config at .continue/agents/project-config.yml, with provider ollama and apiBase http://host.docker.internal:11434; Continue loaded the project config and reached the host Ollama model without mounting ~/.continue.
Source: https://github.com/continuedev/continue/issues/6320#issuecomment-3684218390 (opens external site)
Did this work for you?