Feature summary
When a project is added from a local folder, every new session silently switches the working directory to an isolated git worktree, without notifying or asking the user. Users expect edits to continue in the local folder they explicitly chose, but instead changes are made and committed in the worktree while the original folder is left behind/out of date. When a user explicitly selects a local folder, the app should keep using that folder as the working directory across sessions — or at minimum surface the relocation and ask for consent before moving it.
What problem are you trying to solve?
When I add a project from a local folder, I expect that folder to remain my working directory — that's the whole point of choosing a local folder rather than cloning a remote repo. The problem is that the app does not honor this choice across sessions: the first session works in my local folder, but every subsequent session silently relocates the working directory to an isolated git worktree under ....copilot\repos\copilot-worktrees..., without any notification or consent.
This creates several concrete problems:
Loss of a single source of truth: identical files (e.g. main.py) now exist in multiple physical locations, and it becomes unclear which folder is authoritative.
Unexpected output locations: edits and generated artifacts (reports, build outputs) land in the worktree, not in the folder I selected, so I can't find them where I expect.
The original folder is left stale: my chosen local folder is silently left out of date, requiring manual merge/pull to catch up.
No awareness: the working folder changes per session and this is never surfaced in the UI, so I only discover it by inspecting the filesystem.
For a single-user, local-folder workflow, the worktree isolation provides no benefit and actively breaks the expectation that the folder I explicitly chose is where the work happens. I want my explicit local-folder choice to be respected across sessions.
Proposed solution
When a project is added from a local folder, treat that folder as the persistent working directory for all sessions of that project by default — i.e. run sessions in-place on the user-selected folder instead of creating a separate worktree.
Concretely:
Honor the local-folder choice across sessions. If the user added the project from a local folder, every new session should use that same folder as its working directory, not a generated worktree.
Make the container type explicit and user-controlled. Provide a clear per-project (and global default) setting to choose "in-place (use my local folder)" vs "isolated worktree", and persist that choice across sessions. (Related: #1204, #936, #1111, #714.)
Never relocate silently. If a worktree is going to be used, surface it clearly in the UI before the session starts (show the actual working path and ask for consent), so the working location is never changed without the user's awareness.
Show the working directory in the session UI. Always display the absolute working path for the active session, so it's obvious where edits and generated outputs will land.
For users who rely on parallel agents, the worktree behavior can remain available — but it should be an explicit, visible opt-in for local-folder projects, not a silent default.
Workflow impact
The current behavior significantly disrupts a local-folder workflow:
Confusion over the source of truth. Because the same files are duplicated into a worktree, it's no longer obvious which folder is authoritative. This undermines basic original/source management and erodes trust in where my code actually lives.
Lost or misplaced outputs. Generated artifacts (e.g. report files, build outputs) are written to the worktree instead of my chosen folder. I went looking for them in my local folder and they weren't there — I only found them by inspecting the worktree path manually.
Stale working folder. My selected local folder is silently left out of date, forcing extra manual steps (merge/pull) just to bring it back in sync with work that I thought was happening there in the first place.
Hidden, per-session relocation. The working directory changes from session to session with no UI indication, so I cannot reason about where edits and commits are going without digging through the filesystem.
Wasted time and mistrust. I spent a long time confused about whether the tool had even run, and where my files went, before discovering the worktree mechanism. This is a poor first-run experience and damages confidence in the tool for everyday local development.
For single-user, local-folder development the worktree isolation provides no benefit and only adds friction, surprise, and risk of working on or shipping the wrong copy.
Installation context
App install location: C:\Users<user>\AppData\Local\Programs\GitHub Copilot\github.exe (per-user install) Copilot CLI engine: C:\Users<user>\AppData\Local\github-copilot-sdk\cli\1.0.64-1\copilot.exe Worktree base directory: C:\Users<user>.copilot\repos\copilot-worktrees\ — this is the centralized location where every local session's worktree is created, away from the user-selected local folder. Scope this request affects: Any project added via "Local folder or repository" (local-folder projects), as opposed to projects cloned from a remote. All sessions after the first one for such a project, on a per-user installation on Windows. The request concerns the default checkout strategy (worktree) and its silent, per-session relocation of the working directory; ideally configurable at the project level and as a global default
Additional context
Related issues (similar requests / overlapping concerns):
#1204 — Choose session type (in-place vs. worktree) when creating a session
#936 — create_session always creates a worktree — no option for a local/in-place session
#1111 — Global default for session container type (Branches vs Worktrees)
#714 — Persist "Use worktree" toggle across sessions and add a project-level default
#169 — Decouple sessions from worktrees
#407 / #734 — Configurable / specifiable worktree location
This request differs from the above by focusing specifically on respecting an explicit local-folder selection across sessions and on the silent, unconsented relocation of the working directory (not just adding a toggle).
Concrete example of the confusion it causes:
I selected a local folder, e.g. C:\02_PRG...\MyProject, and worked there in the first session.
In a later session I ran a script and it reported output at:
....copilot\repos\copilot-worktrees\MyProject<branch>\report.md
I looked in my original folder C:\02_PRG...\MyProject and the file was not there, so I assumed the tool had not run at all.
The same main.py existed in two physical locations with identical content, and it was unclear which was authoritative.
Only after manually running git worktree list did I realize the app had created a separate worktree and switched the working directory there — something I never selected or was told about.
Suggested UX: show the active session's absolute working path in the UI, and for local-folder projects default to in-place execution (or require explicit, visible consent before using a worktree)
Feature summary
When a project is added from a local folder, every new session silently switches the working directory to an isolated git worktree, without notifying or asking the user. Users expect edits to continue in the local folder they explicitly chose, but instead changes are made and committed in the worktree while the original folder is left behind/out of date. When a user explicitly selects a local folder, the app should keep using that folder as the working directory across sessions — or at minimum surface the relocation and ask for consent before moving it.
What problem are you trying to solve?
When I add a project from a local folder, I expect that folder to remain my working directory — that's the whole point of choosing a local folder rather than cloning a remote repo. The problem is that the app does not honor this choice across sessions: the first session works in my local folder, but every subsequent session silently relocates the working directory to an isolated git worktree under ....copilot\repos\copilot-worktrees..., without any notification or consent.
This creates several concrete problems:
Loss of a single source of truth: identical files (e.g. main.py) now exist in multiple physical locations, and it becomes unclear which folder is authoritative.
Unexpected output locations: edits and generated artifacts (reports, build outputs) land in the worktree, not in the folder I selected, so I can't find them where I expect.
The original folder is left stale: my chosen local folder is silently left out of date, requiring manual merge/pull to catch up.
No awareness: the working folder changes per session and this is never surfaced in the UI, so I only discover it by inspecting the filesystem.
For a single-user, local-folder workflow, the worktree isolation provides no benefit and actively breaks the expectation that the folder I explicitly chose is where the work happens. I want my explicit local-folder choice to be respected across sessions.
Proposed solution
When a project is added from a local folder, treat that folder as the persistent working directory for all sessions of that project by default — i.e. run sessions in-place on the user-selected folder instead of creating a separate worktree.
Concretely:
Honor the local-folder choice across sessions. If the user added the project from a local folder, every new session should use that same folder as its working directory, not a generated worktree.
Make the container type explicit and user-controlled. Provide a clear per-project (and global default) setting to choose "in-place (use my local folder)" vs "isolated worktree", and persist that choice across sessions. (Related: #1204, #936, #1111, #714.)
Never relocate silently. If a worktree is going to be used, surface it clearly in the UI before the session starts (show the actual working path and ask for consent), so the working location is never changed without the user's awareness.
Show the working directory in the session UI. Always display the absolute working path for the active session, so it's obvious where edits and generated outputs will land.
For users who rely on parallel agents, the worktree behavior can remain available — but it should be an explicit, visible opt-in for local-folder projects, not a silent default.
Workflow impact
The current behavior significantly disrupts a local-folder workflow:
Confusion over the source of truth. Because the same files are duplicated into a worktree, it's no longer obvious which folder is authoritative. This undermines basic original/source management and erodes trust in where my code actually lives.
Lost or misplaced outputs. Generated artifacts (e.g. report files, build outputs) are written to the worktree instead of my chosen folder. I went looking for them in my local folder and they weren't there — I only found them by inspecting the worktree path manually.
Stale working folder. My selected local folder is silently left out of date, forcing extra manual steps (merge/pull) just to bring it back in sync with work that I thought was happening there in the first place.
Hidden, per-session relocation. The working directory changes from session to session with no UI indication, so I cannot reason about where edits and commits are going without digging through the filesystem.
Wasted time and mistrust. I spent a long time confused about whether the tool had even run, and where my files went, before discovering the worktree mechanism. This is a poor first-run experience and damages confidence in the tool for everyday local development.
For single-user, local-folder development the worktree isolation provides no benefit and only adds friction, surprise, and risk of working on or shipping the wrong copy.
Installation context
App install location: C:\Users<user>\AppData\Local\Programs\GitHub Copilot\github.exe (per-user install) Copilot CLI engine: C:\Users<user>\AppData\Local\github-copilot-sdk\cli\1.0.64-1\copilot.exe Worktree base directory: C:\Users<user>.copilot\repos\copilot-worktrees\ — this is the centralized location where every local session's worktree is created, away from the user-selected local folder. Scope this request affects: Any project added via "Local folder or repository" (local-folder projects), as opposed to projects cloned from a remote. All sessions after the first one for such a project, on a per-user installation on Windows. The request concerns the default checkout strategy (worktree) and its silent, per-session relocation of the working directory; ideally configurable at the project level and as a global default
Additional context
Related issues (similar requests / overlapping concerns):
#1204 — Choose session type (in-place vs. worktree) when creating a session
#936 — create_session always creates a worktree — no option for a local/in-place session
#1111 — Global default for session container type (Branches vs Worktrees)
#714 — Persist "Use worktree" toggle across sessions and add a project-level default
#169 — Decouple sessions from worktrees
#407 / #734 — Configurable / specifiable worktree location
This request differs from the above by focusing specifically on respecting an explicit local-folder selection across sessions and on the silent, unconsented relocation of the working directory (not just adding a toggle).
Concrete example of the confusion it causes:
I selected a local folder, e.g. C:\02_PRG...\MyProject, and worked there in the first session.
In a later session I ran a script and it reported output at:
....copilot\repos\copilot-worktrees\MyProject<branch>\report.md
I looked in my original folder C:\02_PRG...\MyProject and the file was not there, so I assumed the tool had not run at all.
The same main.py existed in two physical locations with identical content, and it was unclear which was authoritative.
Only after manually running git worktree list did I realize the app had created a separate worktree and switched the working directory there — something I never selected or was told about.
Suggested UX: show the active session's absolute working path in the UI, and for local-folder projects default to in-place execution (or require explicit, visible consent before using a worktree)