Description
Feature Request: Port Forwarding from Sandbox to Host
Summary
Add the ability to expose sandbox ports to the WSL2/host network, enabling browser-based access to the OpenClaw Control UI and custom web applications running inside the sandbox.
Problem
The OpenClaw gateway listens on 127.0.0.1:18789 inside the sandbox, but the OpenShell network namespace (netns) isolation makes this port completely unreachable from:
The WSL2 host
The Windows host
Any browser on the host machine
This means:
The OpenClaw Control UI / dashboard is inaccessible from a browser
Custom web applications (e.g., chat bridges, dev tools) running inside the sandbox cannot serve traffic to the host
The only interface available is the terminal TUI (openclaw tui), which has reliability issues with paste, long responses, and session stability
What I Tried
Direct browser access to localhost:18789 — connection refused (port not visible outside sandbox)
WSL2 port forwarding via netsh interface portproxy — fails because port is not on WSL2 network, only inside sandbox netns
Node.js reverse proxy inside sandbox bound to 0.0.0.0:3000 — starts successfully but unreachable from WSL2 due to same netns isolation
Python socket forwarder inside sandbox — same result
curl http://127.0.0.1:18789 from WSL2 (outside sandbox) — connection refused, confirming the port is netns-isolated
openshell sandbox subcommands — no port-forward or equivalent exists
Proposed Solution
Add an openshell sandbox port-forward command (similar to kubectl port-forward) that creates a tunnel from the host network into the sandbox network namespace:
bashopenshell sandbox port-forward clawville-001 18789:18789
or
openshell sandbox port-forward clawville-001 3000:3000
This would allow:
Browser access to the OpenClaw Control UI from Windows
Custom web applications inside the sandbox to serve the host
Development workflows that require browser-based tools
Alternative approaches that would also solve this:
A --expose-ports flag on openshell sandbox create
An openshell sandbox expose command to selectively open ports
Built-in reverse proxy in the OpenShell gateway that forwards to sandbox ports
Environment
OS: Windows 11 Home (Build 26100.7171)
WSL2: Ubuntu 24.04
Hardware: Intel i7-14700 (20 cores/28 threads), 64GB DDR5, NVIDIA RTX 4070 12GB
Docker: Docker Desktop with WSL2 backend
NemoClaw: v0.1.0 (installed 2026-03-24)
OpenShell: v0.0.14
OpenClaw: 2026.3.11
Sandbox: Landlock + seccomp + netns isolation
Use Case
I am running NemoClaw as a persistent compute node in a multi-AI federation (multiple AI agents coordinated with human-in-the-loop governance). The TUI is insufficient for production workflows that involve:
File upload via drag-and-drop
Formatted markdown response display
Long-running sessions with reliable copy/paste
Integration with browser-based development tools
A browser-accessible interface is essential for practical use of NemoClaw beyond basic terminal interaction.
Workaround Attempted
Built a Node.js Express/WebSocket bridge application to proxy between the browser and the OpenClaw gateway. The bridge runs successfully inside the sandbox but the netns isolation prevents any external access. Running the bridge outside the sandbox fails because it cannot reach the gateway port inside the sandbox. This confirms the issue is specifically the lack of host-to-sandbox port forwarding.
Labels
enhancement, networking, sandbox
Reproduction Steps
- Run
nemoclaw onboard on Windows 11 WSL2
- Select cloud inference (Nemotron 120B)
- Connect to sandbox:
nemoclaw clawville-001 connect
- Inside sandbox, confirm gateway listening:
ss -tlnp shows 127.0.0.1:18789
- Exit sandbox, from WSL2 run:
curl http://127.0.0.1:18789 - connection refused
- From Windows browser:
http://localhost:18789 - connection refused
- No
openshell sandbox port-forward command exists
Environment
- OS: Windows 11 Home (Build 26100.7171) / Ubuntu 24.04 (WSL2)
- Node.js: v22.22.1
- Docker: Docker Desktop 4.x / Docker Engine 27.x
- NemoClaw: v0.1.0
- OpenShell: v0.0.14
- OpenClaw: 2026.3.11
Debug Output
Logs
Checklist
Description
Feature Request: Port Forwarding from Sandbox to Host
Summary
Add the ability to expose sandbox ports to the WSL2/host network, enabling browser-based access to the OpenClaw Control UI and custom web applications running inside the sandbox.
Problem
The OpenClaw gateway listens on 127.0.0.1:18789 inside the sandbox, but the OpenShell network namespace (netns) isolation makes this port completely unreachable from:
The WSL2 host
The Windows host
Any browser on the host machine
This means:
The OpenClaw Control UI / dashboard is inaccessible from a browser
Custom web applications (e.g., chat bridges, dev tools) running inside the sandbox cannot serve traffic to the host
The only interface available is the terminal TUI (openclaw tui), which has reliability issues with paste, long responses, and session stability
What I Tried
Direct browser access to localhost:18789 — connection refused (port not visible outside sandbox)
WSL2 port forwarding via netsh interface portproxy — fails because port is not on WSL2 network, only inside sandbox netns
Node.js reverse proxy inside sandbox bound to 0.0.0.0:3000 — starts successfully but unreachable from WSL2 due to same netns isolation
Python socket forwarder inside sandbox — same result
curl http://127.0.0.1:18789 from WSL2 (outside sandbox) — connection refused, confirming the port is netns-isolated
openshell sandbox subcommands — no port-forward or equivalent exists
Proposed Solution
Add an openshell sandbox port-forward command (similar to kubectl port-forward) that creates a tunnel from the host network into the sandbox network namespace:
bashopenshell sandbox port-forward clawville-001 18789:18789
or
openshell sandbox port-forward clawville-001 3000:3000
This would allow:
Browser access to the OpenClaw Control UI from Windows
Custom web applications inside the sandbox to serve the host
Development workflows that require browser-based tools
Alternative approaches that would also solve this:
A --expose-ports flag on openshell sandbox create
An openshell sandbox expose command to selectively open ports
Built-in reverse proxy in the OpenShell gateway that forwards to sandbox ports
Environment
OS: Windows 11 Home (Build 26100.7171)
WSL2: Ubuntu 24.04
Hardware: Intel i7-14700 (20 cores/28 threads), 64GB DDR5, NVIDIA RTX 4070 12GB
Docker: Docker Desktop with WSL2 backend
NemoClaw: v0.1.0 (installed 2026-03-24)
OpenShell: v0.0.14
OpenClaw: 2026.3.11
Sandbox: Landlock + seccomp + netns isolation
Use Case
I am running NemoClaw as a persistent compute node in a multi-AI federation (multiple AI agents coordinated with human-in-the-loop governance). The TUI is insufficient for production workflows that involve:
File upload via drag-and-drop
Formatted markdown response display
Long-running sessions with reliable copy/paste
Integration with browser-based development tools
A browser-accessible interface is essential for practical use of NemoClaw beyond basic terminal interaction.
Workaround Attempted
Built a Node.js Express/WebSocket bridge application to proxy between the browser and the OpenClaw gateway. The bridge runs successfully inside the sandbox but the netns isolation prevents any external access. Running the bridge outside the sandbox fails because it cannot reach the gateway port inside the sandbox. This confirms the issue is specifically the lack of host-to-sandbox port forwarding.
Labels
enhancement, networking, sandbox
Reproduction Steps
nemoclaw onboardon Windows 11 WSL2nemoclaw clawville-001 connectss -tlnpshows 127.0.0.1:18789curl http://127.0.0.1:18789- connection refusedhttp://localhost:18789- connection refusedopenshell sandbox port-forwardcommand existsEnvironment
Debug Output
Logs
Checklist