[Proposal] Exclusive Workspaces for Snapshot Isolation Across Conversations

[kripper]

Summary

The /workspace directory is currently mounted and shared across all conversations, which is convenient for collaborative work but introduces a critical issue:

When restoring a snapshot (refer to issue #6163), the entire workspace is reverted. This inadvertently overwrites ongoing changes in other conversations, which can lead to data loss or workflow disruption.

To address this, we propose creating a workspace that is exclusive to each conversation. This exclusive workspace will ensure that snapshots and restores are isolated per conversation without impacting shared resources.

---

Technical Design

The proposed solution revolves around segregating workspaces into isolated and shared environments:

1. Per-Conversation Workspaces

   • Each new conversation will begin with an exclusive, empty workspace mounted as /workspace.
   • This workspace will be tied to the conversation and will be included in snapshots/restores.

2. Shared Workspaces

   • A separate shared mount point (e.g., /archive) will be introduced for files that are not included in snapshots.
   • Users will have the ability to manage and optionally grant write access to this shared folder for inter-conversation collaboration.

---

Implementation Proposal

We will define two distinct mounts inside the sandbox environment:

1. /workspace:

   • Exclusive to the conversation sandbox.
   • Fully included in snapshots and restores.

2. /archive:

   • Shared among all conversations.
   • Managed independently by the user and excluded from snapshots.

Host Directory Structure

On the host machine, the file structure (currently within the OH repository) would look like this:

workspaces/
	75bc4c6729c1119ab33856f9d1fd51f26be4ce1fc0b97426cca3063c2228db34/
		(workspace files for session 75bc4...., mounted as `/workspace` inside the sandbox)
archive/
	(files shared with/by the user, equivalent to the current 'workspace' folder)

• Alternative: The /workspace directory could also simply not be mounted at all and just use the container storage. This way, the workspace can be snapshoted/restored together with the entire container storage, but it will get lost when the container is destroyed.

• Access Control: Users can choose to isolate conversation sandboxes completely by restricting write permissions to /archive.

---

Alternatives Considered

1. Instruct OH to work outside /workspace
   • This approach would require users to bypass /workspace, which is counterintuitive and contradicts the purpose of having a dedicated workspace.

By implementing this design, we maintain the intuitive usage of /workspace while ensuring snapshots remain conversation-specific, thus preventing unintended overwrites in shared environments.

[scosenza]

Note that the underlying single /workspace issue also prevents running multiple "local runtime" agents on the same machine e.g. #5284 (comment)

Thanks for working on this!

[kripper]

I guess for the LocalRuntime case, you could simply tell the agent to work inside a given directory, since there will be no isolation anyway (and use the above proposed host directory structure).
And for the Docker case, another option (added to the description) is simply not mount at all and have the /workspace directory only reisde on the container storage.