Skip to content

Allow a persisted default for new session workspace type (branch vs worktree) #4396

Description

@AshHoldsworth

Describe the feature or problem you'd like to solve

There is no way to set a default workspace type for new sessions. Every new session defaults to creating an isolated worktree on a new branch, and users who prefer to work in their existing checkout on their own branch have to remember to change it in the new-session dialog every single time. Forget once and the agent's work silently lands somewhere you weren't looking.

Proposed solution

Add a persisted default for workspace_type, settable at the user level (and ideally overridable per project), honoured when creating a new session. The per-session picker stays exactly as it is — this only changes what it's pre-set to.

The data model already supports this. workspaces.workspace_type is CHECK (workspace_type IN ('worktree', 'branch', 'folder', 'cloud')), so branch workspaces are a fully supported, first-class mode — there's just no way to make one the default. From my own install:

Session workspace_type branch
Reviewing branch changes worktree ashholdsworth-urban-happiness
Review Code Changes branch CC-3119-decision-mechanism-rules
Review Code Changes branch CC-2708

I went looking for somewhere to set this and there is nowhere:

  • ~/.copilot/settings.json — model selection only
  • ~/.copilot/config.json — trusted folders / login state, and marked as automatically managed
  • settings table in ~/.copilot/data.db — no related column
  • app_state table — no related key
  • projects table — has branch_prefix, sparse_checkout, sandbox_enabled, but no workspace type default

Suggested shape, matching the existing config style:

// ~/.copilot/settings.json
{
  "model": "claude-opus-5",
  "defaultWorkspaceType": "branch"  // "worktree" | "branch" | "folder"
}

Plus an optional per-project override, since the right answer genuinely differs by repo — parallel agent work wants worktrees, a repo with heavy local setup or a slow build wants the existing checkout.

Example prompts or workflows

  1. Reviewing a colleague's in-flight branch. I check out CC-3120, open a session, and ask the agent to review it. Today the session silently branches off into a worktree; any fix the agent then makes is invisible from my normal checkout until it's manually moved across.
  2. Iterative work with a running dev server. My server, node_modules and local config live in the main checkout. A worktree session can't see any of it, so I want branch as the default and worktrees only when I opt in.
  3. Large monorepo. A fresh worktree means a full re-install and rebuild per session. Defaulting to branch reuses the warm state.
  4. Small fix on the branch I'm already on. I just want the agent to edit in place and let me commit — no new branch, no second directory.
  5. Deliberate parallel agents. Here I do want worktrees, so I flip the picker for those sessions. The point is that the common case shouldn't be the one requiring the extra step.

Additional context

Environment: GitHub Copilot desktop app 1.1.5, macOS 26.6, Copilot CLI 1.0.79-5.

Related but distinct issues:

Neither asks for a persisted default, so I've filed this separately, but happy for it to be folded into either if triage sees it as one piece of work.

Two things that make the current behaviour harder to live with:

  1. The app reports that "workspace checkout can only be updated before the first session starts", so a session that started as a worktree can't be converted afterwards — you have to discard it and start again.
  2. Editing data.db by hand isn't a viable workaround: the worktree is already created on disk and registered with git, so changing the row would desync the two.

Why this matters beyond convenience: the mode is invisible mid-conversation. The agent works in the worktree exactly as instructed, so nothing looks wrong until you go to your own checkout and find it untouched. A persisted default would remove that whole class of surprise for people who never want worktrees in the first place.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions