Problem (one or two sentences)
When a historical Zoo Code conversation is reopened from a different VS Code workspace or Git worktree, the conversation remains bound to the workspace path where it was created. File mentions, agent tools, commands, prompts, and checkpoints continue using the old path instead of the files in the currently open workspace.
Context (who is affected and when)
This affects users who continue a conversation after moving equivalent work to another checkout, branch layout, remote workspace, or Git worktree. It is especially confusing when the old path still exists because Zoo silently operates there while VS Code shows files from the new workspace; if the old path no longer exists, file and command operations may fail.
Confirmed against Zoo Code v3.80.1 source and current main (v3.82.0 at investigation time).
Reproduction steps
- Open VS Code on workspace/worktree B.
- Start a Zoo Code conversation and allow it to be persisted in extension global storage.
- Close B, then open workspace/worktree A containing the files the user now intends Zoo to operate on.
- In Zoo Code history, show all workspaces and reopen the conversation created in B.
- Use
@ file search or ask the agent to read/search/edit files or run a command.
- Observe that the history item is labeled with B and operations resolve against B rather than A.
Deterministic automated reproduction: #1601. Its expected-failure test configures the open/provider workspace as /mock/workspace, restores a conversation whose task cwd is /old/worktree-b, invokes searchFiles, and confirms current code selects /old/worktree-b instead of the desired open workspace.
Expected result
Zoo should provide an explicit, safe workspace policy for historical conversations. Reasonable options are:
- Follow the currently open/resolved VS Code workspace.
- Keep the original workspace.
- Ask when the persisted conversation workspace differs from the open workspace, with actions such as Use current workspace, Open original workspace, and Cancel.
The chosen root should consistently apply to @ file selection, prompts, file/search/edit tools, commands, ignore/protection rules, and checkpoints.
Actual result
The restored conversation silently keeps its original workspace path. Source-level flow:
ClineProvider.createTaskWithHistoryItem() passes historyItem.workspace as workspacePath.
Task stores that path and exposes it as Task.cwd.
- Webview operations prefer
provider.getCurrentTask()?.cwd over the provider/current-window cwd.
- Agent tools and prompt/environment generation resolve against
Task.cwd.
This makes the persisted origin workspace double as the active execution root, with no UI to inspect or change it.
Persisted storage details
Remote VS Code installations commonly store tasks under:
.vscode-server/data/User/globalStorage/zoocodeorganization.zoo-code/tasks/
Relevant persisted data includes:
tasks/<task-id>/history_item.json: workspace is the authoritative field used to restore the task execution root.
api_conversation_history.json: can embed old cwd/path values in environment details, tool arguments, tool results, and conversation content, but these are not the authoritative root selector.
ui_messages.json: can embed old worktree paths in displayed transcript content, but does not select runtime cwd.
_index.json: may contain workspace/task summaries in older or leftover storage. In v3.80.1 and current extension source, per-task history_item.json files are authoritative and the extension no longer reads/writes a shared index; _index.json may therefore be stale. Older builds that use it require index/history consistency.
Multi-root workspace limitation
A VS Code multi-root workspace is one window containing multiple top-level folders. It can choose the root for a new task based on the active editor or first folder, but it does not move an existing conversation: restoration still prefers the persisted task cwd. As a result, adding both worktrees to one multi-root window does not make @ search or relative agent tools follow the newly focused folder for that conversation.
Manual workaround and risks
An unsupported workaround is to fully close VS Code/the extension host, back up the entire task directory, then change history_item.json.workspace to the desired workspace before reopening the conversation.
Risks and constraints:
- Do not edit while Zoo is running. The active
Task, workspace-scoped controllers, and task-history cache remain bound in memory, and later saves may overwrite disk edits.
- Editing embedded API/UI transcript paths is not required for routing. Blind global replacement can corrupt user text, commands, tool evidence, or diffs; historical old-path content may still influence model reasoning.
- Keep any legacy
_index.json entry consistent only if the installed build actually uses it.
- Per-task checkpoint shadow Git stores
core.worktree for the original path and rejects a different workspace. Changing only history_item.json.workspace can disable or break checkpoint initialization/restoration; old checkpoints should not be assumed valid for the new checkout.
- The new checkout may not be semantically equivalent even if filenames match.
Conversation continuity is the priority; checkpoint reuse can be reset or disabled when switching roots.
Suggested product direction
On historical conversation restore, compare historyItem.workspace with the currently resolved provider workspace. If they differ, expose a compact mismatch prompt and optionally a setting such as Historical conversations: Ask / Follow current workspace / Keep original.
For Use current workspace, instantiate against the current provider cwd, rebuild all workspace-scoped services, persist the selected active root, and create/reset checkpoint state for that root. If history provenance is still useful, store the immutable origin separately from the mutable active workspace.
Screenshots
Not applicable. The mismatch is captured deterministically in #1601.
Video
Not applicable.
What version of Zoo are you running
Reproduced in v3.80.1 source and current main (v3.82.0 during investigation).
Additional context
Problem (one or two sentences)
When a historical Zoo Code conversation is reopened from a different VS Code workspace or Git worktree, the conversation remains bound to the workspace path where it was created. File mentions, agent tools, commands, prompts, and checkpoints continue using the old path instead of the files in the currently open workspace.
Context (who is affected and when)
This affects users who continue a conversation after moving equivalent work to another checkout, branch layout, remote workspace, or Git worktree. It is especially confusing when the old path still exists because Zoo silently operates there while VS Code shows files from the new workspace; if the old path no longer exists, file and command operations may fail.
Confirmed against Zoo Code v3.80.1 source and current
main(v3.82.0 at investigation time).Reproduction steps
@file search or ask the agent to read/search/edit files or run a command.Deterministic automated reproduction: #1601. Its expected-failure test configures the open/provider workspace as
/mock/workspace, restores a conversation whose task cwd is/old/worktree-b, invokessearchFiles, and confirms current code selects/old/worktree-binstead of the desired open workspace.Expected result
Zoo should provide an explicit, safe workspace policy for historical conversations. Reasonable options are:
The chosen root should consistently apply to
@file selection, prompts, file/search/edit tools, commands, ignore/protection rules, and checkpoints.Actual result
The restored conversation silently keeps its original workspace path. Source-level flow:
ClineProvider.createTaskWithHistoryItem()passeshistoryItem.workspaceasworkspacePath.Taskstores that path and exposes it asTask.cwd.provider.getCurrentTask()?.cwdover the provider/current-window cwd.Task.cwd.This makes the persisted origin workspace double as the active execution root, with no UI to inspect or change it.
Persisted storage details
Remote VS Code installations commonly store tasks under:
Relevant persisted data includes:
tasks/<task-id>/history_item.json:workspaceis the authoritative field used to restore the task execution root.api_conversation_history.json: can embed old cwd/path values in environment details, tool arguments, tool results, and conversation content, but these are not the authoritative root selector.ui_messages.json: can embed old worktree paths in displayed transcript content, but does not select runtime cwd._index.json: may contain workspace/task summaries in older or leftover storage. In v3.80.1 and current extension source, per-taskhistory_item.jsonfiles are authoritative and the extension no longer reads/writes a shared index;_index.jsonmay therefore be stale. Older builds that use it require index/history consistency.Multi-root workspace limitation
A VS Code multi-root workspace is one window containing multiple top-level folders. It can choose the root for a new task based on the active editor or first folder, but it does not move an existing conversation: restoration still prefers the persisted task cwd. As a result, adding both worktrees to one multi-root window does not make
@search or relative agent tools follow the newly focused folder for that conversation.Manual workaround and risks
An unsupported workaround is to fully close VS Code/the extension host, back up the entire task directory, then change
history_item.json.workspaceto the desired workspace before reopening the conversation.Risks and constraints:
Task, workspace-scoped controllers, and task-history cache remain bound in memory, and later saves may overwrite disk edits._index.jsonentry consistent only if the installed build actually uses it.core.worktreefor the original path and rejects a different workspace. Changing onlyhistory_item.json.workspacecan disable or break checkpoint initialization/restoration; old checkpoints should not be assumed valid for the new checkout.Conversation continuity is the priority; checkpoint reuse can be reset or disabled when switching roots.
Suggested product direction
On historical conversation restore, compare
historyItem.workspacewith the currently resolved provider workspace. If they differ, expose a compact mismatch prompt and optionally a setting such as Historical conversations: Ask / Follow current workspace / Keep original.For Use current workspace, instantiate against the current provider cwd, rebuild all workspace-scoped services, persist the selected active root, and create/reset checkpoint state for that root. If history provenance is still useful, store the immutable origin separately from the mutable active workspace.
Screenshots
Not applicable. The mismatch is captured deterministically in #1601.
Video
Not applicable.
What version of Zoo are you running
Reproduced in v3.80.1 source and current
main(v3.82.0 during investigation).Additional context