Problem
A managed worktree created through open_workspace is persisted with mode: "worktree", managed: true, its worktree root, and an allowed source repository. If the client later loses that workspace ID, reopening the existing worktree by path through open_workspace fails with Path is outside allowed roots whenever the configured worktree root is intentionally outside allowedRoots.
The persisted workspace can still be restored internally by ID, because restore validation separately verifies that its source root is allowed and its worktree root is inside the configured managed-worktree root. There is currently no path-based way to recover that registered workspace.
Reproduction
- Configure a source repository under
allowedRoots and use a separate worktreeRoot outside it.
- Open the source in
worktree mode and note the returned managed-worktree path.
- Start a new client session without the returned workspace ID.
- Call
open_workspace with the existing managed-worktree path in checkout mode.
Actual
The call is rejected as outside allowedRoots.
Expected
An exact path match to a persisted managed worktree should restore the original workspace session, including its original workspace ID, without adding the whole worktree parent to allowedRoots.
Security constraints
The recovery must remain limited to a persisted session that is both mode: "worktree" and managed: true. Normal restored-worktree validation must still require an allowed source root and containment within the configured worktree root. Arbitrary unregistered paths under the managed-worktree parent must remain denied.
Acceptance criteria
- Reopening a persisted managed worktree by its exact path restores the recorded session.
- Home-directory path expansion is supported by the existing path resolver.
- A regular external checkout and an unregistered sibling worktree remain denied.
- The behavior is covered by a regression test using a managed-worktree root outside
allowedRoots.
Problem
A managed worktree created through
open_workspaceis persisted withmode: "worktree",managed: true, its worktree root, and an allowed source repository. If the client later loses that workspace ID, reopening the existing worktree by path throughopen_workspacefails withPath is outside allowed rootswhenever the configured worktree root is intentionally outsideallowedRoots.The persisted workspace can still be restored internally by ID, because restore validation separately verifies that its source root is allowed and its worktree root is inside the configured managed-worktree root. There is currently no path-based way to recover that registered workspace.
Reproduction
allowedRootsand use a separateworktreeRootoutside it.worktreemode and note the returned managed-worktree path.open_workspacewith the existing managed-worktree path in checkout mode.Actual
The call is rejected as outside
allowedRoots.Expected
An exact path match to a persisted managed worktree should restore the original workspace session, including its original workspace ID, without adding the whole worktree parent to
allowedRoots.Security constraints
The recovery must remain limited to a persisted session that is both
mode: "worktree"andmanaged: true. Normal restored-worktree validation must still require an allowed source root and containment within the configured worktree root. Arbitrary unregistered paths under the managed-worktree parent must remain denied.Acceptance criteria
allowedRoots.