I have few questions regarding the new standalone sbx product.
I used to use docker sandbox command coming from Docker Desktop and it has .sandbox folder where there is proxy-config.json which is used as a default for new sandboxes and existing once not having their own config. Is there the same type of default config for sbx? Are there json config files for the specific sandboxes, which could be changed the same way? Where are these configs located?
Will the built-in docker sandbox command continue to work inside Docker Desktop in new versions or are we forced to update to the new sbx? If Docker Desktop will continue working, will it share the same core or use a different version of the sandbox? Looks like now they have different storage structure.
Is it possible to migrate existing sandboxes to the sbx somehow?
Iām not sure about 1. I thought I saw the proxy json somewhere, but I could possibly remember the old version. When I started the daemon it asked me which type of isolation I wanted to use, so at least there is an initial config which can be reset by running sbx policy reset, but the sbx policy commands controlls network policies in general, not for a specific Sandbox.
Since Iām using sbx, I used similar sandboxes without the need for customized network policies, so I didnāt even think about that, but I would see the benefit of allowing one sandbox to access a service that others should not be able to. I donāt know how that would be possible now or if it is planned to be implemented.
Regarding 2. The Sandbox in Docker Desktop is an olde rversion. I assume at some point that could be upgraded to the new version that can be used with sbx, but it likely depends on the feedbacks. If the problem is that some features ae not available in the new version, based on feedbacks, that could be re-implemented, but Iām not sure if the sandbox being a cli plugin itself is important. An upgrade recently introduced sbx tmeplate load command that allowed importing local images to the sandbox. That was the one I missed in the new version. Out of curiosity, can you share what you think why docker sandbox would be important to be kept?
To the 3rd question: I would try exporting the sandbox in one environment and using the previously menitoned sbx template load to import the image. but that would only import the template, not policies.
Regarding 1. We currently have a setup script which does a lot of things and one of them is forcing the correct and common proxy settings for all users. What I would like to avoid here is to delegate the decision on the applied policy to the end user, we would like to use the common settings.
And yes, it would be nice to be able to use different proxy settings for different sandboxes for some power users.
Regarding 2. Right now if we use sandbox with Claude Code it means that each sandbox holds its own Claude Code conversation history. It is not very convenient and it would be better to share it in general, but since not each sandbox has its own user directory where Claude stores the files, changing sandbox means loosing the whole history inside the old sandbox.
Regarding 3. Will it also import user directory contents?
Wasnāt it always the case? What am I missing here?
As far as I know, saving a sandbox is similar to committing a container. It saves the current state of the sandbox, including installed apps and configs except files in mounted directories. At the end, you will have an image that you could save to a tar file and load it to a new sandbox daemon.as template.
I havenāt tried, but I donāt think that conversation history would be kept. Even after restarting a sandbox I donāt remember keeping conversation history with the agent and it wouldnāt be expected when someone saves a sandbox as a template for another.
When I restart the sandbox it starts from the same state where I left it. So normally the conversation history is in place. (It is separate for each sandbox). If I have to migrate all my sandboxes to the new sbx engine, I will recreate them from scratch. I will loose all history and also Claude Code authentication. Although it is not a big deal on one machine, but on the organization scale it may create some friction.
I had time to try what I just assumed before. So when I use docker sandbox save mysandbox newtag --output exported-mysandbox.tar, it exports the sandbox to a tar file and I can import it as ānewtagā and import in sbx with sbx template load -i exported-mysandbox.tar.
For some reason, I got an error which I didnāt fully understand, but it referred to a path on my host trying to change the owner of a claude.md file. IāM not sure what it wanted to do on my host when I wanted to create the sandbox in sbx using the same folder as in docker sandbox, but I could create it in a subfolder (could be a bug).
Then I had to find out that when I save a sandbox, all files are kept under /home/agent/.claude/, even the chat history in history.jsonl which I didnāt even know was there (Iām a relatively new claude cli user). Claude still didnāt know about those messages. /resume did not recognize it and in a new shell, claude --dangerously-skip-permissions --resume SESSIONID did not recognize the session id which was in the history file.
So Iām not sure what I did wrong, but it looked like the files were kept in the imported sandbox as well. I did not expect it, so good to know.