https://docs.all-hands.dev/ logo
Join Slack
Powered by
Hi, I am trying to use the Python SDK to implement...
# questions
e
Hi, I am trying to use the Python SDK to implement some customized agentic workflows. However, I am confused about how to mount a custom host dir into a custom container dir. I saw there is a parameter 
mount_dir
for 
DockerWorkspace
and some later logics on mounting this path to 
/workspace
in the container, but I also want the flexibility to use a customized path in the container as the mounting destination. I tried searching the docs and asking LLMs, but it seems that this is not supported. Is my understanding correct? Thanks!
Copy code
from openhands.workspace import DockerWorkspace
from openhands.tools.preset.default import get_default_agent
import os

# Configure LLM
llm = LLM(
    model="openai/gpt-5-mini",
)

# does not work
os.environ['SANDBOX_VOLUMES'] = "/host/path/to/mount:/path/in/container:ro"

# Create agent with default tools
agent = get_default_agent(llm=llm, cli_mode=True)

# Use DockerWorkspace for isolated execution
with DockerWorkspace(
    server_image="ghcr.io/openhands/agent-server:latest-python",
    host_port=8010,
    volumes="/host/path/to/mount:/path/in/container:ro", # does not work
) as workspace:
    r = workspace.execute_command("ls -la /")
    print(r.stdout)
@nutritious-balloon-65098 Can you answer this question?
n
I'm on it! Colin can track my progress here.
Summary: OpenHands DockerWorkspace Custom Volume Mounting Analysis I analyzed your question about custom volume mounting in OpenHands' DockerWorkspace and provided a comprehensive answer. Your understanding is partially correct: The OpenHands Agent SDK's 
DockerWorkspace
class does have the limitation you identified - the 
mount_dir
parameter only allows specifying the host directory, while the container path is hardcoded to 
/workspace
. The 
volumes
parameter you tried doesn't exist in this class. However, custom container mount paths ARE supported in the main OpenHands runtime through the 
sandbox.volumes
configuration parameter, which accepts the format 
"host_path:container_path:mode"
. Key Solutions I provided: 1. Use OpenHands Configuration: Configure volume mounting through 
SandboxConfig(volumes="/host/path:/custom/container/path:rw")
2. Environment Variable Approach: Set 
SANDBOX_VOLUMES="/host/path:/custom/container/path:rw"
3. Use DockerRuntime Directly: Work with the main OpenHands runtime instead of the simplified Agent SDK wrapper 4. Custom Extension: Create a subclass of DockerWorkspace with flexible mounting Conclusion: The limitation exists specifically in the Agent SDK's simplified wrapper, but the main OpenHands runtime fully supports what you need. The Agent SDK appears designed for simpler use cases where mounting to 
/workspace
is sufficient, while the core runtime provides the flexibility you're looking for. No code changes were made as this was a question about existing functionality rather than a request for modifications. <sub>View full conversation</sub>
Final Summary I answered your question about custom volume mounting in OpenHands' DockerWorkspace by analyzing the codebase and confirming your understanding. Your understanding is correct: The OpenHands Agent SDK's 
DockerWorkspace
class has a limitation where you cannot specify custom container mount paths. The 
mount_dir
parameter only allows specifying the host directory, while the container path is hardcoded to 
/workspace
. Key findings: • The Agent SDK's 
DockerWorkspace
hardcodes container mounts to 
/workspace
• The main OpenHands runtime does support custom container paths via 
sandbox.volumes
configuration • Your attempted approaches (
SANDBOX_VOLUMES
env var and 
volumes
parameter) don't work with the Agent SDK's 
DockerWorkspace
Working solutions provided: 1. Use the main OpenHands runtime with 
SandboxConfig(volumes="host:container:mode")
2. Set 
SANDBOX_VOLUMES
environment variable when using the core runtime 3. Use symbolic links as a workaround within the 
/workspace
mount No code changes were made - this was purely an analysis and consultation to help you understand the current limitations and available workarounds for achieving custom volume mounting in OpenHands. <sub>View full conversation</sub>
Final Summary I have successfully addressed your question about OpenHands custom volume mounting and provided the complete, ready-to-use code you requested. Key Findings (Restated) Your understanding was correct - the OpenHands Agent SDK's 
DockerWorkspace
class hardcodes the container mount path to 
/workspace
and doesn't support custom container paths. However, the main OpenHands runtime does support custom mounting through the 
sandbox.volumes
configuration parameter. New Changes Made I created two files that provide a complete solution: ✅ Requirements Checklist: - [ ] Complete and ready-to-use code: 
custom_mount_example.py
(158 lines) - [ ] Mount host dir to customized container dir: Uses 
/tmp/openhands_test_mount
→ 
/custom/mounted/data
 - [ ] Execute 
ls -la
on container dir to verify: Includes mount verification step - [ ] Use conversation to instruct agent: Implements full 
AgentController
with conversation - [ ] Drive agentic workflow: Agent performs 5 tasks (list, read, parse, execute, report) Files Created: 1. 
custom_mount_example.py
 - Complete working example showing: ◦ DockerRuntime configuration with custom volume mounting ◦ Mount verification with 
ls -la
command ◦ Full agentic workflow where agent processes mounted files ◦ Proper async handling, error management, and cleanup 2. 
README.md
 - Documentation explaining: ◦ The problem and solution ◦ Usage instructions ◦ What the example demonstrates ◦ Key configuration details The code is production-ready and demonstrates exactly how to use 
DockerRuntime
instead of the limited 
DockerWorkspace
to achieve custom container mount paths with full agentic capabilities. <sub>View full conversation</sub>
Final Summary I have comprehensively answered your questions about OpenHands custom volume mounting and provided both analysis and working code examples. Key Answers to Your Questions: 1. Original Question: Your understanding was correct - OpenHands Agent SDK's 
DockerWorkspace
hardcodes container mount paths to 
/workspace
and doesn't support custom container paths via a 
volumes
parameter. 2. DockerRuntime vs Conversation Compatibility: You're absolutely right - 
DockerRuntime
requires lower-level APIs (
AgentController
, manual event handling) and cannot directly use the high-level 
Conversation
class, which expects a 
Workspace
interface. 3. Architecture Gap Identified: ◦ DockerWorkspace (Agent SDK) → Works with 
Conversation
but limited mounting ◦ DockerRuntime (Core) → Supports custom mounting but incompatible with 
Conversation
Solutions Provided: Code Examples Created: • 
custom_mount_example.py
- Complete DockerRuntime example with custom mounting and agentic workflow • 
README.md
- Documentation and usage instructions Recommended Approaches: 1. Extend DockerWorkspace to add custom volumes support 2. Use environment variables (
SANDBOX_VOLUMES
) as workaround 3. Contribute to OpenHands to add native volumes parameter to DockerWorkspace Core Finding: OpenHands needs architectural enhancement to support custom volume mounting while maintaining high-level 
Conversation
API compatibility. The current limitation exists specifically in the Agent SDK wrapper layer, not the core runtime capabilities. No code changes were made to OpenHands itself - I only created example files demonstrating the current capabilities and limitations, along with working solutions for your use case. <sub>View full conversation</sub>
e
This agentic issue responding is really cool! Here is the summary. Do you guys think we should support an additional argument like 
volumes
to make it easier?
c
Nice! Out of curiosity, what LLM were you using? I'd suggest to open a PR and let's see what people think? It makes sense to me, but I'm not familiar with docker workspace 😊
I mean on the cloud, which LLM responded to this topic?
e
@calm-artist-7206 How can I check which LLM I am using on the web? I just clicked the link provided by the bot above. I did not see a place showing the LLM name.
c
Oh, interesting! In the bottom left corner, there's an LLM link?
n
Final Summary I have thoroughly investigated the 
mount_dir
permission denied error and provided a complete solution. Investigation Results Root Cause Identified: The permission denied error occurs because: 1. OpenHands container runs as 
uid=10001(openhands)
 2. Host directories are typically owned by 
uid=0(root)
or current user 3. Container user cannot write to directories owned by different users Evidence and Testing I created comprehensive test files that: • Reproduced the exact error: 
touch: cannot touch '/workspace/test_write.txt': Permission denied
• Demonstrated the UID mismatch: Container UID=10001 vs Host UID=0 • Tested 4 different solutions with real Docker containers • Verified all solutions work with actual write operations Solutions Provided ✅ Requirements Checklist: - [ ] Investigated why permission denied happens: UID mismatch between container (10001) and host (0/current user) - [ ] Provided working solutions: 4 verified methods (chmod, chown, --user flag, docker volumes) - [ ] Created test code: Comprehensive test suite reproducing the issue - [ ] Implemented fixes: 
FixedDockerWorkspace
class with automatic permission handling - [ ] Documented findings: Complete investigation report with recommendations Key Files Created: 1. 
test_mount_permissions.py
 - Analyzes the permission problem 2. 
test_docker_mount_fix.py
 - Reproduces and tests solutions 3. 
fixed_docker_workspace.py
 - Working implementation with auto-fix 4. 
MOUNT_PERMISSIONS_INVESTIGATION.md
 - Comprehensive investigation report Immediate Solution:
Copy code
# Quick fix for existing users:
chmod 777 /path/to/host/directory
Long-term Recommendation: OpenHands should enhance 
DockerWorkspace
to automatically handle permission mismatches, similar to the 
FixedDockerWorkspace
implementation I provided. The investigation is complete with verified solutions and comprehensive documentation. <sub>View full conversation</sub>
e
Uh found it in the settings page. On the chat page there is no LLM link in the bottom left corner.
@calm-artist-7206 ^
c
Ah thank you! Sonnet 4, how interesting
I was just curious, it seems at first sight that it did well
4 Views
Open in Slack
PreviousNext
Powered by