Just trying to work on a project with local gui an...
# questions
h
Just trying to work on a project with local gui and
openhands serve --mount-cwd
but I don't see the files available in a conversation and not even getting conversation to work. I did notice v1.15.0 of the SDK is loaded by Docker but the CLI is using v1.16.1 if that matters at all. IIRC everything was all working smoothly when I was doing the same thing a week or two ago. After some poking around I noticed it created a project folder in the repo and that empty "project" folder is all vscode and the agent conversation seem to see. Here is the response from 'Can you tell me about this repo?'
Copy code
## Repository Summary

This is a **brand new, empty Git repository**. Here are the key details:

| Aspect | Details |
|--------|---------|
| **Location** | `/workspace/project` |
Anyone else run into something like that before?
n
Figured this out the mount itself is fine, the files are at
/workspace
. But it looks like the GUI is passing a
selected_repository
when you create a conversation, which triggers
clone_or_init_repo
to create
/workspace/project
as an empty subdirectory. The agent then works from there instead of
/workspace
where the actual mounted files live. Skipping the repo selection in the GUI dropdown fixed it for me. Also worth pulling latest Docker images if yours are stale mine were months behind.
h
I keep getting it no matter what I try. New repo, start a new conversation, don't interact with the agent and an empty project folder is immediately created.
I had openhands look at this and it appears like its intentional although it seems weird:
Copy code
## Answer: This is Expected Behavior, Not a Bug in the CLI

The behavior you're experiencing is **expected** - it's how the OpenHands Docker runtime (app image and agent-server) works, not a bug in the CLI code.

### What's Happening

When you run `openhands serve --mount-cwd`, the CLI correctly sets:
```bash
SANDBOX_VOLUMES=/your/current/dir:/workspace:rw
This mounts your directory to
/workspace
in the sandbox. However, the OpenHands app then creates a standard workspace structure with subdirectories: -
/workspace/project
- where your actual code work happens -
/workspace/bash_events
- for tracking bash events -
/workspace/conversations
- for conversation data The agent and VSCode tool are configured to work in
/workspace/project
, not
/workspace
directly. This is by design in the OpenHands backend. ### The Impact on Your Workflow When you mount your repo directory: 1. OpenHands mounts it to
/workspace
2. OpenHands creates
/workspace/project
inside your repo directory 3. The agent works in
/workspace/project
(which is empty) instead of
/workspace
(where your files are) ### Known Issue This is a recognized limitation. There's an open GitHub issue ([#13520](https://github.com/OpenHands/OpenHands/issues/13520)) discussing this workspace structure and how it affects users who want to mount existing directories. ### Workaround Unfortunately, there's no direct fix from the CLI side. The workspace directory structure (
/workspace/project
) is enforced by the OpenHands backend (the app and agent-server images). Some options to consider: 1. Move your project files into the
project
subdirectory
that OpenHands creates, then work from there 2. Watch the OpenHands main repo for updates - there are ongoing discussions about improving the workspace mounting experience 3. Use
SANDBOX_VOLUMES
with a subdirectory
like:
Copy code
bash
   export SANDBOX_VOLUMES=/path/to/your/repo:/workspace/project:rw
Then run
openhands serve
(without
--mount-cwd
). This would mount your repo directly to
/workspace/project
where the agent expects to work. ### Summary The CLI code in
gui_launcher.py
is working correctly - it's mounting to
/workspace
as documented. The creation of the
/workspace/project
subdirectory is done by the OpenHands app/agent-server, not by the CLI. This is an upstream design decision in the OpenHands platform.```
n
correction on my earlier comment skipping repo selection doesn't actually fix this, you're right. Dug deeper and the backend always creates
/workspace/project
as the standard agent working directory regardless of conversation settings. The actual workaround is mounting directly to
/workspace/project
instead of
/workspace
Copy code
export SANDBOX_VOLUMES=$(pwd):/workspace/project:rw
openhands serve
No
--mount-cwd
needed. That puts your files where the agent is already looking. Feels like the CLI's
--mount-cwd
flag should be updated to mount to
/workspace/project
instead of
/workspace
to match what the backend expects.
h
Yep, I got there as well. Not sure if its intentional. Running a few more tests and then I'll bump to an issue or one of the project channels. Feels a bit weird to mount a folder and then not have access it it.