Below is a copy-paste Windows 11 checklist for the most reliable current setup: WSL2 Ubuntu + Docker Desktop + NemoClaw + Ollama running inside WSL. NVIDIA’s Windows path is WSL2 with Docker Desktop, and CMD/PowerShell are not supported for the install flow.nvidia+1
0) Before you start
-
Update Windows 11.
-
Make sure your NVIDIA Windows driver is current.
-
Reboot if you just updated the GPU driver.
-
Use an admin PowerShell for the Windows-side commands below.gist.github+1
1) Install WSL2
Run this in PowerShell as Administrator:
wsl --install
wsl --update
wsl --set-default-version 2
wsl --status
If you want a specific distro, install Ubuntu from the Microsoft Store or run:
wsl --install -d Ubuntu-24.04
NVIDIA’s supported Windows path is WSL2, and the Ollama integration page also says Windows requires WSL2 with Docker Desktop.ollama+1
2) First Ubuntu setup
Open Ubuntu from the Start menu, then run:
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl git ca-certificates gnupg lsb-release
Check that WSL can see the GPU:
nvidia-smi
You should see your NVIDIA GPU from inside Ubuntu if the Windows driver and WSL GPU support are working.boxmining+1
3) Install Docker Desktop
Install Docker Desktop in Windows, then enable:
-
Use the WSL 2 based engine.
-
Integrate Docker with your Ubuntu distro.
After Docker Desktop starts, verify from Ubuntu:
docker version
docker run --rm hello-world
Docker Desktop is the supported container runtime for the Windows WSL2 setup, and GPU-enabled containers on Windows 11/WSL2 depend on the Windows NVIDIA driver rather than a Linux driver inside WSL.github+2
4) Enable NVIDIA GPU passthrough for Docker
In Ubuntu inside WSL, install the NVIDIA container runtime tooling:
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
Then restart Docker Desktop from Windows, or run:
wsl --shutdown
and reopen Ubuntu + Docker Desktop.gist.github+1
Test GPU passthrough in Docker:
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
If that prints your GPU, Docker GPU passthrough is working.github+1
5) Install Node.js in WSL
NVIDIA’s quickstart expects Node.js 20+ and npm 10+. Easiest path in Ubuntu:nvidia
sudo apt update
sudo apt install -y nodejs npm
node -v
npm -v
If you want to pin a newer version, use nvm, but the simple apt install is fine for the first pass.github+1
6) Install NemoClaw
Run the official bootstrap script in Ubuntu:
curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
If the installer asks about setup, follow the prompts and keep it in the WSL Ubuntu environment.nvidia
7) Start NemoClaw
After install, start the gateway:
openshell gateway start --name nemoclaw
Then connect:
nemoclaw nemoclaw connect
The current WSL2 guidance suggests the automated onboarding can mis-handle GPU mode, so a manual gateway start without forcing GPU is often safer on Windows WSL2.github+2
8) Install Ollama in WSL
Because Windows-hosted Ollama can be unreachable from the NemoClaw sandbox on WSL2, the safer option is to run Ollama inside the same WSL Ubuntu environment. Install it in Ubuntu with:github+1
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
Start the server:
ollama serve
Pull a model:
ollama pull llama3.1
Ollama’s NemoClaw integration page says Ollama must already be installed and running before the installer runs, and it specifically warns that sandbox reachability matters in WSL2/container setups.ollama
9) Point NemoClaw at Ollama
If your NemoClaw/OpenClaw setup has an inference config command, use the Ollama-local backend and point it at the WSL-hosted Ollama endpoint, typically:
openshell inference set --provider ollama-local --base-url http://host.openshell.internal:11434 --model llama3.1 --no-verify
If that hostname does not work in your build, use the WSL host IP instead, or the workaround documented in the current WSL2 issue track.github+1
10) Quick verification
nvidia-smi
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
ollama run llama3.1 "Say hello in one sentence"
If all three work, your base stack is good: WSL GPU access, Docker GPU passthrough, and local model inference.boxmining+2
Yes — for this setup, “agents” usually means your own client app or framework talking to Ollama’s API, not something built into Ollama itself. The cleanest approach in WSL is to run Ollama as the model server, then connect an agent framework or app to http://127.0.0.1:11434 or the WSL-reachable host address, with the model server kept inside the same WSL environment for reachability.github+2
Agent setup checklist
-
Confirm WSL Ubuntu is running.
-
Confirm Ollama is installed in WSL, not only on Windows.
-
Start Ollama:
ollama serve. -
Pull an agent-capable model:
ollama pull llama3.1or similar. -
Verify the model runs:
ollama run llama3.1 "hello". -
Build your agent in a framework like Python, LangChain, Agno, or your own app, and point it at Ollama’s local API.shshell+1
WSL Ollama commands
Run these inside Ubuntu in WSL:
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama serve
In another WSL terminal, test a model:
ollama pull llama3.1
ollama run llama3.1 "You are a helpful assistant. Reply with one sentence."
Ollama’s NemoClaw integration notes that Ollama must already be installed and running before integration, and that WSL/container reachability matters.ollama
If you want “agentic” behavior
Create an agent that uses the Ollama API plus tools/functions. A minimal Python pattern is:
python3 -m venv .venv
source .venv/bin/activate
pip install -U ollama
Then in Python:
from ollama import chat
resp = chat(
model='llama3.1',
messages=[
{'role': 'system', 'content': 'You are a concise assistant.'},
{'role': 'user', 'content': 'Plan my day in 3 bullets.'}
]
)
print(resp['message']['content'])
This is the basic pattern you’d use before adding tool use, memory, or multi-step orchestration.docs-v1.agno+1
If you want a tool-using agent
-
Pick a framework: LangChain, Agno, or your own code.
-
Point the framework’s model wrapper to Ollama.
-
Register tools such as web search, file access, or shell calls.
-
Keep temperature low for more reliable tool calling.
-
Test one tool first, then add more.shshell+1
Example with a Python agent framework from the docs I found:
from agno.agent import Agent
from agno.models.ollama import Ollama
from agno.tools.duckduckgo import DuckDuckGoTools
agent = Agent(
model=Ollama(id="llama3.1:8b"),
tools=[DuckDuckGoTools()],
show_tool_calls=True,
markdown=True,
)
agent.print_response("What's happening in France?", stream=True)
That pattern shows the general idea: Ollama provides the model, and the agent framework adds tools and orchestration.docs-v1.agno+1
NemoClaw-specific note
If you want these agents to run in NemoClaw, keep Ollama in WSL and make sure the sandbox can reach it. Current WSL2 reports show that Windows-hosted Ollama is unreliable from inside the sandbox, so the WSL-local Ollama path is still the safest route.github+1
Best-practice checklist for your machine
-
Use WSL2 Ubuntu 22.04+ or 24.04.
-
Run Ollama inside WSL.
-
Use an agent framework or custom Python code.
-
Test direct Ollama calls before adding tools.
-
If integrating with NemoClaw, verify sandbox reachability early.ollama+1
If you want, I can turn this into a single “agent starter kit” checklist with exact commands for Python, LangChain/Agno, and an Ollama-backed tool-calling agent.