I'm really struggling to set this up, running the docker image, with

-e SANDBOX_VOLUMES=/home/me/git:/workspace:rw

the launched sandboxes try accessing

/workspace/conversations

and other nonexistent directories, and crash out on launch, leaving the main docker just with timeouts, not propagating the error messages. Am I supposed to have prepared my workspace directory with some things first? Aren't conversations and the like supposed to be stored in

~/.openhands/

and not in my project workspace? I have existing projects from private repositories that I'm trying to point this at, for some refactoring work. Thanks

Hmmm are you following the how to mount local dirs doc? I think you still have to set some workspace related parameters. Any chance you want to try the new https://github.com/OpenHands/agent-canvas? If you already aren't deep in usage, I’d suggest trying it. It’s a simpler setup

Yeah, I had a bunch of different vars before which didn't work, but the latest is apparently reduced down to just SANDBOX_VOLUMES according to https://docs.openhands.dev/openhands/usage/sandboxes/docker#mounting-your-code-into-the-sandbox and various github issue threads. The mount itself does work, the per-conversation sandbox container is just expecting infrastructure things there for some reason (conversations, bash_events, etc), instead of just my project files. Not sure what agent-canvas does differently, I'm not necessarily trying to develop new agents, but rather trying to find a good orchestration system for running larger coding/refactoring jobs managed by the AI, using my locally hosted LLMs.

The information may be out of date or there might be a bug. Feel free to open a bug. Agent-canvas is similar but it just connects straight to the agent server. No need to switch now that you got it working but it will get the most attention and work once it goes stable.

Well, the coding agent decided to sudo chown my entire directory, and switch everything to user/group 10001. For some reason, it can execute sudo from inside the container and change ownership of my files through the mount. Mounting directories into the container in and of itself seems extraordinarily dangerous here regarding user identities not lining up, and giving unchecked sudo to an LLM.