windows-local-ai-services — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited windows-local-ai-services (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Running local AI services (enowxai, Ollama, LM Studio, vLLM, llama.cpp servers) on Windows has specific networking and port binding pitfalls. This skill covers setup, troubleshooting, and WSL2 cross-OS access.
references/windows-port-restrictions.md — Windows reserved port ranges and binding errorsreferences/headless-gui-apps.md — Running GUI apps in headless WSL2 with XvfbSymptom: Service crashes immediately with:
ERROR failed to start error="listen tcp4 127.0.0.1:1430: bind: An attempt was made to access a socket in a way forbidden by its access permissions."Root Cause: Windows reserves certain port ranges for system services (Hyper-V, WinNAT, dynamic port allocation). Ports in these ranges cannot be bound by user applications.
Fix:
# Use a port outside reserved ranges (8000-9000 is usually safe)
service start --port 8430 netsh int ipv4 show dynamicport tcp
netsh int ipv4 show excludedportrange protocol=tcp netsh int ipv4 add excludedportrange protocol=tcp startport=1430 numberofports=1Never kill `svchost.exe` — it's a Windows system service host. If netstat shows svchost using your target port, the port is reserved by Windows.
Symptom: Service runs on Windows but WSL2 cannot connect via localhost.
Root Cause: WSL2 uses a virtualized network. localhost in WSL2 points to the WSL2 VM, not the Windows host.
Fix:
# Get Windows host IP (usually 172.17.16.1, but can change on reboot)
ip route show default | awk '{print $3}'
# Test connection
curl http://172.17.16.1:8430/v1/models # Check listening address
netstat -ano | findstr :8430
# Should show 0.0.0.0:8430, not 127.0.0.1:8430 # Allow inbound on the service port
New-NetFirewallRule -DisplayName "AI Service Port 8430" -Direction Inbound -LocalPort 8430 -Protocol TCP -Action AllowSymptom: Service says "port already in use" but Get-Process shows nothing.
Diagnosis:
# Find what's using the port
netstat -ano | findstr :8430
# Get process details (replace 1234 with PID from netstat)
Get-Process -Id 1234 | Select-Object Name, Id, PathFix:
svchost or another system service: change your service's portAlways check logs first:
# Common log locations
Get-Content ~\.service-name\service.log -Tail 50
Get-Content $env:APPDATA\service-name\logs\latest.log -Tail 50Common causes:
When setting up a new local AI service on Windows:
curl http://localhost:PORT/healthcurl http://$(ip route show default | awk '{print $3}'):PORT/health~/.bashrc: export WINDOWS_HOST=$(ip route show default | awk '{print $3}')
export AI_SERVICE_URL="http://$WINDOWS_HOST:8430/v1"After setup, verify cross-OS connectivity:
# From WSL2
GATEWAY_IP=$(ip route show default | awk '{print $3}')
echo "Windows host IP: $GATEWAY_IP"
# Test connection
curl -s http://$GATEWAY_IP:8430/v1/models | jq .
# If it works, save to config
echo "export AI_SERVICE_URL=http://$GATEWAY_IP:8430/v1" >> ~/.bashrclocalhost~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.