Bug: Windows companion app may create a new fork instead of reusing the existing session

[karkarl]

Summary

The Windows companion app appears to sometimes create a new forked session instead of attaching to / reusing the existing session.

Expected

Opening or continuing a session reuses the existing session. Forking only happens on explicit user action.

Actual

A new fork may be created in place of the existing session (session-resolution path picks/creates a new session).

Next steps

• Reproduce and capture the conditions that trigger the unwanted fork.
• Root-cause the session-resolution / attach path.

Acceptance criteria

• Continuing an existing session reuses it (no unintended fork).
• Forking occurs only when the user explicitly requests it.

Context

Surfaced during chat-session review (2026-07-08).

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 1, 2026, 6:19 AM ET / 10:19 UTC.

Summary
Keep open. Current main now remembers a materialized selected session, restores it when available, and limits companion-side session creation to the explicit /new lifecycle command, but the report has no current-main trace that identifies how an unintended fork still occurs. The existing duplicate-title work addressed the confusing symptom, not session creation itself.

Likely related people: Caleb Eden (high confidence) introduced the current lifecycle-command path; Karen (medium confidence) recently migrated the chat surface that consumes the selection state.

Reproducibility: no. Current source shows reuse-oriented selection and explicit /new creation, but the issue provides no current-main steps, session keys, gateway trace, or timing sequence that produces an unintended fork.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
A maintainer or reporter should provide one current-main unintended-fork trace before a repair worker chooses a session-resolution boundary.

Review details

Best possible solution:

Capture one current-main sequence showing the selected session key before and after the unexpected fork, then add a regression test at the proven selection or lifecycle boundary while preserving explicit /new creation.

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

No. Current source shows reuse-oriented selection and explicit /new creation, but the issue provides no current-main steps, session keys, gateway trace, or timing sequence that produces an unintended fork.

Is this the best way to solve the issue?

Unclear. The requested invariant is correct, but the safest repair boundary cannot be selected until evidence distinguishes a companion selection race from gateway-side session creation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Without a current-main trace, changing selection logic could regress the deliberate /new child-session workflow while missing a gateway-side or timing-specific trigger.

Codex review notes: model internal, reasoning high; reviewed against 8ac00c5f4977.

Label changes

Label justifications:

• P2: An unintended session fork is a normal-priority companion-chat defect with a bounded but currently unverified blast radius.
• impact:session-state: The report concerns selecting or creating the wrong conversation session.
• impact:ux-friction: Duplicate or unexpected conversations make continuation confusing, but the report does not establish a fully blocked user journey.

Evidence reviewed

What I checked:

• Current selection behavior: Current main resolves the remembered thread only while it exists (or before the first session list), otherwise prefers the gateway-marked main session and then other existing sessions; this is reuse-oriented rather than a creation path. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:6257, 8ac00c5f4977)
• Creation boundary is explicit: The only companion chat call site that reaches the gateway session-create RPC is the lifecycle dispatcher, where it is selected only for the parsed /new command. The focused tests assert that the request uses the active session as parent and does not mutate fallback state. (src/OpenClaw.Tray.WinUI/Chat/ChatLifecycleCommandDispatcher.cs:86, 8ac00c5f4977)
• Stale snapshot guard: The Reactor chat root does not fall back to the default thread while a newly created session remains pending, and focused tests cover the stale-snapshot case. This protects an explicit new-session operation but does not reproduce the reported unintended-fork trigger. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs:264, 8ac00c5f4977)
• Feature-history provenance: Local history identifies commit 2fb1da2, authored by Caleb Eden on 2026-07-21, as the introduction of native lifecycle slash commands. The commit is an ancestor of current main. (src/OpenClaw.Tray.WinUI/Chat/ChatLifecycleCommandDispatcher.cs:70, 2fb1da26c175)
• Release check: The current lifecycle implementation is newer than the checked-out v0.6.12 release: v0.6.12 points to 4166e0f and does not contain commit 2fb1da2. This is not implementation-close provenance because the reported trigger remains unproven. (4166e0fd63f8)
• Related work boundary: The linked closed issue and unmerged PR addressed duplicate display names after a fork, not the underlying condition that would create an unwanted fork. Their evidence therefore does not supersede this issue. (tests/OpenClaw.Tray.Tests/SessionTitleFormatterTests.cs:9, 8ac00c5f4977)

Likely related people:

• Caleb Eden: Local history attributes the native Windows chat lifecycle-command introduction to this contributor; that path owns the only companion-side session-create call site found in current source. (role: introduced current lifecycle-command behavior; confidence: high; commits: 2fb1da26c175; files: src/OpenClaw.Tray.WinUI/Chat/ChatLifecycleCommandDispatcher.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs)
• Karen: Local history shows the recent Reactor migration of the chat surface, which renders the provider's selected-thread and pending-selection state. (role: recent chat-surface contributor; confidence: medium; commits: 9acafa606a4d; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.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.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[github-actions]

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