Repository navigation
Multi-repo: the files panel and @ search don't follow the .code-workspace folder list #323
Description
For a .code-workspace project, the files panel and @ file search don't show the folders the file lists. With two or more repos they show only the git folders, so a listed plain folder is left out. With one repo they show the whole workspace folder, so folders the file doesn't list show up.
A listed folder is left out (two repos)
~/dev/scope-test/
scope-test.code-workspace folders: api, web, docs
api/ git
web/ git
docs/ no git, listed
release.md
The files panel shows only api and web, and @release.md shows "No matching files or folders". To point the agent at docs/release.md, you have to type or paste the path.
Unlisted folders are shown (one repo)
~/dev/scope-test-three/
scope-test-three.code-workspace folders: api, docs
api/ git
docs/ no git, listed
luigi/ no git, not listed
yoshi.md
The files panel shows api, docs, luigi and the .code-workspace file itself, and @yoshi finds luigi/yoshi.md, although the file doesn't list luigi.
The other two combinations
Two repos with an unlisted folder (scope-test-two: lists api, web, docs; luigi on disk). The files panel shows api and web, so the listed docs and the unlisted luigi are both hidden, and @release finds nothing.
One repo, no unlisted folder (scope-test-one: lists api, docs). @release finds docs/release.md, and the files panel shows api, docs and the workspace file.
Why
Two decisions use the wrong signal:
- Which folders:
WorkspaceFile.readkeeps only listed folders that have a.git, asrepoRoots(apps/server/src/workspace/WorkspaceFile.ts:184-186). The listed plain folders aren't stored on the project. - Whether to show separate folders at all: the files panel and
@search only userepoRootswhen there are two or more (apps/web/src/components/ChatView.tsx:3653,apps/web/src/components/files/FileBrowserPanel.tsx:126). With one repo they fall back to the project's workspace root, which for a.code-workspaceproject is the folder the file sits in (ChatView.tsx:3630-3633). The comment on the@search roots expects that fallback to be the repo: "single-repo projects search the worktree-awaregitCwdalone" (ChatView.tsx:3674-3675).
The same fallback is why a one-repo workspace offers Initialize Git instead of Source Control (Scenarios B and D). With fewer than two repos, the header's git control runs on that workspace folder (apps/web/src/components/chat/ChatHeader.tsx:401-417), which has no .git.
How this differs from #313
#313 lists repoRoots in the agent's instructions, and its wording was narrowed so it doesn't say plain folders are outside the project (comment). This issue is about the files panel and @ search, which pick their folders from the same git-only list.
Question
Should the files panel and @ search follow the folders a .code-workspace lists, whether they have git or not and however many repos there are?
If yes, one way to do it: store the listed folders that exist on the project next to repoRoots, the same way repoRoots is stored. Every place that saves repoRoots already has the listed folders from the same read of the file:
- adding the project (
apps/web/src/components/CommandPalette.tsx:3086-3090) - saving the folders dialog (
apps/web/src/components/ProjectFoldersDialog.tsx:222-226) - the re-read when a project loads (
apps/web/src/hooks/useWorkspaceProjectReconcile.ts:106-113) - opening a workspace file from the desktop app (
apps/web/src/components/desktop/DesktopAppActivationCoordinator.tsx:77-80)
The re-read on load only updates the project when repoRoots or the file path changes (useWorkspaceProjectReconcile.ts:100-101), so it would need to compare the folder list too. Otherwise a hand edit that only adds or removes a plain folder wouldn't reach the project.
The files panel and @ search would then use that list for any project with a workspaceFile, and diffs, checkpoints and PRs would keep using repoRoots.
Activity
LoganRupe commentedon Sep 29, 2026
@dotrahat could you review #325 when you get a chance?
dotrahat commentedon Sep 30, 2026
@LoganRupe sure, I'll review that.
fix(web): files panel and @ search follow the .code-workspace folder …
dotrahat commentedon Sep 30, 2026
@LoganRupe, I reviewed #325 after it merged: #325 (comment)
All four scenarios from this issue pass on
75c7d8e37. The review lists four follow-ups (chat file links, the folder list only refreshing through Manage folders, one-repo workspaces not starting isolated runs, and mobile and agent access), which I can open as separate issues.LoganRupe commentedon Oct 1, 2026
@dotrahat thanks for the review, it was a big help. All four follow-ups are now on
multi-repo-workspaces(feee30eed5):.code-workspace, and the tree waits for the first read instead of flashing the old layout.@search follow the folder list, and agents can reach every listed folder. Plain folders are shared with isolated runs and sit outside checkpoints, which the docs now say.Two things I know are still open: mobile chat links don't use the folder list yet, and Codex may still block writes to folders outside its working directory.
If you get a chance to retest from a fresh build, I'd love to hear how it goes. I'll close this once you're happy, and please open new issues for anything else you find.
dotrahat commentedon Oct 1, 2026
@LoganRupe I'm happy to assist. I'll retest fresh build soon and share.
dotrahat commentedon Oct 2, 2026
@LoganRupe retested on a fresh build of
feee30eed, and all four follow-ups work:.code-workspacewas unreadable.docstoo, and in Auto-accept edits Claude's edit to a listed folder outside the workspace folder needed no approval (it only asked about a shell command it ran first). Codex asked for approval for the same write, as you expected.The original four scenarios from this issue, the folders dialog, and isolated runs in both two-repo and one-repo projects all pass. I didn't test mobile, since that needs a mobile build from this branch.
One new bug turned up while retesting: #335, where right-click actions in the files panel use the folder's display name instead of its real path. From my side, this one is good to close.