Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Managed-gateway provenance probe only asks `systemctl --user`; a gateway run as a system unit can't pair the web chat

Open Beginner friendly
  • Is something wrong?
#1,763 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
bash, csharp, linux
Domain
infrastructure

Research direction

Start with ManagedLocalGatewayPortProvenanceService.IsStrongCredentialAllowed and trace where it gets the cached ExpectedManagedGateway probe result and builds the WSL probe. Check how the probe handles a missing user-unit PID, then run the relevant tests or add coverage for the system-unit fallback. Done means it checks the system manager only when the user-manager query returns no PID and still requires the same strict listener-owner match.

Written by the indexing model from the issue text.

Description

clawsweeper:needs-product-decision clawsweeper:needs-security-review clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:security impact:ux-friction issue-rating: 🦞 diamond lobster P2

Version: Companion 2026.9.8-1, managed local gateway in a WSL distro, mirrored networking, loopback gateway URL.

What happens: with "Use gateway's web chat interface" on, Chat shows "Web Chat Unavailable: Open Connection settings to finish pairing with a gateway", even though the saved gateway record has a shared token.

Cause (from reading the source at v2026.9.8-1): ManagedLocalGatewayPortProvenanceService.IsStrongCredentialAllowed (:298-322) only releases the shared token to the web chat when a cached ExpectedManagedGateway probe result exists. The probe runs wsl.exe -d <distro> -- bash -s with a script equivalent to:

pid=$(systemctl --user show openclaw-gateway -p MainPID --value); test "${pid:-0}" -gt 0 && ss -ltnp | grep -E ':18789([^0-9]|$)' | grep -F "pid=$pid,"

That only passes when the gateway is a systemd user unit. If the gateway is installed as a system unit (User= set in /etc/systemd/system/openclaw-gateway.service, a reasonable hardening step: a user unit can undo sandbox options such as InaccessiblePaths=), the user manager has no such unit, MainPID is 0, and the probe fails even though that unit's process is the one listening on the port. The probe itself is fast (about 0.1 s against the 5 s timeout); the answer is simply wrong for system units.

Expected: if the user-manager query returns no pid, fall back to the system manager (systemctl show openclaw-gateway.service -p MainPID --value) and then do the same ss pid match. The listener-owner check stays as strict as before.

Workaround on our side: a root-owned systemctl wrapper earlier on the distro's PATH that answers exactly that one --user show ... MainPID query from the system manager and passes everything else through.

Possibly related: #1333 (listener owner could not be verified).

Dominant language
C#
Stars
2.1k
Forks
315
Avg merge
4d 10h
Merged PRs (30d)
169

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/openclaw-windows-node

All issues in openclaw/openclaw-windows-node

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.