[VS Code] First-class virtual workspace support with a non-breaking native-root transition

Open 💬 1 comment Opened Aug 5, 2026 by RobinLin666
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

IDE Extension 26.721.41059

What feature would you like to see?

Please add first-class support for VS Code virtual workspaces backed by a custom FileSystemProvider, and provide a compatibility path for virtual workspaces that also expose a native agent/configuration root.

Today the IDE extension derives workspace roots from workspaceFolders[].uri.fsPath. As described in #36680, ordinary non-file: URIs can produce values that are not valid native absolute paths and fail downstream.

There is also a useful limited-mode case that should not be lost while fixing that bug: a virtual-workspace provider can shape its URI path around an existing native "agent anchor" directory. Codex then receives a fully qualified native root, starts successfully, loads project-local AGENTS.md, skills, and .codex/config.toml, and connects to MCP servers. The actual project content remains virtual and is accessed through VS Code APIs or MCP tools.

This behavior is currently incidental. A fix that filters solely on uri.scheme === "file", or a manifest change that disables Codex in all virtual workspaces, would break this working integration before first-class VFS support exists.

Could the team share whether virtual workspace support is planned and, if so, the target release or milestone?

Requested behavior:

  1. Treat the logical VS Code workspace URI and the native Codex execution root as separate concepts.
  2. Use vscode.workspace.fs for virtual resources where possible, with graceful limited-mode behavior for features that require native disk access.
  3. Add an explicit way for a virtual-workspace provider or user setting to supply a native execution/configuration root.
  4. When fixing invalid virtual roots, validate the actual native-path contract rather than rejecting every non-file: scheme.
  5. Until an explicit replacement ships, keep fully qualified, existing native roots usable even when their workspace URI scheme is virtual.
  6. Declare virtual workspace support as limited and document the limitations instead of disabling the extension entirely.

Additional information

This request is not asking Codex to rely permanently on Uri.fsPath for non-file: URIs. It asks for a supported replacement for the native-anchor pattern and a non-breaking transition so current limited-mode integrations continue to work.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 23 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #36680

Powered by Codex Action