All-Hands-AI
[Feature]: Support for non-Debian based custom sandboxes
What problem or use case are you trying to solve?
Some use cases would be better served by supporting non-Debian based containers as custom sandboxes: https://github.com/All-Hands-AI/OpenHands/issues/9098
Describe the UX or technical implementation you have in mind
Implement support for APK- and DNF-based distros in addition to the current APT support.
Additional context
Here's a rough breakdown of the coverage you'd get:
- APT (already supported): Debian, Ubuntu, and other Debian-based distributions
- DNF: Red Hat Enterprise Linux, CentOS, Fedora, and other Red Hat-based distributions
- APK: Alpine Linux
If you find this feature request or enhancement useful, make sure to add a 👍 to the issue
@matty-fortune, on the page:
- https://www.all-hands.dev/features
what does:
Bring your own containerized development environment (coming soon!)
mean? Is it:
a) An out-of-date comment that has already been implemented with custom sandbox containers as documented at https://docs.all-hands.dev/usage/how-to/custom-sandbox-guide
or
b) This issue "Support for non-Debian based custom sandboxes"
?
@bartlettroscoe that first comment is for the OpenHands Cloud that will be available in the near future.
@mamoodi and @matty-fortune, it just occurred to me that another option would be to extend OpenHands to add a new mode to assume that the Sandbox container was already set up with all of the packages that are needed so that apt-get never needed to be called? This could be an option called something like --no-install-packages true:
docker run ... \
python -m openhands.cli.main --override-cli-mode true --no-install-packages true
(Or could set through the configuration file?)
Then you could tell the agent what commands it run to perform build and test tasks (just like I do with VSCode + Copilot Agent Mode).
Then as long as Openhands only ran standard Linux commands (that work on any Linux distribution) and the commands that I tell it to use in the prompt, this would work with any custom container with any base Linux OS distribution.
For example, I can use any container I want with VSCode + GitHub Copilot Agent Mode and it never tries to install anything with the package manager. Why can't we have a mode in OpenHands that does the same thing? Just leave it to an advanced user to set up their custom sandbox container with all of the tools needed to perform all of the tasks (including building, running tests, etc.) and then tell OpenHands/AI Agent/LLM what commands to call for different tasks.
We could prototype this on our end to see how viable this would be, but we would like to get your feedback first to see if this would be a useful feature to merge back to the 'main' branch.
What do you think?
NOTE: You may have to create a wrapper Dockerfile and create a wrapper image that installs extra packages needed/expected from OpenHands/AI Agent/LLM from what are already in the Redhat-based Trilinos container, but that is a super common use case and one that is consistent with the design and philosophy of containers.
@bartlettroscoe
Yes that'd be a fine way to go about it. Yes the expected OpenHands setup would otherwise need to be put in place in the container. I agree that's the more container-centric design.
I'm not able to speak on the possibility of anything getting merged, but of course the most straightforward option would be simply doing something like your --no-install-packages flag then making a standalone version of the OpenHands container setup things that's as generic as possible. This would be a very minimal change to the OpenHands codebase, while the standalone container setup would need to be maintained but could be handled by an outside party. I don't have time to do any heavy lifting on it, but if you decide to pursue this route I'll help where I can.
@matty-fortune, I'm not sure what you mean by a "stand-alone container". Do you just mean the sandbox container has been completely set up beforehand with any packages that would be needed by the agent before the sandbox container gets fired up?
Do you have any estimate how long it would take someone to implement a --no-install-packages option? (Given that this is an unfamiliar code base for my team, I'm not sure how to estimate this up front.)
I'm just wondering how people are using OpenHands with real C++ projects that have non-trivial dependencies and very specific version requirements for compilers and related tools? You're not going to get this from the basic binary package manager in Debian.
Perhaps our use case is just too far off from the vision for OpenHands? Is the primary use case for OpenHands simpler software projects that don't have complex dependencies? If that is the case, are there other agentic frameworks that we might look at that might be a better fit for bringing your own container with compilers and other tools needed to manipulate your C++ project?
With that said, perhaps the best route would be to go back to the idea of providing specialized compilers and other tools through MCP as discussed #9098. Learning about MCP and learning how to incorporate into our environment and workflows could have real advantages in the future in terms of swapping between different AI agents. (I'm just worried about forcing the agent to run our tools as prescribed in the prompts instead of having the agent trying to revert back to running raw terminal commands. I struggle with that quite a bit with VSCode + GitHub Co-pilot agent mode. But in that case, does not really matter because the agent itself is running inside of my container so it could just directly run the compiler, the build tools, etc. It's running in a container, but in a way very different from the way that OpenHands does. One can argue from a security perspective that having the agent running completely inside of a container is more secure since we can lock down what can be accessed from the container, instead of having the agent fire off commands in a sandbox container. An untrusted rogue agent could do real damage since it's actually running on your host machine instead of inside of the container. Yes, the openhands agent is running in a container on your hose system and perhaps so perhaps we could restrict what it has access to through the docker run command or even create our own wrapper image to further lock things down.)
@matty-fortune, I'm not sure what you mean by a "stand-alone container". Do you just mean the sandbox container has been completely set up beforehand with any packages that would be needed by the agent before the sandbox container gets fired up?
Yes, standalone as in not managed by the OpenHands software, so it handles its own set up through some other means.
Do you have any estimate how long it would take someone to implement a
--no-install-packagesoption? (Given that this is an unfamiliar code base for my team, I'm not sure how to estimate this up front.)
My guess would be not all too long, but I can't provide a clear estimate. You'd need to add support for the flag, which would need to disable the areas that are doing that runtime container management. I'd look at these two spots first: https://github.com/All-Hands-AI/OpenHands/tree/main/openhands/runtime and https://github.com/All-Hands-AI/OpenHands/tree/main/containers/runtime
I'm just wondering how people are using OpenHands with real C++ projects that have non-trivial dependencies and very specific version requirements for compilers and related tools? You're not going to get this from the basic binary package manager in Debian.
I don't personally know that people are using it for things like that. Agents are quite a new thing and certainly still at a point of early-adopter phase. I'd assume a lot of people are mostly using them for so-called vibe coding tasks.
Perhaps our use case is just too far off from the vision for OpenHands? Is the primary use case for OpenHands simpler software projects that don't have complex dependencies? If that is the case, are there other agentic frameworks that we might look at that might be a better fit for bringing your own container with compilers and other tools needed to manipulate your C++ project?
I don't think it's off from the vision, but this is all R&D level stuff at this point. I can't say that I know of any viable alternatives, but hopefully the space grows. I think you can use OpenHands for your use case, but I don't think things are anywhere near the point of being an off-the-shelf solution yet, and certainly not from anything open source.
With that said, perhaps the best route would be to go back to the idea of providing specialized compilers and other tools through MCP as discussed #9098. Learning about MCP and learning how to incorporate into our environment and workflows could have real advantages in the future in terms of swapping between different AI agents. (I'm just worried about forcing the agent to run our tools as prescribed in the prompts instead of having the agent trying to revert back to running raw terminal commands. I struggle with that quite a bit with VSCode + GitHub Co-pilot agent mode. But in that case, does not really matter because the agent itself is running inside of my container so it could just directly run the compiler, the build tools, etc. It's running in a container, but in a way very different from the way that OpenHands does. One can argue from a security perspective that having the agent running completely inside of a container is more secure since we can lock down what can be accessed from the container, instead of having the agent fire off commands in a sandbox container. An untrusted rogue agent could do real damage since it's actually running on your host machine instead of inside of the container. Yes, the openhands agent is running in a container on your hose system and perhaps so perhaps we could restrict what it has access to through the docker run command or even create our own wrapper image to further lock things down.)
I think both routes are perfectly viable and each have pros and cons. I think both are similar enough in terms of required work, but yes they do take very different directions. I think the container route is something OpenHands should do, honestly, but the cloud-focused business model could be an incentive not to do so. I think the MCP route is a fine option, but yes it does add a layer to things and there wouldn't necessarily be anything forcing the agent to use the proper MCP tools. Things get a bit blurry since MCP is primarily thought of as being for adding something like get_weather whereas something like run_bash starts to look very similar to what OpenHands already does, so there's definitely room for agent confusion there. All of these problems are solvable, but it's still very early in this space. I don't know what resource constraints you're operating under, but I feel like a dedicated "hacker" could bang either of these routes out, at least for a proof of concept, within one or a few weekends of serious work.
I'm interested in learning about as much of the AI space as possible while working on my own side projects as a means to do that so I'm more than happy to help where I can in the spirit of learning, but one way or another someone has to dig in and do the "heavy lifting", although to be fair neither of these are close to the "heaviest lifting" around and who knows, you could open source what you do and perhaps attract fellow scientists to join in (on that note, I have been curious what sort of work this is intended to help out with if you ever want to share a few details).
I'm interested in learning about as much of the AI space as possible while working on my own side projects as a means to do that so I'm more than happy to help where I can in the spirit of learning, but one way or another someone has to dig in and do the "heavy lifting", although to be fair neither of these are close to the "heaviest lifting" around and who knows, you could open source what you do and perhaps attract fellow scientists to join in
Understood. That is the plan. I am going to dive into creating a local MCP server first to provide builds of object code, executables and running of tests. I will likely start with FastMCP:
- https://github.com/jlowin/fastmcp
which looks to be nearly as popular as the official MCP Python-sdk:
- https://github.com/modelcontextprotocol/python-sdk
on that note, I have been curious what sort of work this is intended to help out with if you ever want to share a few details
Initially, we are trying to use AI agents to refactor and generate tests for large C++ code bases in our institution (Sandia National Labs). We are starting out by focusing on the open-source C++ project Trilinos:
- https://github.com/trilinos/Trilinos
And initially, we are using the RedHat-based clang-19 container:
- https://github.com/trilinos/containers/tree/main/dockerfiles/clang-openmpi
which has a lot custom TPLs and tools needed for that project. (And our bigger internal C++ codes have even more challenging C++ dependencies and tools so we will need containers there as well.) That container uses Spack to build many tricky TPLs needed by Trilinos.
Here was my failed attempt to switch that container from RedHad-based to Debian-based:
- https://github.com/trilinos/containers/pull/19
(Changing the base image of an existing container is not the right way to go, I was just hoping it would work without too much effort, but it did not.)
@bartlettroscoe that sounds like a good choice, please keep us updated in https://github.com/All-Hands-AI/OpenHands/issues/9098. This is a great use case to explore more complex usages of OpenHands. Anyone working or looking to work with significant dependancies should pay attention and chime in.
As far as this issue, I think the OpenHands team should strongly consider the concept of a --no-install-packages flag. Not to single you out, but @mamoodi since you've participated here, what do you think of that idea? It seems like a reasonable and straightforward way to increase container compatibility for the custom sandbox feature.
I think the OpenHands team should strongly consider the concept of a
--no-install-packagesflag.
That would be really nice. And then OpenHands could assert that a given Sandbox container contained all of the needed tools and commands when it first started up and report what was missing (and give some suggestions on what package need to be installed in order to use OpenHands).
Well what's required to be added to the runtime container is what allows OpenHands to communicate with that container and control it, so that would have to be something separate that could be installed into the container with OpenHands simply assuming that it's in place.
Well what's required to be added to the runtime container is what allows OpenHands to communicate with that container and control it, so that would have to be something separate that could be installed into the container with OpenHands simply assuming that it's in place.
Installing these things up-front in the sandbox container image will just make the sandbox container load that much faster.
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open for 40 days with no activity. Remove the stale label or leave a comment, otherwise it will be closed in 10 days.
FYI: As described in:
- https://github.com/All-Hands-AI/OpenHands/issues/9098#issuecomment-3237042097
we are building a derived container installing OpenHands on top of our base Redhat container and that is working. We just wish there was a better install model for OpenHands that did not require any network communication when you ran the openhands CLI when you were in the container (because we need to lock down the container).
This issue is stale because it has been open for 40 days with no activity. Remove the stale label or leave a comment, otherwise it will be closed in 10 days.