Investigate virtual workspace roots set by other extensions

Resolved 💬 4 comments Opened Oct 18, 2025 by smaccoun Closed Jan 10, 2026

💡 Likely answer: A maintainer (gpeal, contributor) responded on this thread — see the highlighted reply below.

🐛 Bug: VS Code Codex searches entire filesystem instead of workspace (should ignore `writable_roots` for search)

Summary

When using the Codex VS Code extension, adding context or typing @ triggers a file search that crawls my entire disk.
Search should only look within the open workspace, regardless of what’s in writable_roots.

This causes multi-minute hangs before results appear and includes files from /System, /usr, etc.

---

🧩 Steps to Reproduce

Open a workspace (e.g., /Users/username/il/monorepo).
Open Codex chat.
Type @ or use “Add context” to search for a file.
Observe:

“Searching…” spinner runs for minutes.
Results eventually include files far outside the workspace (even system-level ones).

---

✅ Expected

File search should be scoped to the open workspace (or VS Code project folder).
It should not depend on writable_roots in ~/.codex/config.toml.
writable_roots should define where Codex can write, not what it can search.

---

❌ Actual

Codex’s session logs show that it adds / to writable_roots, causing a full-disk crawl:

"writable_roots": [
  "/Users/username/projects/monorepo",
  "/"
]

🖼️ Screenshot

Below, @AGENTS.md shows results from multiple system paths instead of limiting to the workspace:

!codex-global-search-bug

View original on GitHub ↗

4 Comments

gpeal contributor · 10 months ago

How are you opening your vs code project? This should only happen if / is a vs code workspace root.

If your vs code project has a code-workspace file, do you mind sharing it?

Does this happen on new conversations, follow-ups, and following up to a conversation you reopen after restarting vs code?

smaccoun · 10 months ago

Update: Root Cause Identified

Thanks @gpeal for the clarifying questions - they led me to discover the actual issue.

(fwiw, one might consider that extensions implementation questionable as well.....i think still could call this bug in codex but i understand arg that extension is wrong)

The Problem:
My monorepo.code-workspace file contains a second workspace folder added by the fildir VS Code extension:

{
  "folders": [
    {
      "name": "monorepo",
      "path": "."
    },
    {
      "name": "Filtered View",
      "uri": "fildir:/"
    }
  ]
}

The fildir extension adds a virtual filesystem root (fildir://) to browse the entire filesystem from VS Code. This causes Codex to treat / as a valid workspace root alongside the monorepo folder.

Key Finding:
My ~/.codex/config.toml does NOT have writable_roots configured, yet Codex still searches from /. This proves Codex is incorrectly prioritizing secondary workspace roots added by extensions.

Evidence This Is a Codex Bug:

Claude Code handles the exact same fildir setup without hanging or searching from /
VS Code's design treats the first folder in the workspace list as primary; extensions' virtual roots should not be treated equally
The extension should respect workspace hierarchy, not flatten all roots to the same level

Expected Behavior:
Codex should either:

Prioritize the primary workspace folder (the monorepo) for file searches, or
Provide a config option to exclude virtual filesystem extensions

Why writable_roots Isn't a Solution:
It's a global config that would break Codex for my other projects. It shouldn't be necessary—Codex should handle workspace structure correctly by default.

Recommendation:
Codex should prioritize the primary workspace folder for file searches, ignoring secondary roots added by VS Code extensions (like fildir://). This is how Claude Code and other IDE tools handle multi-root workspaces.