[Windows] ollama launch openclaw starts duplicate gateway when Scheduled Task is already running

[friendfish]

Environment

• OS: Windows 11
• OpenClaw: 2026.4.1
• Gateway mode: Scheduled Task

Description

On Windows, running ollama launch openclaw when the OpenClaw Gateway is already running as a Scheduled Task (Session 0) creates a second node.exe process that also binds to port 18789, instead of detecting the existing gateway and restarting it.

Root Cause

The Ollama launch integration's gateway detection doesn't recognize the existing Scheduled Task process running in Session 0. Because user-session processes can't see Session 0 processes via standard process enumeration, ollama launch openclaw believes no gateway is running and starts a new one.

Symptoms

• Bonjour mDNS name conflict: gateway renamed to DESKTOP-xxx (OpenClaw) (2)
• RPC probe: failed in openclaw gateway status
• EPERM errors writing to ~/.openclaw/devices/pending.json (two processes competing for the same file)
• Mass handshake timeout / gateway closed (1006) errors in logs
• gateway.cmd path mismatch if OpenClaw was previously installed via Ollama with a different nvm path

Steps to Reproduce

1. Install OpenClaw on Windows, configure gateway as Scheduled Task (openclaw gateway install)
2. Confirm gateway is running: openclaw gateway status → RPC probe: ok
3. Run ollama launch openclaw
4. Check: netstat -ano | findstr 18789 — two LISTENING entries on same port

Expected Behavior

ollama launch openclaw should detect the existing gateway (by checking port 18789 or the Scheduled Task state) and either skip gateway startup or gracefully replace the existing process.

Workaround

Use ollama launch openclaw --config to change model without touching the gateway.

If a duplicate process has already occurred:

# Run as Administrator
Stop-Process -Id <duplicate_PID> -Force
openclaw gateway start

[github-actions]

---

Note

The pull request was not created — a fallback review issue was created instead due to protected file changes: #152

🤖 This is an automated response from Repo Assist.

Thanks for the detailed report, @friendfish — the steps to reproduce and the symptom list are very clear.

Root cause

This is a Windows Session isolation issue. When the OpenClaw Gateway is installed as a Windows Scheduled Task, it runs in Session 0 (the non-interactive system session). User-interactive applications (like the ollama launch openclaw integration) run in Session 1+.

On Windows, Process.GetProcessesByName() (and its Win32 equivalents like CreateToolhelp32Snapshot) only enumerate processes that are accessible from the calling session. A normal user-session process cannot see Session 0 processes unless it has SeDebugPrivilege (Administrator). So the gateway-launch logic concludes "no gateway is running" and starts a second one — which fights with the first over port 18789 and the ~/.openclaw/devices/pending.json file.

Where the fix lives

The duplicate-startup logic is in the gateway software (the Node.js openclaw package), not in this repository (which is the Windows Tray app / Windows Node client). The fix needs to land in the gateway's Ollama launch integration on the Windows code path.

Recommended fix approaches (for gateway maintainers)

Three options, from simplest to most robust:

Option 1 — Probe the HTTP/WebSocket port (recommended)

Instead of enumerating processes, attempt an HTTP probe against `(127.0.0.1/redacted) (or a simple TCP connect):

async function isGatewayAlreadyRunning(port = 18789) {
  return new Promise(resolve => {
    const socket = new net.Socket();
    socket.setTimeout(500);
    socket.on('connect', () => { socket.destroy(); resolve(true); });
    socket.on('error', () => resolve(false));
    socket.on('timeout', () => { socket.destroy(); resolve(false); });
    socket.connect(port, '127.0.0.1');
  });
}

This works regardless of session, and is the cleanest cross-session detection method.

Option 2 — Query the Scheduled Task state via schtasks

schtasks /query /tn "OpenClaw Gateway" /fo LIST

If the Status field is Running, skip gateway startup. This is Windows-only and requires knowing the exact task name.

Option 3 — Use a named mutex or lock file

The gateway could create a named global mutex (Global\OpenClawGateway) or write a PID lock file (~/.openclaw/gateway.pid) on startup, and check/remove it on clean exit. Global mutexes are visible across sessions.

Workaround (already mentioned)

The --config flag workaround you listed is the correct user-facing workaround until this is fixed upstream.

---

I've applied bug + needs investigation labels. If you can confirm which version of the gateway introduced the Ollama launch integration, that would help narrow down the relevant code path.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@cbb46ab386962aa371045839fc9998ee4e97ca64