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

[Bug]: Native chat vs 2026.10.5 gateway: Enter/Ctrl+Enter dead, reply never renders, app freezes, orphaned ssh.exe holds tunnel port 18789

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
44/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend-api-design, desktop

Research direction

Start by tracing the Windows Hub native chat WebSocket event handling and SSH tunnel lifecycle; the issue names no source files or tests. Reproduce against the stated 2026.10.5 gateway and compare native chat with the browser Control UI over the same tunnel. Done means keyboard submission and replies work, the app remains responsive, and closing it releases the tunnel process.

Written by the indexing model from the issue text.

Description

clawsweeper:fix-shape-clear clawsweeper:needs-maintainer-review clawsweeper:no-new-fix-pr impact:crash-loop impact:message-loss impact:ux-release-blocker issue-rating: 🦪 silver shellfish P0
Bug type

Client bug (Windows Hub native chat + SSH tunnel lifecycle)

Beta release blocker

No

Summary

Windows Hub v2026.9.8-1 (latest stable) native chat against a 2026.10.5 gateway (1b58cb9) over the built-in SSH tunnel is unusable, with a cascade failure:

  1. Composer keyboard shortcuts are dead — Enter and Ctrl+Enter do not submit; only clicking the send button works.
  2. Clicking send delivers the message (gateway-side chat.send triggers a full agent turn; model calls and the assistant reply are generated), but no reply ever renders in the Hub — the sent bubble stays gray indefinitely.
  3. Within ~1–4 minutes the entire app freezes and must be force-closed.
  4. After force-close, the Hub's tunnel ssh.exe survives as an orphan holding local port 18789; the next Hub start fails the tunnel with port-in-use. Get-NetTCPConnection -LocalPort 18789 reports an OwningProcess PID that tasklist cannot resolve (ghost socket) until the OS reclaims it.
Steps to reproduce
  1. Gateway: OpenClaw 2026.10.5 on Ubuntu (systemd user service, bind: loopback, auth.mode: token).
  2. Hub setup: SSH-tunnel connection type (key-based SSH auth to the gateway host), gateway token auth, device pairing approved via openclaw devices approve.
  3. Open a DM session in the Hub's native chat. Type a message. Try Enter / Ctrl+Enter (nothing happens). Click the send button.
  4. Observe: message reaches the gateway and the assistant turn completes (visible in gateway journal), but no reply appears; the bubble stays gray; the app freezes within minutes; force-close leaves ssh.exe holding 18789.
Expected behavior
  • Enter/Ctrl+Enter submit the composed message.
  • The assistant reply renders in the chat.
  • No app freeze; tunnel process is terminated with the app.
Actual behavior

See the four-point cascade above. Gateway-side journal evidence for step 2: the Hub's WebSocket connection polls sessions.list / sessions.preview successfully, chat.send starts the turn (model calls logged, reply generated), but zero reply/event deliveries reach the Hub connection in the same window.

Workaround that works: the gateway-served browser Control UI over the same tunnel renders the session and full bidirectional chat fine — suggesting the native client's event-stream consumption is what breaks, not the tunnel or the gateway.

Additional context
  • Client: OpenClaw Windows Tray cli v2026.9.8-1 (from the standalone releases page, latest stable as of 2026-10-20).
  • Gateway: OpenClaw 2026.10.5 (1b58cb9), Ubuntu, loopback bind.
  • Note: the stable channel (v2026.9.8-1, latest) currently has no build whose native chat works against a 2026.10.5 gateway — as reported here the feature is unusable, not degraded.
  • The SSH tunnel recovery path did not clean up the orphaned ssh.exe after the freeze.
  • Happy to provide journal excerpts or run controlled reproductions on request.
Dominant language
C#
Stars
2.2k
Forks
321
Avg merge
4d 16h
Merged PRs (30d)
175

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.