When importing Codex sessions whose cwd is a Git worktree of an already-open repo, CodeG sometimes registers the worktree folder as a top-level workspace folder instead of grouping it under the repo root.
Example local state:
- Root repo:
C:\_Data\Projects\WowApps
- Worktree grouped correctly:
C:\_Data\Projects\worktrees\churn-report-edit-entries
- Worktrees shown incorrectly as top-level:
C:\_Data\Projects\worktrees\admin-danger-zone-edit-area-on-vendor-editC:\_Data\Projects\worktrees\pricing-investigation
DB evidence:
folder.id = 32, path ...\churn-report-edit-entries, parent_id = 1folder.id = 33, path ...\admin-danger-zone-edit-area-on-vendor-edit, parent_id = NULLfolder.id = 34, path ...\pricing-investigation, parent_id = NULL
All three are valid Git worktrees from C:\_Data\Projects\WowApps according to git -C C:\_Data\Projects\WowApps worktree list --porcelain.
Likely cause:
The normal worktree registration path uses open_worktree_folder_core, which writes the parent repo id via folder_service::add_folder_with_parent(...).
But the session import path in src-tauri/src/commands/conversations.rs calls plain folder_service::add_folder(...) for imported session cwd paths. That creates/reopens a normal folder and leaves parent_id = NULL. It does not resolve whether the imported cwd is a Git worktree belonging to an existing root folder.
Expected behavior:
When importing a session whose cwd is a Git worktree of an already-open folder, CodeG should register/reconcile that folder as a worktree child of the root repo, same as open_worktree_folder_core does.
Relevant code:
src-tauri/src/commands/folders.rs
open_worktree_folder_core(...)
src-tauri/src/db/service/folder_service.rs
add_folder(...)add_folder_with_parent(...)
src-tauri/src/commands/conversations.rs
import_selected_from_summaries(...) currently calls folder_service::add_folder(...)
When importing Codex sessions whose
cwdis a Git worktree of an already-open repo, CodeG sometimes registers the worktree folder as a top-level workspace folder instead of grouping it under the repo root.Example local state:
C:\_Data\Projects\WowAppsC:\_Data\Projects\worktrees\churn-report-edit-entriesC:\_Data\Projects\worktrees\admin-danger-zone-edit-area-on-vendor-editC:\_Data\Projects\worktrees\pricing-investigationDB evidence:
folder.id = 32, path...\churn-report-edit-entries,parent_id = 1folder.id = 33, path...\admin-danger-zone-edit-area-on-vendor-edit,parent_id = NULLfolder.id = 34, path...\pricing-investigation,parent_id = NULLAll three are valid Git worktrees from
C:\_Data\Projects\WowAppsaccording togit -C C:\_Data\Projects\WowApps worktree list --porcelain.Likely cause:
The normal worktree registration path uses
open_worktree_folder_core, which writes the parent repo id viafolder_service::add_folder_with_parent(...).But the session import path in
src-tauri/src/commands/conversations.rscalls plainfolder_service::add_folder(...)for imported sessioncwdpaths. That creates/reopens a normal folder and leavesparent_id = NULL. It does not resolve whether the importedcwdis a Git worktree belonging to an existing root folder.Expected behavior:
When importing a session whose
cwdis a Git worktree of an already-open folder, CodeG should register/reconcile that folder as a worktree child of the root repo, same asopen_worktree_folder_coredoes.Relevant code:
src-tauri/src/commands/folders.rsopen_worktree_folder_core(...)src-tauri/src/db/service/folder_service.rsadd_folder(...)add_folder_with_parent(...)src-tauri/src/commands/conversations.rsimport_selected_from_summaries(...)currently callsfolder_service::add_folder(...)