[Bug]: LocalBox has been removed from 0.9.0

[yaroslavkasatikov]

Is there an existing issue for the same bug?

• I have checked the troubleshooting document at https://docs.all-hands.dev/modules/usage/troubleshooting
• I have checked the existing issues.

Describe the bug

Hey team,

We built our setup based on local sandbox in Openshift with restricted permission. We did it after this discusion #2675

But we found there is no local sandbox in v. 0.9.0+ and it brakes our setup :(

Is there a replacement for it or would it be possible to revert this changes?

Many thanks!

Current OpenHands version

0.9.0+

Installation and Configuration

We 've written own Dockerfile based on yours:

FROM ghcr.io/opendevin/opendevin:0.7
RUN chmod 777 -R /app
ENTRYPOINT []
USER root

# install basic packages
RUN apt-get update && apt-get install -y \
    curl \
    wget \
    git \
    vim \
    nano \
    unzip \
    zip \
    python3 \
    python3-pip \
    python3-venv \
    python3-dev \
    build-essential \
    openssh-server \
    sudo \
    gcc \
    jq \
    g++ \
    make \
    iproute2 \
    && rm -rf /var/lib/apt/lists/*

RUN mkdir -p -m0755 /var/run/sshd

# symlink python3 to python
RUN ln -s /usr/bin/python3 /usr/bin/python

# ==== OpenDevin Runtime Client ====
RUN mkdir -p /opendevin && mkdir -p /opendevin/logs && chmod 777 /opendevin/logs
RUN wget "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh"
RUN bash Miniforge3-$(uname)-$(uname -m).sh -b -p /opendevin/miniforge3
RUN chmod -R g+w /opendevin/miniforge3
RUN bash -c ". /opendevin/miniforge3/etc/profile.d/conda.sh && conda config --set changeps1 False && conda config --append channels conda-forge"
RUN echo "" > /opendevin/bash.bashrc

# - agentskills dependencies
RUN /opendevin/miniforge3/bin/pip install --upgrade pip
RUN /opendevin/miniforge3/bin/pip install jupyterlab notebook jupyter_kernel_gateway flake8
RUN /opendevin/miniforge3/bin/pip install python-docx PyPDF2 python-pptx pylatexenc openai
RUN chmod 777 -R /opendevin
RUN mkdir -p /opt/workspace_base && chmod -R 777 /opt/workspace_base
RUN sed "s/config.sandbox_type/\'local\'/g" -i /app/opendevin/runtime/runtime.py && sed '24,27{/.*/d}' -i /app/opendevin/runtime/plugins/mixin.py && mkdir /opendevin/plugins/ && cp -av /app/opendevin/runtime/plugins/jupyter /opendevin/plugins/ && cp -av /app/opendevin/runtime/plugins/agent_skills /opendevin/plugins/
RUN export PATH=/opendevin/miniforge3/bin:/app/.venv/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
RUN echo $PATH
RUN cd /app && playwright install
CMD ["uvicorn", "opendevin.server.listen:app", "--host", "0.0.0.0", "--port", "3000"]

We combined opendevin and sandbox into the same container, changed paths and permission.

This image works without root/docker etc so we were able to start it under restrictedv2 Openshift SCC

### Model and Agent

_No response_

### Operating System

_No response_

### Reproduction Steps

_No response_

### Logs, Errors, Screenshots, and Additional Context

_No response_

[mamoodi]

Tagging @enyst since he was involved in he initial discussion to see if he is able to help.

[enyst]

Local box has been removed a while ago when we have completely rewrote our images, there is no more "SSH box" either, and we have switched to a runtime to which we connect via a REST API. I'm not sure how that can play with your restrictions. 🤔 @xingyaoww what do you think?

[xingyaoww]

Yeah.. I think it will be pretty tricky to do all these, though technically not impossible.

To execute things locally, the hard requirement is to at least have an "openhands" poetry environment setup (i.e., everything in poetry.lock) plus a few things like playwright. Then start a process locally like this so a Runtime API server is accessible by the backend.

The challenge here is it can be very challenging to maintain a consistent playwright across different local setups (e.g., MacOS probably need a different way to install the chromium required by playwright than WSL, etc.) - would love any idea/contribution here!

[aelbarkani]

Well if the sandbox is remote it is ok too, for example if we start it manually somehow and pass some args like the API URL or something like that. Our restriction basically is we cannot run things as root for security reasons, so the backend shouldn't build or run a container.
Is this option easier to implement ?