I am having the same issue. 500 error, timeout waiting for sandbox. I am using "New Conversation" and "Start from Scratch". I confirmed that LLM connectivity is working with docker exec -it openhands-app curl -s http://host.docker.internal:1234/v1/models { "data": [ { "id": "qwen/qwen3.6-35b-a3b", "object": "model", "owned_by": "organization_owner" }, { "id": "text-embedding-nomic-embed-text-v1.5", "object": "model", "owned_by": "organization_owner" } ], "object": "list" } Please find the openhands docker log snippet attached.

Hey @purple-book-27215, Your

curl

only proves openhands-app can reach LM Studio, but the timeout you're hitting happens before any LLM call. The stack trace ends in

wait_for_sandbox_running()

, which means openhands-app created the agent-server sandbox container but its internal

GET /alive

probe never succeeded within 120s. So LM Studio is a red herring here. A couple of things to check, in order: 1. While the "Start from Scratch" is hanging, run in another shell:

docker ps -a --filter "name=oh-agent-server-" --format '{{.Names}}\t{{.Status}}\t{{.Image}}'

• No container at all → openhands-app couldn't even start it. Check

docker logs openhands-app

for a Docker SDK error. • Container

Exited

→ it crashed.

docker logs <name>

will show why. • Container

Up

but timing out →

/alive

isn't responding in time. From inside openhands-app:

docker exec -it openhands-app curl -v <http://host.docker.internal>:<host-port>/health

where

<host-port>

is what

docker ps

shows mapped to container port 8000. 2. Make sure you're using the v1 env-var names for the image. The legacy

SANDBOX_RUNTIME_CONTAINER_IMAGE

is no longer read in current OpenHands, the image now comes from these two, which must be set _together_:

-e AGENT_SERVER_IMAGE_REPOSITORY=<http://ghcr.io/openhands/agent-server|ghcr.io/openhands/agent-server>
-e AGENT_SERVER_IMAGE_TAG=1.26.0-python

If you set only one (or neither), it falls back to the built-in default, which on current main is exactly ghcr.io/openhands/agent-server:1.26.0-python. So if you had the legacy var set, OpenHands was pulling the default, not the image you thought. Pre-pull it so the 120s budget isn't eaten by the pull:

docker pull <http://ghcr.io/openhands/agent-server:1.26.0-python|ghcr.io/openhands/agent-server:1.26.0-python>

(Use the tag that matches your openhands version.) 3. If the host is just slow, bump the grace period (default 15s):

-e SANDBOX_STARTUP_GRACE_SECONDS=60

Note this only helps if the container is coming up near the limit, the 120s wait_for_sandbox_running ceiling itself isn't env-configurable, so if a cold image pull is what's blowing past 120s, the pre-pull in step 2 is the real fix. If you can paste: • output of the

docker ps -a

command above while it's hanging, and •

docker logs

of the

oh-agent-server-…

container we can tell in one look whether it's image, crash, or networking.

@modern-fireman-99755 Thank you for your thoughful reply. The agent server appears to be stopping within about 10 seconds of starting. ---------- I started openhands, refreshed web page. New conversation. I ran the following 3 commands within 40 seconds total $ docker ps -a --filter "name=oh-agent-server-" --format '{{.Names}}\t{{.Status}}\t{{.Image}}' oh-agent-server-6dTqKHaSH2QoI9aVPltBgz Up 4 seconds ghcr.io/openhands/agent-server:1.23.1-python $ docker exec -it openhands-app curl -v http://host.docker.internal:8000/health * Host host.docker.internal:8000 was resolved. * IPv6: (none) * IPv4: 172.17.0.1 * Trying 172.17.0.1:8000... * connect to 172.17.0.1 port 8000 from 172.17.0.2 port 48386 failed: Connection refused * Failed to connect to host.docker.internal port 8000 after 0 ms: Could not connect to server * closing connection #0 curl: (7) Failed to connect to host.docker.internal port 8000 after 0 ms: Could not connect to server $ docker ps -a --filter "name=oh-agent-server-" --format '{{.Names}}\t{{.Status}}\t{{.Image}}' oh-agent-server-6dTqKHaSH2QoI9aVPltBgz Exited (0) 7 seconds ago ghcr.io/openhands/agent-server:1.23.1-python ---------- Trying again by adding the options that you suggested: openhands serve --mount-cwd causes these docker options docker run -it --rm --pull=always \ -e LOG_ALL_EVENTS=true \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /home/user1/.openhands:/.openhands \ -e SANDBOX_VOLUMES=/home/user1/dev/ws46_ai_agents/workspacerw \ -e SANDBOX_USER_ID=1000 \ -p 3000:3000 \ --add-host host.docker.internal:host-gateway \ --name openhands-app \ docker.openhands.dev/openhands/openhands:latest pull the agent server image docker pull ghcr.io/openhands/agent-server:1.26.0-python I am adding these options per the slack message response. -e AGENT_SERVER_IMAGE_REPOSITORY=ghcr.io/openhands/agent-server -e AGENT_SERVER_IMAGE_TAG=1.26.0-python docker run -it --rm --pull=always \ -e LOG_ALL_EVENTS=true \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /home/user1/.openhands:/.openhands \ -e SANDBOX_VOLUMES=/home/user1/dev/ws46_ai_agents/workspacerw \ -e SANDBOX_USER_ID=1000 \ -e AGENT_SERVER_IMAGE_REPOSITORY=ghcr.io/openhands/agent-server \ -e AGENT_SERVER_IMAGE_TAG=1.26.0-python \ -p 3000:3000 \ --add-host host.docker.internal:host-gateway \ --name openhands-app \ docker.openhands.dev/openhands/openhands:latest $ docker ps -a --filter "name=oh-agent-server-" --format '{{.Names}}\t{{.Status}}\t{{.Image}}' oh-agent-server-2k40r2UhAS41OH0St2C3x9 Exited (0) 19 seconds ago ghcr.io/openhands/agent-server:1.26.0-python Later in the web-ui http://localhost:3000/conversations/task-20a5f... 500: Sandbox failed to start within 120s: oh-agent-server-2k40r2UhAS41OH0St2C3x9

Thanks @purple-book-27215

Exited (0)

is the key clue. A startup crash (failed init, missing dependency, permission error) makes the agent-server exit with a non-zero code (uvicorn uses exit 3). An exit code of 0 means the process shut down cleanly, i.e. it was told to stop, not that it errored. So this isn't the server failing to boot; something is stopping it ~10s after it starts. The ``500: Sandbox failed to start within 120s`` is just the downstream symptom: openhands-app keeps polling the sandbox's

/health

for 120s, but the container is already gone. Two quick corrections so we don't chase ghosts: • Your

curl host.docker.internal:8000/health

couldn't have worked. In the default (bridge) network mode, openhands-app publishes the sandbox's container port 8000 to a random host port — not 8000 — and reaches it there. Nothing listens on host port 8000, so that "connection refused" tells us nothing. • The sandbox container is created with

remove=False

, so even though it shows

Exited

, its logs are still there. That's exactly what we need. Right after it exits, grab this (the name changes each attempt, so this picks the latest one):

NAME=$(docker ps -aq --filter "name=oh-agent-server-" --latest)
docker logs "$NAME" 2>&1 | tail -n 120
docker inspect "$NAME" --format 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} started ={{.State.StartedAt}} finished={{.State.FinishedAt}} err={{.State.Error}}'

What to look for in docker logs: •

Received signal SIGTERM/SIGINT, shutting down...

→ the agent-server logs this when something sends it a stop signal. openhands-app does not stop a single sandbox on its own (it only pauses extra sandboxes beyond the limit, or removes on delete), so a signal here means something external is killing it: Docker Desktop, a `docker stop`/cleanup script, or the host. Worth checking whether anything on the host is issuing

docker stop

against

oh-agent-server-*

. • Reaches

Application startup complete

/

Uvicorn running on <http://0.0.0.0:8000>

and then exits → confirms it came up fine and was stopped afterwards (points to an external signal, not a code bug). The

Error preloading chromium

line, if present, is harmless — the server continues past it. • A Python traceback before exit → a genuine startup failure, but that normally shows a non-zero exit code, so given the

0

it's less likely. The docker inspect line also tells us how long it ran (`started`→`finished`) and rules out an OOM kill (

oom=true

, which would be exit 137). Paste the

docker logs

+

docker inspect

output and we'll know in one look whether it's an external stop signal, an OOM, or (less likely) a real crash.

@modern-fireman-99755 I have made much progress. Thanks! This appears to be a permissions problem with the agent server when using this option docker run -it --rm --pull=always \ -e SANDBOX_VOLUMES=/home/user1/dev/ws46_ai_agents/workspacerw \ {"asctime": "2026-06-08 232535,499", "levelname": "INFO", "name": "openhands.agent_server.api", "filename": "api.py", "lineno": 187, "message": "Server initialization complete - ready to serve requests"} {"asctime": "2026-06-08 232535,500", "levelname": "ERROR", "name": "uvicorn.error", "filename": "on.py", "lineno": 121, "message": "Traceback (most recent call last):\n File \"starlette/routing.py\", line 694, in lifespan\n File \"contextlib.py\", line 214, in __aenter__\n File \"fastapi/routing.py\", line 201, in merged_lifespan\n File \"contextlib.py\", line 214, in __aenter__\n File \"fastapi/routing.py\", line 201, in merged_lifespan\n File \"contextlib.py\", line 214, in __aenter__\n File \"fastapi/routing.py\", line 201, in merged_lifespan\n File \"contextlib.py\", line 214, in __aenter__\n File \"fastapi/routing.py\", line 201, in merged_lifespan\n File \"contextlib.py\", line 214, in __aenter__\n File \"openhands/agent_server/api.py\", line 189, in api_lifespan\n File \"openhands/agent_server/conversation_service.py\", line 940, in __aenter__\n File \"pathlib/_local.py\", line 722, in mkdir\nPermissionError: [Errno 13] Permission denied: '/workspace/conversations'\n"} {"asctime": "2026-06-08 232535,500", "levelname": "ERROR", "name": "uvicorn.error", "filename": "on.py", "lineno": 59, "message": "Application startup failed. Exiting."} I created the workspace/conversations dir and progressed to a new error {"asctime": "2026-06-10 023537,250", "levelname": "ERROR", "name": "openhands.agent_server.api", "filename": "api.py", "lineno": 470, "message": "Unhandled exception on POST /api/bash/start_bash_command", "exc_info": "Traceback (most recent call last):\n File \"starlette/middleware/errors.py\", line 164, in __call__\n File \"openhands/agent_server/middleware.py\", line 94, in __call__\n File \"starlette/middleware/cors.py\", line 87, in __call__\n File \"starlette/middleware/exceptions.py\", line 63, in __call__\n File \"starlette/_exception_handler.py\", line 53, in wrapped_app\n File \"starlette/_exception_handler.py\", line 42, in wrapped_app\n File \"fastapi/middleware/asyncexitstack.py\", line 18, in __call__\n File \"starlette/routing.py\", line 716, in __call__\n File \"starlette/routing.py\", line 736, in app\n File \"starlette/routing.py\", line 290, in handle\n File \"fastapi/routing.py\", line 119, in app\n File \"starlette/_exception_handler.py\", line 53, in wrapped_app\n File \"starlette/_exception_handler.py\", line 42, in wrapped_app\n File \"fastapi/routing.py\", line 105, in app\n File \"fastapi/routing.py\", line 424, in app\n File \"fastapi/routing.py\", line 312, in run_endpoint_function\n File \"openhands/agent_server/bash_router.py\", line 98, in start_bash_command\n File \"openhands/agent_server/bash_service.py\", line 207, in start_bash_command\n File \"openhands/agent_server/bash_service.py\", line 60, in _save_event_to_file\n File \"openhands/agent_server/bash_service.py\", line 41, in _ensure_bash_events_dir\n File \"pathlib/_local.py\", line 722, in mkdir\nPermissionError: [Errno 13] Permission denied: '/workspace/bash_events'"} I created the workspace/bash_events dir. I opened the permissions for the workspace directory tree chmod 777 bash_events conversations I was able to get farther. It appears to complete the new conversation and fails on this error back in openhands. 025439 - openhands.app_server.event_callback.webhook_routerERROR webhook_router.py:475 - Error in webhook Traceback (most recent call last): File "/app/openhands/app_server/event_callback/webhook_router.py", line 419, in on_event await asyncio.gather( *[event_service.save_event(conversation_id, event) for event in events] ) File "/app/openhands/app_server/event/event_service_base.py", line 168, in save_event await loop.run_in_executor(None, self._store_event, path, event) File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 59, in run result = self.fn(*self.args, **self.kwargs) File "/app/openhands/app_server/event/filesystem_event_service.py", line 34, in _store_event path.parent.mkdir(parents=True, exist_ok=True) ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.13/pathlib/_local.py", line 722, in mkdir os.mkdir(self, mode) ~~~~~~~~^^^^^^^^^^^^ PermissionError: [Errno 13] Permission denied: '/.openhands/v1_conversations/e56f65ea03704dc6add19d25073fb5a1'

@purple-book-27215 Yeah 😄 we will find the solution 💪 Ok the problem is that a non-root process can't write into a bind-mounted host dir it doesn't own. The reason is that two different containers run as two different fixed UIDs, against two different mounts: • openhands-app runs as

SANDBOX_USER_ID

(you set 1000). It writes the app-side event store to

/.openhands/v1_conversations/…

→ your

~/.openhands.

That's the error you're hitting now. • oh-agent-server-* runs as

UID

10001 (openhands, baked into the agent-server image).

SANDBOX_USER_ID

is not passed through to it, so it's always 10001 no matter what you set. It writes

conversations/

and

bash_events/

into your mounted workspace →

/home/user1/dev/ws46_ai_agents

. That's why chmod 777 on those dirs — not the UID setting — is what unblocked the sandbox. So fix each side for its own UID: App side (~/.openhands, owned by SANDBOX_USER_ID):

# set the app's UID to YOUR user instead of hardcoding 1000
 -e SANDBOX_USER_ID=$(id -u) 
 # and make ~/.openhands match it
 sudo chown -R $(id -u):$(id -g) /home/user1/.openhands

This is exactly the "manually adjust permissions of

~/.openhands

for this user" note in the official docker-compose. Workspace side (agent-server, UID 10001 — not configurable): Quickest: keep what you did: make the workspace writable by 10001 (

chmod 777

, or cleaner:

setfacl -R -m u:10001:rwx -m d:u:10001:rwx /home/user1/dev/ws46_ai_agents

). Cleanest/permanent: build a custom agent-server image as your UID and point the image vars at it — the Dockerfile takes a build arg:

docker build --build-arg UID=$(id -u) --build-arg GID=$(id -g) -t my-agent-server:1.26 ...
 -e AGENT_SERVER_IMAGE_REPOSITORY=my-agent-server -e AGENT_SERVER_IMAGE_TAG=1.26

Then the sandbox runs as you and the workspace permission problem disappears. Two 5-second confirmations that prove the above:

docker inspect $(docker ps -aq --filter "name=oh-agent-server-" --latest) --format '{{.Config.User}}'  # expect openhands / 10001
 docker exec -it openhands-app id                                     # expect uid=<SANDBOX_USER_ID>

🤞

Manually adjusting the permissions of ~/.openhands using -e SANDBOX_USER_ID=$(id -u) It is working! Thank you for all of your help. I was able to get the bash hello.bash created and corresponding test_hello.bash. All tests passed.

I think all of the problems are in this thread. Here is my info on the docker install to help any devs or testers to reproduce. I try to keep my configs as simple/default as possible for ease of setup for myself and the other devs. I used the default fedora install of docker. https://developer.fedoraproject.org/tools/docker/docker-installation.html sudo dnf install dnf-plugins-core # to start docker sudo systemctl start docker failed, need to add user to the docker group sudo usermod -aG docker $USER re-login OR newgrp docker

thanks a lot