Background
PR #99 makes workspace deletion a hard-delete for workspace-scoped database data: channels, messages, tasks, agents, teams, memberships, trace events, attachment links, orphan attachment rows, and orphan attachment files.
There is one remaining restriction: deleting a workspace does not remove per-agent or per-team runtime workspace directories from disk.
Current behavior
When a workspace is deleted, Chorus removes scoped database rows and orphan attachment files, but leaves runtime workspace directories such as:
- per-agent directories under the configured agents dir
- per-team directories under the configured teams dir
- agent private team-memory directories
This is documented in docs/workspace.md as a current limitation.
Why this is unsafe to fix directly today
Team filesystem paths are currently keyed by team name, not workspace id. Since team names can repeat across workspaces, deleting filesystem directories during workspace deletion could erase files that belong to another workspace with the same team name.
Example risk:
- Workspace A has team ops
- Workspace B also has team ops
- Deleting Workspace A removes teams/ops
- Workspace B loses its runtime team files
Desired behavior
Workspace deletion should eventually remove all workspace-owned runtime filesystem state, but only after runtime paths become workspace-scoped.
A likely target layout:
- agents/{workspace-id}/{agent-name}/
- teams/{workspace-id}/{team-name}/
- agents/{workspace-id}/{agent-name}/teams/{team-name}/
or an equivalent slug/id based layout with a clear migration story.
Acceptance criteria
- Agent runtime directories are scoped by workspace identity.
- Team runtime directories are scoped by workspace identity.
- Agent private team-memory directories are scoped by workspace identity.
- Deleting a workspace removes only that workspace runtime filesystem state.
- Same-named teams or agents in other workspaces are not affected.
- Existing delete-agent and delete-team flows keep their current behavior inside the active workspace.
- Tests cover same-name teams across two workspaces and verify deleting one workspace does not remove the other workspace files.
Related
Background
PR #99 makes workspace deletion a hard-delete for workspace-scoped database data: channels, messages, tasks, agents, teams, memberships, trace events, attachment links, orphan attachment rows, and orphan attachment files.
There is one remaining restriction: deleting a workspace does not remove per-agent or per-team runtime workspace directories from disk.
Current behavior
When a workspace is deleted, Chorus removes scoped database rows and orphan attachment files, but leaves runtime workspace directories such as:
This is documented in docs/workspace.md as a current limitation.
Why this is unsafe to fix directly today
Team filesystem paths are currently keyed by team name, not workspace id. Since team names can repeat across workspaces, deleting filesystem directories during workspace deletion could erase files that belong to another workspace with the same team name.
Example risk:
Desired behavior
Workspace deletion should eventually remove all workspace-owned runtime filesystem state, but only after runtime paths become workspace-scoped.
A likely target layout:
or an equivalent slug/id based layout with a clear migration story.
Acceptance criteria
Related