Companion hangs after connecting to remote Gateway (node bootstrap_token_invalid loop, then freeze loading large chat history); Settings unreachable #1714

Activity

1. github-project-automation

   added this to Windows Companion Appon Oct 13, 2026
2. github-project-automation

   moved this to Backlog in Windows Companion Appon Oct 13, 2026
3. clawsweeper

   added

   P0Emergency: data loss, security bypass, crash loop, or unusable core runtime.Emergency: data loss, security bypass, crash loop, or unusable core runtime.

   clawsweeper:needs-infoClawSweeper needs more reporter information before it can verify this issue.ClawSweeper needs more reporter information before it can verify this issue.

   clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.

   clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.

   impact:auth-providerThis issue is about auth, provider routing, model choice, or SecretRef resolution.This issue is about auth, provider routing, model choice, or SecretRef resolution.

   impact:crash-loopThis issue is about crashes, hangs, restart loops, or process-level availability.This issue is about crashes, hangs, restart loops, or process-level availability.

   impact:ux-release-blockerA non-technical user is blocked without terminal, logs, config, or support.A non-technical user is blocked without terminal, logs, config, or support.

   issue-rating: 🦐 gold shrimpDecent issue quality, but reproduction details are still incomplete.Decent issue quality, but reproduction details are still incomplete.

   on Oct 13, 2026
4. clawsweeper commented on Oct 13, 2026

   

   clawsweeperBot

   on Oct 13, 2026 – with ClawSweeper

   Last edited by clawsweeper

   More actions

   Codex review: this still needs some work.

   Summary
   Keep open: released-build startup hangs are independently corroborated, and neither current main nor the open candidates establish that the freeze and inaccessible Settings are fixed.

   Reproducibility: Released-build failure is credibly corroborated, including recovery by changing only the chat surface, but this read-only review establishes no high-confidence current-main reproduction and ran no builds or tests.

   Next step
   Capture current-build UI-thread samples and the redacted node rejection envelope, then select the repair and provide a visible safe-start recovery button.

   Review details

   Best possible solution:

   Restore responsive native chat and offer visible pairing repair or safe-start recovery without clearing conversations.

   Do we have a high-confidence way to reproduce the issue?

   Released-build failure is credibly corroborated, including recovery by changing only the chat surface, but this read-only review establishes no high-confidence current-main reproduction and ran no builds or tests.

   Is this the best way to solve the issue?

   Trace native navigation and rendering before selecting pagination or retry guards: small-history failures and the existing detached layout handler weaken those proposed explanations, while pairing needs separate protocol evidence.

   AGENTS.md: found and applied where relevant.

   Remaining risk / open question:

   • No current-main reproduction distinguishes a non-returning native navigation call from repeated completed calls or another rendering stall.
   • The exact node rejection envelope and role-token state remain unavailable, so authentication retries cannot yet be assigned a narrow repair.

   Codex review notes: model internal, reasoning medium; reviewed against ed1444b0de69.

   Label changes

   Label changes:

   • add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
   • remove issue-rating: 🦐 gold shrimp: Current issue advisory state no longer selects this label.
   • remove clawsweeper:needs-info: Current issue advisory state no longer selects this label.

   Label justifications:

   • P0: Reported first useful run persistently freezes Companion and makes Settings unreachable, requiring external intervention.
   • impact:ux-release-blocker: Confirmed recovery requires closing the process and editing settings outside the app.
   • impact:crash-loop: Startup restoration reportedly leaves the desktop process unresponsive across restarts.
   • impact:auth-provider: The report and corroborating discussion describe rejected setup credentials and unusable node pairing.

   Evidence reviewed

   Acceptance criteria:

   • ./build.ps1
   • dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
   • dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
   • dotnet test ./tests/OpenClaw.Connection.Tests/OpenClaw.Connection.Tests.csproj --no-restore
   • Establish a failing current-build Windows x64 startup-restoration regression before proposing a fix.

   What I checked:

   • Independent native versus legacy recovery: chestercs reports the hang on 2026.9.8-1 and Store build 2026.10.401 with only 44 transcript events and about 20 KB of history; disabling node mode did not help, while UseLegacyWebChat restored operation. The comment also reports that users.self falls back cleanly. Companion hangs after connecting to remote Gateway (node bootstrap_token_invalid loop, then freeze loading large chat history); Settings unreachable #1714 (comment).
   • Current native navigation boundary: OnLayoutUpdated detaches its handler before dispatching StartTailRequest, which validates the target and calls native StartBringItemIntoView. This retains the reported hotspot but does not prove an unconditional application-side layout loop. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, ed1444b0de69)
   • Released-build diagnostic corroboration: ShiroePL and oywino describe startup-restoration hangs with UI-thread stacks inside InitialTailPositioner and StartBringItemIntoView; oywino additionally confirms sustained UI-thread CPU consumption on 2026.9.8-1. The private dumps were not inspected. Later discussion explicitly reports no verified sustained-hang fix. [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167.
   • History reconstruction does not establish UI-thread blocking: History acquisition awaits with ConfigureAwait(false) before building and committing its reconstruction plan, so the report does not justify assuming that pagination alone repairs the native freeze. (src/OpenClaw.Tray.WinUI/Chat/ChatHistoryLoader.cs:339, ed1444b0de69)
   • Node rejection requires its exact envelope: The current node client stops reconnecting for structured AUTH_BOOTSTRAP_TOKEN_INVALID, but its terminal-code list does not include the lowercase bootstrap_token_invalid reason quoted by the reporter; the full response is needed to establish whether that omission explains the retries. (src/OpenClaw.Shared/WindowsNodeClient.cs:1182, ed1444b0de69)
   • Existing tests leave native convergence unproved: Presentation tests protect scroll wiring, stale-target rejection, bounds, and queue generations; bootstrap lifecycle tests protect durable per-role token handoff. These tests do not establish that native navigation returns under the reported failure. (tests/OpenClaw.Tray.Tests/ChatTimelinePresentationTests.cs:85, ed1444b0de69)

   Likely related people:

   • Barbara Kudiess: Raw commit d67ef51 adds src/OpenClaw.Connection/BootstrapTokenLifecycle.cs:446 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: medium; commits: d67ef5140d13; files: src/OpenClaw.Connection/BootstrapTokenLifecycle.cs)

   How this review workflow works

   • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
   • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
   • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
   • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
   • Maintainers can also comment @clawsweeper review to request a fresh review only.
   • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge; those execution lanes are retired.
   • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

   Reviewed October 26, 2026, 7:59 PM ET / 23:59 UTC.
5. chestercs commented on Oct 18, 2026

   

   chestercs

   on Oct 18, 2026

   More actions

   Same symptoms here on newer builds, plus a workaround that unblocked us.

   Environment

   • Windows Companion: Microsoft Store build 2026.10.401 (x64, Windows 11). Reproduced first on 2026.9.8-1 (Inno build).
   • Gateway: 2026.10.4 (Docker, Linux arm64), protocol 4, token auth.
   • Connection: remote, wss:// through a TLS reverse proxy (nginx, WebSocket upgrade forwarded).

   1. Setup code is burned by the operator connection
   On 2026.10.4 the gateway pairs a setup-code connection silently only when it is a mobile node (role=node, client.mode=node; isMobileNodeBootstrapConnect in the gateway's message handler). The Companion connects first as role=operator, clientId=cli, mode=cli with the bootstrap token. That connection gets pairing-required, and the code is consumed. After openclaw devices approve it keeps retrying with the same code, gets bootstrap_token_invalid, and generates a new device identity on each fresh setup attempt.
   Workaround: skip the setup code and enter the gateway URL and the shared gateway token by hand. Then approve the pending request once. The node role upgrade was auto-approved after that.

   2. The freeze is the native chat view, not history size and not node mode

   • Windows logs AppHangB1 / MoAppHang. There is no exception in openclaw-tray.log.
   • The last tray log lines before every hang are Sending frame: chat.history and Wizard response payload kind=Object len=20102. The default thread (agent:main:main) is small here: 44 transcript events, about 20 KB of history. So this is not only a "very large history" problem.
   • Setting "EnableNodeMode": false in %APPDATA%\OpenClawTray\settings.json did not stop the hang.
   • The connection is healthy the whole time: Connected within about 1 s on every start, and the node is paired and connected.
   • users.self -> FORBIDDEN is logged on every connect, but it falls back cleanly ("using owner fallback"). It is not the cause.

   Workaround that works: set "UseLegacyWebChat": true in %APPDATA%\OpenClawTray\settings.json, with the app fully closed. After that the Companion opens normally, chat works, and the node connects with its canvas/tts/stt commands.

   This points at the native chat rendering path (see also #1167, #1568), not at pairing or history size.
6. clawsweeper

   added

   clawsweeper:intake:bugPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   issue-rating: 🦪 silver shellfishThin issue quality; more reproduction proof or environment detail is needed.Thin issue quality; more reproduction proof or environment detail is needed.

   and removed

   issue-rating: 🦐 gold shrimpDecent issue quality, but reproduction details are still incomplete.Decent issue quality, but reproduction details are still incomplete.

   clawsweeper:needs-infoClawSweeper needs more reporter information before it can verify this issue.ClawSweeper needs more reporter information before it can verify this issue.

   clawsweeper:intake:bugPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   on Oct 26, 2026
7. github-actions commented on Nov 10, 2026

   

   github-actionsBot

   on Nov 10, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue has been automatically marked as stale due to inactivity.
   Please add updated OpenClaw Windows details or it will be closed.
8. github-actions

   added

   stale

   on Nov 10, 2026